[EXP] Enterprise AI Agent Trust Injection and Connected SaaS Autonomous Insider Risk

Report Type: EXP — Enterprise Exploitation and Organizational Exposure Assessment
Threat Category: Enterprise AI Agent Trust Injection and Connected SaaS Autonomous Insider Risk
Assessment Date: July 25, 2026
Primary Impact Domain: Enterprise Authorization, Identity, and Connected SaaS Integrity
Secondary Impact Domains: Sensitive-Data Exposure, Workflow Manipulation, Persistent Agent Influence, Security-Control Impairment, Financial Risk, Customer and Workforce Impact, Regulatory Exposure, and Operational Disruption
Affected Asset Class: Enterprise AI Agents, Autonomous Workflows, SaaS Connectors, OAuth Applications, User and Service Identities, Browser Sessions, Agent Runtimes, Cloud Resources, Repositories, Business Applications, Persistent Memory, Knowledge Sources, and Downstream Enterprise Systems
Threat Objective Classification: Manipulate Trusted Agent Behavior to Perform Unauthorized Actions Through Legitimate Enterprise Identities, Permissions, Connectors, and Workflows

Published by: CyberDax LLC
Author: Edward “Tony” Dolley
Role: Founder / Principal Threat Researcher, CyberDax LLC
Publication Date: July 25, 2026
Publication Type: Cybersecurity Research Report / White Paper

S2 BLUF

‍ ‍Enterprise AI Agent Trust Injection and Connected SaaS Autonomous Insider Risk creates material enterprise risk because adversary-controlled, compromised, or insufficiently trusted content may alter how an authorized AI agent interprets its task, prioritizes instructions, selects tools, uses connected applications, accesses sensitive information, and performs consequential actions. The risk arises when content presented as data is treated as authoritative direction and materially changes the agent’s task plan, operating constraints, recipients, destinations, data scope, approval interpretation, tool sequence, or completion criteria.

Successful manipulation may allow an adversary to convert a legitimate enterprise agent into an authorized mechanism for sensitive-data access, external communication, permission changes, identity modification, workflow execution, code or configuration changes, financial activity, security-control impairment, persistent influence, or downstream organizational impact. The threat is behaviorally significant because the agent may perform these actions through valid enterprise identities, approved OAuth grants, legitimate connectors, permitted SaaS APIs, expected browser sessions, and sanctioned automation platforms.

The resulting activity may therefore appear technically authorized even when it is inconsistent with the initiating user’s intent, the approved business workflow, organizational policy, or the parameters reviewed during human approval. Compromise may occur without exploitation of a software vulnerability, malware execution, an unfamiliar account, or an obviously malicious network destination.

Immediate executive action is required to inventory enterprise agents and autonomous workflows, map their owners, identities, connectors, permissions, approval controls, data sources, SaaS dependencies, and high-impact capabilities, and determine where untrusted content can influence authorized action. Organizations must preserve prompt, retrieved-content, task-plan, tool-call, approval, identity, connector, SaaS, browser, endpoint, cloud, and network evidence; investigate material behavioral changes; isolate affected agents and connectors; revoke exposed permissions and tokens; restore altered enterprise state; remove persistent influence; and confirm that agent behavior and downstream systems have returned to a known-trusted condition.

Executive Risk Translation

This activity shifts the business risk from an unsafe prompt or unusual model response to uncertainty over whether an authorized enterprise agent and the systems connected to it can continue to be trusted. The primary concern is whether adversary-controlled information redirected the agent’s objective, caused it to exceed the initiating task, influenced its use of enterprise tools, altered the destination or scope of enterprise data, bypassed or misrepresented approval, or produced unauthorized actions under legitimate organizational authority.

When available evidence cannot reliably distinguish external-content exposure from successful behavioral influence, approved automation from unauthorized autonomous action, or direct human activity from agent-performed activity, leadership may need to treat the affected agent, its identities, its connectors, and its resulting enterprise actions as potentially compromised until proven otherwise.

That response may require suspension of autonomous workflows, connector and token revocation, preservation of agent sessions and retrieved content, reconstruction of tool and action sequences, validation of approvals, review of sensitive-data access, restoration of altered SaaS objects and permissions, enterprise-wide hunting across connected agents and platforms, legal and compliance review, executive reporting, and formal confirmation that affected agents and downstream systems can safely return to trusted use.

S3 — Why This Matters Now

·        Enterprise AI agents are increasingly moving from advisory use into action-oriented workflows that can read enterprise data, invoke tools, modify records, communicate externally, update workflows, execute code, and administer connected platforms.

·        Agents routinely process email, documents, webpages, tickets, chat messages, calendar entries, repository content, API responses, knowledge sources, and tool outputs that may contain adversary-controlled or compromised instructions.

·        Adversarial content may be embedded in ordinary business information and may not resemble a conventional exploit, malicious attachment, known injection phrase, or suspicious executable.

·        The use of legitimate enterprise identities, approved applications, valid APIs, and existing permissions can cause unauthorized actions to appear routine or technically compliant.

·        A low-risk task such as summarization, research, classification, or document review may be redirected into an externally communicative, identity-sensitive, financial, destructive, or administrative operation.

·        Browser automation, computer-use capabilities, code interpreters, and local agent runtimes are expanding the range of systems and business processes an agent can influence.

·        Multi-agent and connected-workflow architectures can allow one manipulated task to affect additional agents, users, repositories, tenants, or business processes.

·        Current platform logging frequently does not preserve the complete prompt, retrieved content, task plan, approval context, rejected actions, or final parameter set needed to reconstruct what occurred.

·        A successful event may produce no malware alert, no new process, no visibly malicious response, and no obviously hostile network destination.

·        Removing the initiating content, restarting an agent, or revoking one connector does not prove that unauthorized actions, copied data, altered permissions, created identities, persistent context, or downstream changes were removed.

·        The issue is especially urgent where agents support finance, legal, human resources, customer operations, identity administration, security operations, software development, source control, cloud administration, regulated-data processing, or executive workflows.

S4 — Key Judgments

·        Enterprise AI Agent Trust Injection and Connected SaaS Autonomous Insider Risk should be treated as an enterprise authorization, data-governance, identity, SaaS-integrity, insider-risk, and business-resilience issue, not only as a prompt-security or model-safety concern.

·        The primary enterprise risk is the adversary’s ability to convert untrusted content into altered agent behavior and then use legitimate enterprise identities, permissions, connectors, and functions to perform unauthorized actions.

·        Suspicious content or an unsafe model response does not independently establish successful trust injection or enterprise impact.

·        Stronger evidence exists when untrusted content is followed by a material change in the agent’s objective, task plan, tool use, connector sequence, data scope, recipients, destinations, approval behavior, or resulting enterprise state.

·        Actions performed through valid enterprise authority remain unauthorized when they are inconsistent with explicit user intent, approved workflow, or organizational policy.

·        Approval is meaningful only when it can be tied to the final action, recipient, destination, resource, data scope, identity, and executed parameters.

·        Sensitive-data access becomes materially more significant when it is followed by unauthorized transfer, external sharing, downstream use, or action in another connected system.

·        A workflow should not be considered fully blocked when earlier steps created consequential changes.

·        Repeated attempts to achieve a denied objective through alternate tools, connectors, identities, browser automation, code execution, or smaller steps materially increase concern.

·        Unauthorized agent activity may be confirmed even when the available evidence cannot conclusively determine whether the root cause was trust injection, malicious user direction, excessive agency, weak permissions, or workflow failure.

·        Persistent influence that survives session termination, agent restart, content removal, or connector revocation materially expands the response scope.

·        A functioning agent, successful task result, completed connector revocation, or clean endpoint scan does not prove that data, permissions, identities, workflows, or downstream state remained intact.

·        The most damaging outcome occurs when a manipulated agent exposes sensitive information, alters identities or permissions, modifies source code or deployments, performs financial activity, impairs security controls, affects customers or employees, or expands across multiple connected systems.

S5 — Executive Risk Summary

Business Risk

Enterprise AI Agent Trust Injection and Connected SaaS Autonomous Insider Risk can create direct business harm when an authorized agent performs actions that were not intended, properly approved, or within the organization’s accepted risk boundaries.

Potential consequences include unauthorized disclosure or modification of sensitive information, improper customer or workforce communications, altered permissions, creation of unauthorized users or applications, fraudulent or incorrect transactions, contaminated business records, code or configuration changes, security-control impairment, disrupted operations, and unreliable automated decisions.

Risk increases when affected agents support finance, customer service, human resources, legal operations, software development, source control, deployment, identity administration, cloud operations, security functions, procurement, regulated-data processing, executive communications, or other business-critical workflows.

Technical Cause

The risk is driven by failure to preserve a reliable trust boundary between authoritative instructions, user intent, retrieved content, tool results, persistent context, and external data.

Exposure becomes material when untrusted content changes the agent’s task objective, tool selection, connector use, data scope, recipients, destinations, approval interpretation, or completion criteria. The agent may then use valid enterprise authority to read or transfer information, modify records, change identities or permissions, execute workflows, alter code or configuration, perform financial activity, impair controls, or create persistent influence.

Technical uncertainty increases when prompts, retrieved content, task plans, tool-call arguments, approval records, connector activity, SaaS object changes, resulting state, browser actions, and identity use cannot be reliably correlated.

Threat Posture

The threat posture is elevated for agents that process untrusted content while possessing access to write-capable, externally communicative, financial, identity-sensitive, security-sensitive, destructive, or administrative functions.

Risk becomes critical where agents use broad OAuth scopes, delegated user authority, shared service identities, persistent browser sessions, unrestricted connectors, code-execution environments, or computer-use capabilities. It is also elevated where agents can access sensitive data from one system and act through another, modify enterprise identities or permissions, alter source code or deployments, influence other agents, or affect customer-facing or regulated business processes.

The threat may remain active after the initiating content is removed if altered workflows, persistent context, created identities, tokens, external shares, knowledge entries, automations, or downstream SaaS changes remain.

Executive Decision Requirement

Executives must determine whether affected agent activity can be reconstructed well enough to support defensible containment, recovery, legal, compliance, customer, workforce, and business decisions.

Leadership should require immediate identification of affected agents, identities, data, connectors, SaaS platforms, business processes, approvals, and downstream actions. When impact cannot be ruled out, executives must be prepared to authorize agent suspension, connector isolation, token and session revocation, identity and permission review, persistent-context removal, workflow rollback, SaaS-state restoration, expanded hunting, legal and compliance escalation, customer or workforce impact analysis, communications planning, and temporary manual operation of affected business processes.

The executive decision is whether evidence supports continued use of the affected automation, whether broader containment is required, and what proof is necessary before consequential agent activity resumes.

S6 — Executive Cost Summary

Enterprise AI Agent Trust Injection and Connected SaaS Autonomous Insider Risk creates financial exposure because the organization must determine whether an authorized agent was behaviorally redirected, whether its actions matched explicit user intent, whether approvals covered the final activity, whether sensitive data or enterprise records were affected, and whether unauthorized influence reached connected systems or business processes.

The cost profile differs from routine prompt filtering, SaaS remediation, or endpoint investigation because the affected agent may have continued operating through valid identities and approved business systems while its behavior and resulting actions were no longer trustworthy. A single confirmed event may require investigation across AI platforms, orchestration systems, identity services, OAuth applications, connectors, SaaS tenants, cloud platforms, collaboration systems, source repositories, CI/CD environments, customer systems, financial platforms, endpoints, browsers, and network infrastructure.

Response cost is driven by the need to preserve and reconstruct agent activity, validate human intent and approval, review sensitive-data access, identify unauthorized actions, revoke identities and permissions, remove persistent influence, restore altered enterprise state, investigate related agents and workflows, assess business and data impact, and prove that affected operations have returned to a known-good condition.

Cost increases materially where agent inventory is incomplete, ownership is unclear, permissions are broad, task and approval records are insufficient, agent and human activity share identities, SaaS read telemetry is unavailable, persistent context is not versioned, multi-agent provenance is lost, or relevant logs are delayed, redacted, overwritten, or deleted.

Low Impact Scenario

Rapid investigation confirms exposure to suspicious or adversarial content without evidence that the content materially altered the agent’s task, tool use, data scope, approval behavior, or downstream actions.

No sensitive data was transferred, no consequential enterprise state changed, no identity or permission was altered, no persistent influence was created, and no downstream system was affected. Response is limited to targeted session review, evidence preservation, connector and policy validation, focused SaaS audit review, control tuning, limited hunting, and executive assurance.

Estimated impact $500K–$3M.

Moderate Impact Scenario

Confirmed or strongly suspected manipulation affects one or more agents, connectors, identities, SaaS platforms, workflows, data stores, or business processes.

Evidence may include unauthorized data access or transfer, external communication, permission or identity changes, workflow modification, source-code or configuration changes, approval mismatch, persistent-context modification, security-control impairment, or incomplete visibility into affected actions.

Response requires enterprise-focused investigation, token and connector revocation, identity and permission review, persistent-context removal, SaaS and workflow restoration, sensitive-data impact analysis, expanded hunting, legal and compliance assessment, cyber-insurance coordination, executive reporting, and formal validation that affected systems and records can be relied upon.

Estimated impact $5M–$35M.

High Impact Scenario

Enterprise AI agent trust injection becomes an enterprise-impact event when confirmed or suspected manipulation results in broad sensitive-data exposure, fraudulent or unauthorized financial activity, privileged identity creation, widespread SaaS modification, customer or workforce impact, source-code or deployment compromise, cloud or identity compromise, security-control impairment, destructive activity, or coordinated abuse across multiple agents, tenants, business units, or downstream systems.

Response may require emergency suspension of agent populations, broad credential and token rotation, enterprise-wide SaaS and identity hunting, financial and transaction review, customer or workforce impact analysis, restoration of altered data and permissions, source-code and deployment validation, legal and regulatory escalation, cyber-insurance engagement, communications response, customer-notification analysis, executive and board reporting, and formal validation that enterprise operations can safely resume.

Estimated impact $40M–$200M+.

S6A — Key Cost Drivers

·        Number and business criticality of affected agents, autonomous workflows, connectors, identities, tenants, and downstream platforms.

·        Scope of sensitive or regulated data accessed, modified, summarized, transferred, exposed, or used in downstream decisions.

·        Number and impact of unauthorized messages, shares, records, permissions, identities, workflows, code changes, deployments, transactions, or administrative actions.

·        Availability of complete prompts, retrieved content, task plans, tool-call records, approval parameters, connector activity, SaaS audit events, and resulting-state evidence.

·        Ability to distinguish agent-performed actions from direct human activity under shared or delegated identities.

·        Number and privilege level of OAuth grants, tokens, service principals, connector identities, applications, service accounts, and delegated permissions requiring review or revocation.

·        Scope of cross-system and cross-connector activity requiring reconstruction.

·        Number of partially completed workflows, altered SaaS objects, permissions, transactions, business records, or automated decisions requiring rollback or validation.

·        Scope of persistent changes involving saved instructions, memory, knowledge sources, workflows, templates, rules, automations, connector settings, or shared enterprise content.

·        Number of additional agents, users, workspaces, tenants, repositories, mailboxes, business units, and workflows that may have received contaminated context or instructions.

·        Scope of security-control impairment, logging interruption, evidence deletion, misleading completion reporting, or audit degradation.

·        Number of browsers, endpoints, local runtimes, code-execution environments, containers, workloads, and cloud systems requiring forensic review.

·        Complexity of restoring affected identities, permissions, SaaS objects, workflows, data, source code, deployments, and business records to a known-good state.

·        Business disruption caused by agent suspension, connector revocation, workflow shutdown, transaction reversal, deployment freeze, manual processing, or temporary withdrawal of autonomous capability.

·        Dependence on AI-platform, SaaS, cloud, identity, connector, managed-service, customer, and partner organizations to preserve evidence or restore services.

·        Legal, privacy, regulatory, contractual, financial, employment, customer, partner, cyber-insurance, communications, executive, and board obligations resulting from unauthorized autonomous action or inability to prove the integrity of affected decisions and records.

S6B — Compliance and Risk Context

Figure 1

Enterprise AI Agent Trust Injection and Connected SaaS Autonomous Insider Risk creates compliance exposure when an agent uses delegated enterprise authority to access, disclose, modify, delete, approve, transmit, or act on information without valid human intent, authorization, or policy support.

The central compliance concern is whether an automated or semi-autonomous system performed a regulated, contractual, financial, employment-related, customer-impacting, or records-affecting action that cannot be reliably attributed to an authorized human decision.

Risk increases when the organization cannot prove:

·        Who initiated the task.

·        What information influenced the agent.

·        Which instructions the agent treated as authoritative.

·        What action the human user intended.

·        What parameters were presented for approval.

·        Whether the final executed action matched that approval.

·        Which identity and permissions were used.

·        What data was accessed, transferred, modified, or deleted.

·        Which records, decisions, transactions, or systems were changed.

·        Whether persistent or downstream effects remain.

Potential exposure may involve privacy and breach-notification duties, data-protection requirements, financial and transaction controls, employment and human-resources obligations, records-integrity and retention requirements, legal-hold duties, access-control standards, customer and partner contracts, software-development governance, data-residency commitments, cyber-insurance conditions, and internal AI-governance requirements.

Compliance exposure should be driven by local evidence of unauthorized autonomous action, sensitive-data handling, invalid delegated authority, altered records, unapproved automated decisions, identity or permission changes, persistent influence, or inability to reconstruct human intent and approval. It should not be based solely on the use of enterprise AI, exposure to suspicious content, a classifier alert, an unusual response, or a denied tool request.

Enterprise AI Agent Trust Injection and Connected SaaS Autonomous Insider Risk executive risk model showing how adversary-controlled or compromised content may enter an enterprise agent’s working context, alter the agent’s objective or instruction priority, influence tool and connector use, misuse delegated authority, expand access to connected SaaS and sensitive data, trigger unauthorized autonomous action, create persistent influence, propagate through additional agents or workflows, and produce operational, financial, legal, regulatory, customer, workforce, reputational, and board-level impact.

Compliance Exposure Indicator

High

Risk Register Entry

Risk Title

Enterprise AI Agent Trust Injection and Connected SaaS Autonomous Insider Risk

Risk Description

Enterprise AI agents may use legitimate identities, connectors, applications, and permissions to perform actions that were not explicitly requested, were not properly approved, exceeded the authorized task, or were influenced by adversary-controlled content.

The risk affects the integrity of enterprise data, automated decisions, approval records, business communications, customer and workforce information, financial activity, software changes, identities, permissions, and downstream system state.

Because manipulated activity may occur through approved enterprise services, the organization may be unable to immediately distinguish unauthorized agent behavior from legitimate human or automated activity. This can delay containment, expand investigative scope, and create uncertainty over which records, decisions, transactions, communications, permissions, and business processes remain reliable.

Potential consequences include sensitive-data exposure, fraudulent or incorrect activity, operational disruption, legal or regulatory review, customer or employee impact, incident-response cost, cyber-insurance scrutiny, reputational damage, and board-level concern.

Risk severity should be based on local evidence of unauthorized agent behavior, misuse of delegated authority, sensitive-data handling, enterprise-state changes, persistent influence, downstream impact, or inability to reconstruct human intent and approval.

Likelihood

High

Impact

Severe

Risk Rating

Critical

Annualized Risk Exposure

Estimated annualized exposure of $6M–$45M+ for materially exposed enterprise environments where AI agents process untrusted content, access sensitive or regulated information, connect to multiple enterprise platforms, use delegated authority, or perform write-capable, identity-sensitive, financial, security-sensitive, customer-impacting, or administrative actions.

Exposure increases when agent inventory is incomplete, ownership is unclear, permissions are excessive, approval controls are weak, task and action provenance is incomplete, agent and human activity share identities, persistent context is not governed, or the organization cannot reconstruct affected data, decisions, permissions, and downstream actions.

A realized severe event may reach $40M–$200M+ when manipulation results in broad sensitive-data exposure, fraudulent financial activity, privileged identity creation, widespread enterprise-system modification, source-code or deployment compromise, customer or workforce harm, security-control degradation, destructive activity, prolonged operational disruption, regulatory reporting, customer notification, litigation, cyber-insurance review, communications response, or board-level intervention.

S7 — Risk Drivers

·        Enterprise agents process externally controlled, shared, public, user-editable, or compromised content.

·        Authoritative instructions, user requests, retrieved data, tool results, and persistent context may not be reliably separated.

·        Agents may possess access to multiple enterprise systems and data sources beyond the minimum required for one task.

·        OAuth scopes, delegated permissions, connector authority, service identities, and persistent sessions may be overly broad.

·        Write-capable, externally communicative, destructive, financial, identity-sensitive, security-sensitive, and administrative functions may be available within the same workflow.

·        Human approval may not be bound to the exact final action and parameters executed.

·        Agent and human actions may share the same identity, weakening attribution and accountability.

·        SaaS platforms may not record complete read, search, preview, export, or returned-data activity.

·        Agent platforms may omit planning, rejected actions, retries, parameter changes, and alternate execution paths.

·        Browser automation and computer-use capabilities may bypass structured tool and connector controls.

·        Code-execution and local-agent environments may expose files, credentials, browser sessions, local networks, cloud metadata, and operating-system functions.

·        Sensitive data may move between systems without preserving clear provenance.

·        Data may be transformed, summarized, encoded, or fragmented before transfer.

·        Persistent instructions, memory, knowledge sources, workflows, templates, rules, and shared content may influence future sessions.

·        Multi-agent and multi-workflow environments may propagate contaminated context without preserving source attribution.

·        Agents may be able to modify their own operating context, tools, connector settings, policies, or approval paths.

·        Denied actions may be retried through alternate tools, identities, connectors, APIs, browser sessions, or smaller workflow steps.

·        Multi-step workflows may create irreversible or consequential state before final completion.

·        Security controls may observe individual actions without linking them to the initiating content, task, approval, or agent decision.

·        Logs may be incomplete, delayed, sampled, redacted, overwritten, unsynchronized, or locally alterable.

·        Agent restart, workflow restoration, connector revocation, workload replacement, or model update may remove evidence without removing downstream impact.

·        Approved automation, synchronization, migration, administration, security testing, development, and incident response may resemble suspicious activity.

·        Business impact increases where agents support regulated data, financial activity, identity administration, customer operations, legal work, human resources, software delivery, security operations, cloud administration, or executive workflows.

·        Weak inventory, unclear ownership, excessive authority, incomplete approval controls, and insufficient recovery procedures can convert one manipulated task into systemic enterprise uncertainty.

S8 — Bottom Line for Executives

Enterprise AI Agent Trust Injection and Connected SaaS Autonomous Insider Risk requires an operational decision on whether affected agents and workflows should continue running, be restricted, or be suspended.

Executives should require immediate answers to four questions:

·        What agent action occurred.

·        Whether the action matched explicit human intent and approval.

·        What enterprise data, identities, systems, records, or business processes were affected.

·        What containment and validation are required before autonomous operation resumes.

The operational response should prioritize preservation of evidence, suspension of unsafe capability, revocation of exposed authority, reconstruction of consequential actions, restoration of altered state, validation of affected records and decisions, and expanded hunting across connected agents and platforms.

The absence of malware, removal of one suspicious content item, revocation of one connector, or continued operation of the affected workflow should not be treated as proof that the incident is contained.

S9 — Board-Level Takeaway

Enterprise AI Agent Trust Injection and Connected SaaS Autonomous Insider Risk is a board-level governance issue because it tests whether the organization can maintain accountable human authority over autonomous and semi-autonomous enterprise action.

The board should require assurance that:

·        Every material enterprise agent has an accountable owner.

·        Agent authority is limited to approved business purposes.

·        High-impact actions are governed by independent controls.

·        Human approval is attributable and bound to the final action.

·        Agent actions can be distinguished from direct human activity.

·        Sensitive data and regulated processes remain protected.

·        Behavior-changing instructions and persistent context are governed.

·        Multi-agent and cross-platform activity preserves provenance.

·        Material incidents can be contained without losing evidence.

·        Altered records, decisions, permissions, and systems can be restored and independently validated.

Board reporting should address material agent dependencies, control gaps, unresolved attribution, affected business processes, customer or workforce impact, legal and regulatory implications, financial exposure, containment status, recovery evidence, and residual risk.

The board-level standard is not whether an agent remains functional. It is whether management can demonstrate that autonomous enterprise authority remains bounded, accountable, observable, recoverable, and aligned with the organization’s risk tolerance.

S10 — Threat Overview

Enterprise AI Agent Trust Injection and Connected SaaS Autonomous Insider Risk describes adversary behavior in which attacker-controlled, compromised, or insufficiently trusted content enters an enterprise agent’s operating context and materially changes how the agent interprets its task, prioritizes instructions, selects tools, uses delegated authority, accesses enterprise data, or performs actions across connected systems. The affected agent may treat content presented as data as authoritative direction and alter its objective, constraints, data scope, recipients, destinations, approval interpretation, connector sequence, action parameters, or completion criteria.

Resulting behavior may include unauthorized enterprise information access, cross-connector data use, external communication, file or record modification, identity or permission changes, workflow execution, code or configuration changes, financial activity, security-control impairment, persistent influence, concealment, or downstream organizational impact. The agent may perform these actions through valid user identities, service accounts, service principals, managed identities, OAuth applications, connectors, browser sessions, APIs, automation platforms, and approved SaaS functions.

Multiple content sources, instruction formats, models, agent frameworks, orchestration platforms, tools, connectors, identities, SaaS applications, approval paths, and resulting actions may produce this behavior. The durable enterprise risk is broader than any single prompt phrase, injection string, model, tool call, connector, platform, campaign, actor, proof of concept, recipient, destination, or infrastructure indicator.

·        This is not only a suspicious-prompt, unsafe-response, model-error, classifier-alert, unusual-tool-call, OAuth-event, external-share, or anomalous-SaaS-activity model.

·        The core threat behavior is adversary-controlled or compromised content materially influencing an agent and causing attempted or completed unauthorized action through legitimate enterprise authority.

·        Email, documents, webpages, tickets, chat, repositories, API responses, knowledge sources, tool output, memory, shared files, and enterprise records represent the primary trust-injection surface.

·        Agent identities, OAuth applications, connectors, browser sessions, service accounts, service principals, managed identities, APIs, and delegated permissions represent the primary authorization surface.

·        Mailboxes, collaboration platforms, file stores, repositories, ticketing systems, customer platforms, financial applications, identity services, cloud platforms, security systems, and administrative consoles represent the primary downstream exposure surface.

·        Suspicious, imperative, hidden, encoded, or machine-oriented content does not prove that the agent followed the instruction.

·        A classifier alert or unusual response does not independently prove behavioral influence, tool execution, data access, or enterprise impact.

·        A proposed or generated tool call does not prove execution.

·        A denied final action does not prove that earlier workflow steps created no consequential state change.

·        Sensitive-data access does not independently establish exposure without evidence of unauthorized transfer, sharing, downstream use, modification, or another consequential action.

·        Cross-connector activity may be legitimate and requires task, approval, identity, recipient, destination, data-scope, and resulting-state context.

·        Valid identity or connector use does not establish that the resulting action was authorized for the specific task.

·        Browser and computer-use agents may perform consequential activity without structured tool-call or connector telemetry.

·        Cloud-hosted agents may perform unauthorized activity without malware, endpoint processes, local files, or obvious network anomalies.

·        Agent and human activity may appear under the same identity, session, application, service principal, or connector.

·        Persistent influence may exist in saved instructions, memory, knowledge bases, vector stores, workflows, templates, rules, policies, shared content, repositories, tickets, connector settings, or downstream SaaS objects.

·        Removing the initiating content, restarting the agent, revoking one connector, or deleting one session does not prove that persistent or downstream effects were removed.

·        Malicious user-directed activity must remain distinct from indirect trust injection unless untrusted content materially influenced the agent’s behavior.

·        Excessive agency and ordinary workflow failure must remain distinct from successful trust injection unless adversarial content materially altered the task plan, authorization context, tool use, or downstream action.

·        Public research, demonstrations, advisories, proof-of-concept content, platform findings, and incident reporting should increase investigative urgency without narrowing the assessment into a vendor-specific, model-specific, or indicator-only approach.

S11 — Threat Classification and Type

Threat Type

Enterprise AI Agent Trust Injection and Connected SaaS Autonomous Insider Risk.

Threat Sub-Type

Indirect prompt injection, instruction-precedence manipulation, task-goal redirection, false-authority presentation, approval-context manipulation, tool-selection influence, connector misuse, delegated-authority abuse, unauthorized SaaS access, cross-system data transfer, identity or permission modification, workflow manipulation, persistent context poisoning, multi-agent propagation, security-control impairment, evidence suppression, and downstream organizational impact.

Operational Classification

Agent trust-boundary compromise, authorization misuse, connected-SaaS abuse, sensitive-data exposure, identity and permission risk, persistent workflow influence, autonomous insider-like activity, downstream system compromise, and business-resilience risk.

Primary Function

Cause an enterprise agent to treat adversary-controlled or compromised content as authoritative direction, materially alter the agent’s task or decision process, use legitimate enterprise identities and connected tools to perform unauthorized actions, and sustain or expand influence while creating uncertainty around human intent, approval validity, data handling, identity use, SaaS integrity, containment completeness, and downstream enterprise impact.

S12 — Campaign or Activity Overview

Figure 2

Enterprise AI Agent Trust Injection and Connected SaaS Autonomous Insider Risk activity model showing adversary-controlled or compromised content entering agent context, instruction-priority or task-goal manipulation, altered planning and tool selection, delegated-authority use, connected-SaaS access, unauthorized data or state changes, persistent influence, multi-agent propagation, concealment, and downstream organizational impact.

This report assesses enterprise AI agent trust injection and connected-SaaS autonomous insider risk as a durable behavior class rather than a single prompt, phrase, model, agent framework, tool, connector, SaaS platform, proof-of-concept implementation, campaign, actor, domain, recipient, destination, or infrastructure indicator.

The activity begins when adversary-controlled, compromised, public, shared, or insufficiently trusted content enters an enterprise agent’s working context. The content may contain direct or indirect instructions, false authority claims, approval claims, hidden text, encoded content, fragmented directives, tool instructions, recipient changes, destination changes, or completion requirements intended to influence machine behavior.

Activity may progress when the agent materially changes its objective, planning sequence, data scope, tool choice, connector use, identity, recipient, destination, approval interpretation, or action parameters. The agent may then use valid enterprise authority to retrieve sensitive information, communicate externally, alter records, modify permissions, create identities or applications, change workflows, update code or configuration, initiate financial activity, impair security controls, or influence another agent or automation.

Successful activity may produce one or more outcomes, including adversarial-content exposure, suspected trust injection, probable instruction influence, attempted tool misuse, blocked autonomous action, partially completed unauthorized action, unauthorized autonomous action, sensitive-data exposure, persistent compromise, or confirmed downstream organizational impact.

·        The activity is best understood as an authorization, identity, data-governance, SaaS-integrity, insider-risk, and business-resilience threat rather than a routine prompt-filtering or model-safety issue.

·        The exact content format, instruction pattern, model, agent framework, tool, connector, platform, identity, or execution path may vary.

·        Activity may begin through email, documents, webpages, tickets, chat messages, calendar entries, repository content, code comments, images, API responses, tool output, knowledge sources, memory, or another content path available to the agent.

·        Adversaries may use direct instructions, indirect goal manipulation, false system messages, fake approval claims, policy impersonation, role claims, urgency, hidden content, encoding, fragmentation, recursion, multilingual content, or instructions distributed across multiple objects.

·        Activity may remain limited to suspicious content exposure, classifier alerts, policy conflicts, denied tool calls, connector errors, approval rejection, malformed arguments, or incomplete execution.

·        Probable instruction influence is indicated when the agent materially changes its plan, tool use, data scope, recipient, destination, identity, approval behavior, or completion criteria after processing untrusted content.

·        Probable authorization misuse is indicated when the resulting action is inconsistent with explicit user intent, approved workflow, organizational policy, or the parameters reviewed during approval.

·        Actions may occur under the expected user, application, service account, service principal, managed identity, browser session, OAuth grant, connector identity, or automation account.

·        Sensitive information may be retrieved through one system and transmitted, posted, uploaded, shared, summarized, encoded, modified, or acted upon through another.

·        Unauthorized changes may involve messages, files, records, permissions, users, groups, roles, guests, applications, OAuth grants, tokens, workflows, rules, webhooks, repository content, code, deployments, transactions, security settings, or customer-facing information.

·        High-impact activity may use structured connectors, SaaS APIs, browser automation, computer-use capabilities, local agent runtimes, code interpreters, or combinations of these methods.

·        A multi-step workflow may create consequential state before a later step is blocked, denied, cancelled, or abandoned.

·        Repeated retries may use modified parameters, alternate tools, different connectors, browser automation, code execution, or another available identity.

·        Persistent influence may use saved instructions, memory, knowledge bases, vector stores, shared content, workflow definitions, templates, rules, policies, automations, connector settings, or downstream SaaS objects.

·        Multi-agent propagation may occur when one agent passes contaminated context, data, instructions, or objectives to another agent or workflow.

·        Concealment may involve minimizing user-visible disclosure, omitting consequential actions, deleting messages or files, altering records, removing session history, impairing audit settings, or falsely reporting task completion.

·        Downstream impact may involve sensitive-data exposure, customer or workforce harm, financial loss, identity compromise, cloud or SaaS compromise, source-code or deployment changes, security-control impairment, destructive activity, legal or regulatory exposure, or prolonged operational disruption.

·        Actor names, prompt strings, model names, tool names, connector names, SaaS platforms, domains, recipients, destinations, proof-of-concept releases, and individual implementation details should enrich the assessment rather than replace local behavior-led evidence.

S13 — Targets and Exposure Surface

The exposure surface includes enterprise AI agents, assistants, copilots, autonomous workflows, browser agents, local agents, orchestration systems, and AI-enabled business processes that consume untrusted or externally controlled content while possessing access to enterprise data, identities, tools, connectors, applications, or high-impact actions.

It also includes every user, identity, connector, SaaS platform, knowledge source, workflow, endpoint, browser, cloud resource, repository, financial process, customer system, security control, and downstream relationship that may be accessed, changed, influenced, or exposed through manipulated agent behavior.

·        Enterprise AI assistants, copilots, autonomous agents, workflow agents, browser agents, computer-use agents, local desktop agents, code agents, security agents, customer-service agents, research agents, and multi-agent systems.

·        Agent orchestration platforms, model gateways, retrieval systems, prompt-management systems, tool routers, policy engines, memory services, vector stores, knowledge bases, agent runtimes, evaluation platforms, and network-accessible agent-response or execution interfaces.

·        MindsDB Minds Platform deployments where unauthenticated access to agent-response functionality can reach agent scratchpad or runtime execution capabilities and result in operating-system command execution.

·        Agent-runtime environments where attacker-controlled requests, prompts, tool arguments, or other externally influenced input can reach code-interpreter, shell, subprocess, command-execution, or equivalent operating-system execution paths.

·        Atlassian Rovo and AI-enabled Jira and Confluence workflows where agents consume Jira issues, comments, descriptions, attachments, Confluence pages, embedded content, linked resources, search results, or other user-controlled and externally influenced content that may contain indirect prompt-injection instructions.

·        Jira and Confluence projects, spaces, pages, issues, comments, attachments, knowledge content, linked objects, automation content, and shared workspace material capable of influencing Rovo or other connected AI-agent behavior.

·        Rovo and connected-SaaS workflows in which manipulated Jira, Confluence, or retrieved third-party content can influence an agent to access, summarize, retrieve, correlate, disclose, transmit, or otherwise act on enterprise data through authorized connectors and delegated user permissions.

·        Connected SaaS applications and enterprise data sources reachable through Rovo or similar agent connectors, including collaboration, file-storage, document, ticketing, source-code, customer, financial, human-resources, identity, cloud, security, and productivity platforms.

·        Email, documents, webpages, tickets, chat messages, calendar entries, shared files, images, repository content, code comments, pull requests, issue trackers, API responses, tool output, search results, and public content.

·        System instructions, developer instructions, user instructions, saved prompts, templates, workflow definitions, agent memory, retrieved context, tool descriptions, policy statements, and behavior-changing configuration.

·        User identities, service accounts, service principals, managed identities, OAuth applications, delegated sessions, API tokens, refresh tokens, browser sessions, connector identities, and shared automation accounts.

·        Mailboxes, collaboration platforms, file-storage services, document platforms, ticketing systems, customer platforms, human-resources systems, legal platforms, financial applications, procurement platforms, and enterprise resource planning systems.

·        Source repositories, package registries, CI/CD systems, deployment platforms, infrastructure-as-code repositories, build systems, development environments, code-review systems, and release-management workflows.

·        Identity providers, directory services, access-governance systems, privileged-access platforms, conditional-access systems, application-consent systems, group-management systems, and administrative portals.

·        Cloud platforms, SaaS tenants, databases, object stores, secret stores, orchestration platforms, serverless services, virtual machines, containers, managed identities, metadata services, and administrative APIs.

·        Security information and event management platforms, endpoint platforms, email-security systems, data-loss-prevention systems, CASB and SaaS-security platforms, vulnerability-management systems, incident-response systems, and security-automation workflows.

·        Browser automation, computer-use interfaces, code interpreters, command-execution tools, local runtimes, endpoints, virtual desktops, containers, automation workers, and managed execution environments.

·        Customer records, employee records, financial records, legal material, source code, credentials, secrets, security findings, regulated information, executive communications, operational data, and administrative records.

·        High-impact functions involving send, share, upload, download, create, modify, delete, approve, purchase, pay, deploy, publish, invite, grant, revoke, elevate, disable, or administer.

·        Workflows where one connector retrieves sensitive information and another connector can transmit, post, upload, share, modify, or act on that information.

·        Agents with broad OAuth scopes, delegated user authority, persistent sessions, shared identities, unrestricted connectors, weak recipient restrictions, or weak destination restrictions.

·        Agents capable of modifying their own instructions, memory, tools, workflows, knowledge sources, policies, connector configuration, or approval paths.

·        Multi-agent environments where context, instructions, data, or objectives pass between agents without reliable provenance.

·        Environments where human and agent actions share the same identity, application, browser session, connector, or audit trail.

·        Platforms that do not preserve complete prompts, retrieved content, task plans, rejected actions, approval parameters, tool arguments, returned data, runtime execution, or resulting state.

·        Browser and computer-use environments where consequential actions occur through graphical interfaces without structured tool-call telemetry.

·        Environments with incomplete SaaS read auditing, weak process-to-network attribution, limited endpoint or agent-runtime visibility, short retention, local-only logging, or unsynchronized timestamps.

·        Agents supporting finance, payroll, procurement, legal, human resources, customer operations, executive communications, identity administration, security operations, software delivery, cloud administration, regulated data, or customer-facing services.

·        Shared enterprise content, repositories, knowledge bases, workflow templates, rules, automations, Jira projects, Confluence spaces, and SaaS objects capable of influencing multiple agents, users, tenants, or business units.

Systems that remain operational after suspicious agent behavior because continued workflow functionality may conceal selective data access, unauthorized changes, operating-system command execution, persistent influence, connected-SaaS data exposure or exfiltration, or downstream propagation.

S14 — Sectors / Countries Affected

Sectors Affected

·        Technology, SaaS, software, cloud-service, telecommunications, managed-service, cybersecurity, digital-platform, AI-platform, and data-service organizations deploying connected enterprise agents or autonomous workflows.

·        Financial services, banking, insurance, payment, fintech, accounting, investment, and procurement organizations using agents for transaction review, customer operations, analysis, approval, communication, or administrative activity.

·        Healthcare, life sciences, pharmaceutical, medical-device, research, and health-service organizations using agents to access clinical, patient, research, regulated, operational, or administrative information.

·        Legal, consulting, professional-services, audit, tax, and advisory organizations using agents for document review, research, communications, client services, case management, knowledge retrieval, or regulated records.

·        Retail, ecommerce, hospitality, travel, media, marketing, publishing, entertainment, and customer-service organizations using agents for customer interaction, personalization, content, commerce, communications, and operational workflows.

·        Government, defense, public-sector, education, nonprofit, research, and regulated-service organizations using agents for public services, analysis, administration, workforce support, information processing, or decision support.

·        Manufacturing, industrial, energy, utilities, aerospace, engineering, transportation, logistics, and supply-chain organizations using agents for operations, maintenance, procurement, engineering, documentation, partner access, or administrative automation.

·        Human-resources, recruiting, payroll, benefits, employment-service, and workforce-management organizations using agents to process employee, applicant, compensation, performance, or regulated employment information.

·        Software-development, DevOps, platform-engineering, cloud-operations, identity, security-operations, and incident-response teams using agents with access to code, repositories, pipelines, cloud resources, identity systems, or security controls.

·        Managed-service providers, consultants, integrators, agent-platform providers, and service organizations whose AI-enabled workflows connect to multiple customer environments.

·        Large enterprises, distributed organizations, multinational businesses, government contractors, hybrid-cloud operators, and regulated environments with extensive SaaS estates and complex downstream dependencies.

Countries Affected

·        Global.

·        Exposure is not limited to one country or region because enterprise AI agents, SaaS platforms, cloud services, OAuth applications, collaboration tools, repositories, financial systems, and connected business workflows are deployed globally.

·        Countries with large technology, cloud, financial, healthcare, government, defense, research, ecommerce, managed-service, and software-development ecosystems may face elevated operational exposure.

·        Cross-border SaaS processing, multinational identities, globally distributed workforces, centralized administration, international customer platforms, shared data repositories, and distributed service-provider relationships can expand investigation, legal, privacy, and containment scope.

·        Country-specific impact should be assessed through agent authority, data sensitivity, business criticality, affected individuals, data residency, regulatory obligations, identity exposure, connected systems, telemetry maturity, and local incident-response capability rather than geography alone.

S15 — Adversary Capability Profiling

Capability Level

Moderate to High

Technical Sophistication

Adversaries require sufficient capability to place or influence content that an enterprise agent is likely to retrieve, understand how the agent interprets instructions and external data, identify available tools or connectors, and shape content that changes the agent’s task, authorization context, or action parameters.

Lower-complexity activity may use public prompt-injection examples, copied instruction patterns, malicious email or documents, poisoned webpages, repository comments, shared files, ordinary SaaS content, false approval claims, direct tool instructions, or readily available demonstrations.

Higher-capability activity may involve multi-stage instruction design, fragmented or indirect goal manipulation, model- and framework-aware content, tool-schema analysis, connector enumeration, approval-context manipulation, multi-agent propagation, persistent knowledge poisoning, parameter mutation, identity switching, browser automation, code execution, low-volume data transfer, security-control impairment, and cleanup intended to obscure the originating content and downstream action chain.

Infrastructure Maturity

Low to Moderate

Infrastructure requirements may be limited because adversaries can use ordinary email, documents, webpages, tickets, repositories, collaboration systems, file-sharing services, customer-submitted content, public websites, or compromised enterprise content to influence an agent.

Lower-maturity activity may rely on one malicious document, message, webpage, ticket, repository entry, shared file, or public content item without dedicated command infrastructure.

Higher-maturity activity may use compromised accounts, trusted websites, cloud platforms, repositories, SaaS tenants, customer portals, partner systems, dynamic content, redirect chains, staged instructions, multiple content sources, external APIs, webhooks, and infrastructure designed to resemble legitimate enterprise communication or integration activity.

Operational Scale

Single-agent influence to multi-agent, multi-SaaS, or enterprise-wide compromise

Operational scale ranges from suspicious content exposure or a blocked tool request affecting one agent session to broad enterprise impact when manipulated behavior causes sensitive-data exposure, identity changes, financial activity, SaaS modification, code or deployment changes, persistent influence, or propagation into additional agents and workflows.

Within one organization, scale may expand from one altered task into unauthorized access or modification across multiple mailboxes, drives, repositories, customer systems, cloud platforms, identity services, financial applications, security systems, business units, tenants, or customer environments.

Shared identities, broad OAuth applications, common connectors, centralized knowledge bases, reusable workflows, enterprise-wide agent templates, shared automation, multi-agent orchestration, and managed-service relationships may increase impact beyond the originating agent.

Escalation Likelihood

High

Escalation likelihood is high when an affected agent possesses write-capable, externally communicative, identity-sensitive, financial, security-sensitive, destructive, or administrative functions.

Escalation likelihood increases when untrusted content is followed by material task-plan change, new connector use, sensitive-data access, recipient or destination changes, approval mismatch, repeated denied-action retries, cross-system transfer, permission changes, identity creation, workflow modification, code changes, financial activity, persistent-context modification, concealment, or propagation to another agent.

Escalation likelihood is highest when agents use broad delegated authority, shared identities, persistent sessions, unrestricted connectors, code execution, browser automation, weak approval binding, incomplete SaaS audit coverage, poorly governed memory or knowledge sources, and access to sensitive or business-critical systems.

S16 — Targeting Probability Assessment

Overall Targeting Probability

High

Targeting Drivers

·        Enterprise AI agents increasingly process untrusted content as part of ordinary business workflows.

·        Agents may retrieve content automatically without the user reviewing every source object.

·        Public documentation, demonstrations, agent frameworks, connector catalogs, tool schemas, and implementation examples may reduce the effort required to understand agent behavior.

·        Malicious content can be delivered through ordinary email, documents, webpages, tickets, chat, repositories, comments, images, API responses, and shared files.

·        Trust injection may not require software exploitation, malware deployment, account compromise, or dedicated attacker infrastructure.

·        Enterprise agents may possess broad access across multiple SaaS platforms and data repositories.

·        Delegated permissions, OAuth scopes, service identities, and persistent sessions may exceed the minimum authority required for the task.

·        Agents may perform actions under identities and applications already trusted by the organization.

·        Tool-call arguments, recipients, destinations, and data scope may be derived from retrieved content.

·        Approval controls may not preserve or validate the exact final parameters executed.

·        Browser automation and computer-use agents may reach functions unavailable through structured connectors.

·        Code-execution tools and local runtimes may expose files, credentials, browser sessions, internal services, cloud metadata, and operating-system functions.

·        Sensitive information may be retrieved from one system and transferred through another.

·        Multi-agent systems may propagate contaminated context or objectives across workflows.

·        Persistent memory, knowledge bases, shared content, templates, rules, and workflows may allow one successful influence event to affect future tasks.

·        Incomplete prompt, planning, approval, read-access, tool-call, and resulting-state telemetry may reduce the likelihood of rapid detection.

·        Shared identities and pooled connectors may weaken attribution.

·        Legitimate enterprise automation may provide cover for unusual cross-platform activity.

·        Removing the initiating content may not reverse actions already completed or remove persistent downstream influence.

·        Targeting probability should be assessed through content exposure, agent authority, connector reach, approval design, data sensitivity, business criticality, persistence capability, multi-agent propagation, telemetry maturity, and local evidence of content-to-action behavior rather than model adoption or prompt count alone.

Most Likely Targets

·        Enterprise agents that automatically retrieve or summarize externally controlled email, documents, webpages, tickets, chat, repositories, code, or customer-submitted content.

·        Agents connected to email, file storage, collaboration, ticketing, customer, financial, human-resources, legal, identity, cloud, development, or security platforms.

·        Agents using broad OAuth scopes, delegated user authority, persistent sessions, shared service identities, service principals, or unrestricted connectors.

·        Agents capable of sending, sharing, uploading, deleting, approving, purchasing, paying, deploying, publishing, inviting, granting, revoking, elevating, disabling, or administering.

·        Multi-agent systems and autonomous workflows that pass context, objectives, data, or tool results between agents.

·        Agents that can alter saved instructions, memory, knowledge sources, workflows, templates, rules, policies, automations, or connector settings.

·        Browser and computer-use agents capable of interacting directly with SaaS and administrative interfaces.

·        Code agents and local runtimes with access to repositories, source code, pipelines, credentials, environment variables, filesystems, cloud resources, or internal services.

·        Finance, procurement, payroll, legal, human-resources, customer-service, identity, cloud-administration, security-operations, DevOps, and executive-support workflows.

·        Environments where human and agent activity share the same user, application, connector, session, or service identity.

·        Platforms with incomplete prompt, planning, rejected-action, approval, read-access, data-return, or resulting-state telemetry.

·        Organizations using common agent templates, centralized knowledge bases, reusable workflows, shared connectors, enterprise-wide applications, or managed agent services.

·        Environments with weak recipient restrictions, destination restrictions, approval binding, connector governance, persistent-context versioning, data-loss prevention, or action-level audit logging.

·        Agents with access to regulated data, customer records, employee information, financial systems, source code, security findings, credentials, secrets, cloud administration, or customer-facing content.

·        Environments with short retention, local-only logs, unsynchronized timestamps, limited SaaS audit access, weak endpoint visibility, or delayed incident-response access.

S17 — MITRE ATT&CK Chain Flow Mapping

Stage 1 — Enterprise Information Access

The adversary-influenced agent may access information from connected mailboxes, collaboration systems, file stores, repositories, customer platforms, knowledge systems, or other enterprise data sources.

·        T1213 — Data from Information Repositories

Stage 2 — Valid-Identity and Authorized-Connector Use

The agent may perform consequential activity through a valid user, service account, service principal, managed identity, OAuth application, delegated session, or approved connector identity.

·        T1078 — Valid Accounts

Stage 3 — Conditional Account or Permission Manipulation

The agent may create or modify accounts, applications, roles, groups, permissions, credentials, OAuth grants, service identities, or other access relationships when the influenced workflow targets identity or authorization state.

·        T1098 — Account Manipulation

Stage 4 — Conditional Data Transfer Through Web Services

The agent may transmit, upload, share, post, or otherwise transfer enterprise information through connected web services, including SaaS applications, web-accessible repositories, cloud services, web APIs, or other externally hosted web platforms.

·        T1567 — Exfiltration Over Web Service

Stage 5 — Conditional Enterprise Data Manipulation

The agent may alter messages, files, records, source code, configuration, customer-facing content, automated decisions, financial records, security data, or other enterprise information.

·        T1565 — Data Manipulation

S18 — Attack Path Narrative (Signal-Aligned Execution Flow)

Enterprise AI Agent Trust Injection and Connected SaaS Autonomous Insider Risk begins when adversary-controlled, compromised, or insufficiently trusted content enters an enterprise agent’s working context and materially influences how the agent interprets its task. The core attack path is progression from adversarial-content exposure into instruction influence, task-goal redirection, altered tool or connector use, delegated-authority misuse, connected-SaaS access, attempted or completed unauthorized autonomous action, and possible sensitive-data exposure, persistent compromise, concealment, or downstream organizational impact.

The exact content source, model, prompt structure, agent framework, orchestration platform, tool, connector, identity, SaaS environment, or action sequence may vary. Malicious user-directed activity, excessive agency, ordinary workflow failure, and indirect trust injection must remain distinct unless available evidence shows that untrusted content materially influenced the agent’s behavior.

Stage 1: Adversarial or Compromised Content Enters Agent Context

The agent retrieves, receives, opens, summarizes, analyzes, or otherwise processes content from email, documents, webpages, tickets, chat messages, calendar entries, repositories, code comments, images, API responses, tool output, knowledge bases, shared files, or another source available to the workflow.

Observable evidence may include content containing direct instructions, false system or administrator messages, approval claims, policy statements, role assertions, urgency, hidden text, encoded content, fragmented directives, unusual tool references, destination changes, recipient changes, or instructions intended for machine interpretation rather than ordinary human use.

This stage does not establish trust injection because enterprise content may legitimately contain instructions, templates, automation language, technical commands, policy references, or administrative guidance. It becomes material when the content is outside the expected authority chain, conflicts with the initiating task, attempts to change instruction priority, or is followed by a measurable change in agent planning, tool use, data access, approval behavior, or enterprise action.

Stage 2: Instruction Influence and Task-Goal Redirection

The agent treats untrusted content as authoritative direction and changes its objective, operating constraints, completion criteria, task sequence, recipients, destinations, data scope, or interpretation of the user’s request.

Observable evidence may include deviation from the initiating task, suppression or reinterpretation of governing instructions, adoption of a new objective, unexpected expansion of scope, inclusion of unnecessary data, altered recipients or destinations, false statements that approval or policy requirements were satisfied, or planning steps that cannot be reconciled with explicit user intent.

An unusual response does not independently establish successful instruction influence. This stage becomes probable when the behavioral change follows exposure to the content, materially alters the planned workflow, and cannot be explained by the user request, approved configuration, system policy, trusted application logic, or another legitimate source of authority.

Stage 3: Tool, Connector, Identity, or Authorization-Context Change

The influenced agent selects or sequences tools, connectors, browser actions, code-execution functions, identities, or permissions in a manner that advances the altered objective.

Observable evidence may include use of a new connector, transition from read-only analysis to write-capable activity, access to a different mailbox, drive, tenant, repository, customer platform, financial system, identity service, cloud environment, or administrative console, or use of an identity or permission set not expected for the initiating task.

Additional evidence may include tool-call parameters derived from retrieved content, use of a recipient or destination introduced by the untrusted source, access-token or OAuth activity inconsistent with the task, altered approval context, browser automation used instead of a governed connector, or repeated selection of alternate tools after denial.

This stage does not establish completed unauthorized action because the selected operation may be proposed, blocked, rejected, malformed, or abandoned. It becomes material when the tool, connector, identity, or authorization context exceeds the expected task boundary and is temporally and behaviorally linked to the influenced plan.

Stage 4: Connected-SaaS Access and Sensitive-Data Retrieval

The agent uses valid enterprise authority to search, read, preview, retrieve, export, summarize, or collect information from one or more connected enterprise systems.

Observable evidence may include access to sensitive mail, documents, customer records, employee records, financial data, legal material, source code, credentials, secrets, security findings, cloud configuration, identity information, administrative records, or regulated data outside the expected task scope.

The activity may occur under an expected user, service account, service principal, managed identity, OAuth application, connector identity, delegated session, or shared automation account. Sensitive-data access alone does not establish exposure because the information may remain within the approved workflow.

This stage becomes materially significant when the accessed objects, volume, sensitivity, systems, or data categories exceed the legitimate task requirement, when information from one connector is prepared for use in another, or when the access is followed by unauthorized transfer, modification, decision-making, or administrative action.

Stage 5: Attempted, Blocked, Partial, or Completed Unauthorized Autonomous Action

The agent attempts or performs an action that is inconsistent with explicit user intent, the approved workflow, organizational policy, or the exact parameters reviewed during approval.

Observable evidence may include unauthorized sending, sharing, uploading, posting, publishing, deleting, modifying, approving, purchasing, paying, deploying, inviting, granting, revoking, elevating, disabling, or administering. Activity may involve messages, files, records, users, groups, roles, permissions, applications, OAuth grants, tokens, workflows, source code, deployments, transactions, security controls, customer-facing content, or cloud resources.

The outcome must be classified according to the available evidence:

·        Attempted tool misuse when a prohibited or unauthorized action was requested but not executed.

·        Blocked autonomous action when controls prevented the action before material state changed.

·        Partially completed unauthorized action when one or more consequential steps occurred before the workflow failed, was denied, cancelled, or stopped.

·        Unauthorized autonomous action when the agent successfully performed a consequential action outside valid intent or authority.

A denied final step does not establish that the workflow was fully blocked. This stage becomes critical when resulting SaaS, identity, financial, code, cloud, security, or business state confirms unauthorized impact.

Stage 6: Persistent Influence, Concealment, and Downstream Organizational Impact

The adversary or influenced agent creates durable behavior-changing content, propagates contaminated context, conceals material actions, or extends impact into additional agents, users, workflows, systems, tenants, or business processes.

Observable evidence may include changes to saved instructions, memory, knowledge bases, vector stores, templates, policies, workflow definitions, rules, automations, shared documents, repositories, tickets, connector settings, identities, permissions, or SaaS objects capable of influencing future tasks.

Propagation may involve transfer of contaminated instructions, data, objectives, summaries, or tool results into another agent, workflow, tenant, business unit, repository, mailbox, customer environment, or managed-service relationship. Concealment may include omission of consequential actions from the user-visible response, false completion statements, deletion of messages or files, alteration of records, prompt or session removal, audit impairment, or security-control changes.

This stage becomes critical when influence survives session termination or agent restart, recurs in later tasks, affects additional agents or users, results in sensitive-data exposure, identity compromise, financial loss, code or deployment changes, security-control impairment, customer or workforce harm, destructive activity, legal or regulatory exposure, or prolonged operational disruption.

S19 — Attack Chain Risk Amplification Summary

Enterprise AI Agent Trust Injection and Connected SaaS Autonomous Insider Risk amplifies enterprise exposure because one content object may influence an authorized agent and produce consequential activity across multiple enterprise platforms. The chain becomes materially more dangerous when untrusted content is followed by task-goal redirection, authorization expansion, sensitive-data access, approval mismatch, unauthorized enterprise-state modification, persistent influence, concealment, or downstream propagation.

·        Routine content processing increases exposure because ordinary business information may contain machine-targeted instructions.

·        Weak separation between authoritative instructions and untrusted data increases manipulation risk.

·        Broad connector access increases blast radius because one agent may reach multiple sensitive platforms.

·        Delegated user or application authority increases business risk because unauthorized activity may appear to have been performed by a valid employee or approved service.

·        Shared identities, pooled connectors, and common OAuth applications increase attribution difficulty.

·        Transition from read-only activity into write-capable, externally communicative, identity-sensitive, financial, destructive, or administrative action increases consequence.

·        Tool-call parameters derived from untrusted content increase authorization risk because recipients, destinations, resources, identities, or data scope may no longer reflect the initiating task.

·        Approval controls not bound to final executed parameters increase uncertainty over whether the resulting action was authorized.

·        Multi-step workflows increase partial-impact risk because consequential state changes may occur before final denial.

·        Cross-system data movement increases confidentiality and scoping risk because the initiating content, accessed data, transfer path, and resulting action may appear in separate platforms and logs.

·        Browser automation and computer-use capabilities may bypass structured connector policy and action logging.

·        Code execution and local runtimes may expand impact into endpoints, files, credentials, browser sessions, internal services, or cloud metadata.

·        Missing planning, read-access, approval, identity, and resulting-state telemetry increases investigative uncertainty.

·        Persistent context and multi-agent propagation increase recurrence and scale.

·        Repeated attempts after denial increase confidence that the workflow is pursuing an unauthorized objective rather than encountering an ordinary error.

·        Misleading completion reporting may create false assurance when consequential actions are omitted or misrepresented.

·        Security-control or audit changes increase containment difficulty.

·        Restarting an agent, deleting a session, or revoking one connector may create false closure when altered state, copied data, created identities, persistent content, or downstream effects remain.

·        Continued workflow functionality increases dwell risk because selective unauthorized activity may occur while the agent continues completing legitimate tasks.

·        Delayed discovery increases investigation difficulty because prompts, retrieved content, sessions, tokens, browser state, tool calls, and temporary workflow artifacts may no longer be available.

·        Response burden increases because teams may need to reconstruct human intent, agent planning, tool execution, data access, approval validity, identity use, SaaS changes, persistent influence, and downstream business impact across multiple platforms.

S20 — Tactics, Techniques, and Procedures

Figure 3

Adversarial Content Placement

Adversaries may place machine-targeted instructions within email, documents, webpages, tickets, chat messages, calendar entries, repositories, code comments, images, API responses, tool output, knowledge sources, shared files, or other content accessible to an enterprise agent.

This behavior becomes risk-relevant when the content attempts to change instruction priority, task goals, recipients, destinations, data scope, tool selection, approval interpretation, or completion criteria.

False Authority, Policy, and Approval Impersonation

Adversaries may present content as a system message, administrator instruction, security requirement, legal directive, compliance rule, approved exception, or previously authorized action.

This behavior becomes materially significant when the agent adopts the claimed authority, overrides a restriction, changes its plan, or performs an action that cannot be linked to a valid policy or approving authority.

Instruction Fragmentation and Machine-Oriented Obfuscation

Adversaries may divide instructions across multiple documents, messages, retrieved chunks, comments, images, or tool results. They may use hidden text, markup, metadata, encoding, multilingual content, symbolic substitutions, recursive references, or content structured for machine interpretation.

This behavior becomes high priority when separately retrieved objects combine into an unauthorized objective or decoded content changes the agent’s plan, tool use, or enterprise action.

Task-Goal Redirection

Adversaries may cause an agent to depart from the initiating request and pursue a new objective involving expanded scope, changed recipients or destinations, additional data access, or consequential action.

This behavior becomes high priority when the revised objective cannot be explained by explicit user intent, approved workflow logic, policy, or trusted system instructions.

Tool, Connector, Identity, and Permission Enumeration

Adversaries may direct or induce the agent to identify available tools, connectors, permissions, identities, mailboxes, drives, repositories, SaaS applications, administrative functions, or sensitive data sources.

Enumeration may occur through direct requests, trial tool calls, schema inspection, error analysis, help functions, staged tasks, or repeated workflow changes. This behavior becomes materially significant when discovery is followed by access to a new system, privilege boundary, data source, or high-impact function.

Read-to-Write Workflow Escalation

Adversaries may redirect a summarization, research, classification, review, or retrieval task into a send, share, upload, modify, delete, approve, deploy, purchase, pay, grant, revoke, or administrative action.

This behavior becomes high priority when a low-risk initiating task transitions into a consequential function without explicit user intent or valid approval.

Tool-Call and Approval-Parameter Manipulation

Adversaries may influence recipients, destinations, object identifiers, file paths, tenants, identities, data scope, permission levels, transaction values, deployment targets, or other action parameters. They may also falsely state that approval has occurred, conceal material parameters, or cause the agent to reuse approval for a materially different action.

This behavior becomes materially significant when final parameters differ from the initiating request, trusted system-of-record values, or the parameters reviewed during approval.

Alternate-Tool and Control-Bypass Attempts

Adversaries or influenced agents may pursue a denied objective by selecting another connector, changing identities, modifying parameters, using browser automation, invoking code execution, switching APIs, or dividing the action into smaller steps.

This behavior becomes materially significant when retries preserve the same unauthorized objective despite policy denial, approval rejection, connector failure, or tool restriction.

Connected-SaaS Data Access

Adversaries may cause an agent to search, preview, read, retrieve, export, summarize, or collect sensitive information from connected mailboxes, drives, collaboration systems, customer platforms, financial applications, human-resources systems, legal platforms, repositories, cloud services, identity systems, or security tools.

This behavior becomes high priority when accessed data exceeds the task requirement, involves sensitive or regulated categories, or is prepared for downstream transfer or action.

Cross-Connector Data Transfer

Adversaries may cause an agent to retrieve information through one connector and transmit, upload, post, share, summarize, encode, modify, or act on it through another.

Data may be transformed, fragmented, translated, compressed, or embedded before transfer. This behavior becomes materially significant when the destination, recipient, data scope, or business purpose is unauthorized or cannot be reconciled with the initiating task.

Unauthorized Communication and Enterprise-State Modification

Adversaries may cause the agent to send email, post messages, publish content, create tickets, generate external links, alter files or records, change permissions, create identities or applications, modify workflows, update code or configuration, or perform administrative actions.

This behavior becomes critical when the resulting state is inconsistent with explicit user intent, approved workflow, policy, or reviewed parameters.

Financial and Transactional Action

Adversaries may cause an agent to initiate, approve, modify, or cancel purchases, payments, refunds, invoices, payroll actions, procurement activity, account changes, or other financial transactions.

This behavior becomes critical when values, recipients, accounts, beneficiaries, approvals, or transaction purposes are inconsistent with the authorized business process.

Persistent Context and Workflow Manipulation

Adversaries may cause the agent to store behavior-changing content in memory, saved instructions, knowledge bases, vector stores, templates, policies, rules, shared documents, repositories, tickets, workflows, scheduled actions, or connector settings.

This behavior becomes high priority when the content influences later sessions, survives agent restart, affects additional users, or continues directing unauthorized activity after the initiating source is removed.

Multi-Agent and Workflow Propagation

Adversaries may use one influenced agent to pass contaminated instructions, data, objectives, summaries, or tool results to another agent or automated workflow.

This behavior becomes materially significant when propagation expands the affected identities, tools, tenants, systems, users, or business processes or obscures the original source of influence.

Browser, Computer-Use, and Local Runtime Abuse

Adversaries may cause an agent to interact directly with graphical interfaces, use existing browser sessions, navigate administrative portals, submit forms, execute code, access files, retrieve credentials, use environment variables, reach internal services, or interact with cloud metadata.

This behavior becomes critical when it bypasses connector governance, approval controls, action logging, recipient restrictions, or API-level policy enforcement.

Security-Control Impairment

Adversaries may cause an agent to modify data-loss-prevention rules, information-protection settings, conditional access, connector restrictions, approval requirements, logging, retention, SIEM forwarding, endpoint controls, cloud policies, repository protections, or SaaS security settings.

This behavior becomes high priority when control changes follow instruction influence, unauthorized access, repeated denials, data transfer, or activity intended to reduce visibility or prevent containment.

Concealment and Misleading Completion Reporting

Adversaries or influenced agents may omit consequential actions from the user-visible response, minimize warnings, falsely report that no action occurred, alter records, delete messages or files, remove session history, or present an unauthorized result as normal task completion.

This behavior becomes materially significant when user-visible output conflicts with tool, connector, identity, SaaS, browser, endpoint, or network evidence.

Artifact and Evidence Removal

Adversaries may cause the agent to delete prompts, messages, files, records, tickets, workflow history, logs, browser artifacts, temporary data, tool outputs, or SaaS objects. They may disable auditing, alter retention, overwrite shared content, revoke investigator access, or destroy short-lived workloads.

This behavior becomes high priority when cleanup follows unauthorized access, data transfer, state modification, persistent influence, or security-control impairment.

Downstream Organizational Expansion

Adversaries may use altered identities, permissions, workflows, tokens, connectors, source code, deployments, customer communications, financial processes, or persistent content to affect additional systems and business operations.

This behavior becomes critical when downstream activity is linked to the originating content-to-action chain through shared identities, objects, recipients, destinations, sessions, connectors, workflow lineage, or bounded time.

Operational Blending With Legitimate Agent and SaaS Activity

Adversaries may blend unauthorized behavior into ordinary summarization, search, synchronization, reporting, customer support, software development, security operations, administration, migration, backup, workflow automation, or incident-response activity.

This blending is effective because legitimate agents may read sensitive data, use multiple connectors, update records, send messages, execute code, or perform administrative functions. Detection and response require correlation across content, agent planning, tool calls, approval records, identity, connector activity, SaaS state, browser actions, endpoint evidence, network activity, change records, and business context.

S20A — Adversary Tradecraft Summary

Enterprise AI Agent Trust Injection and Connected SaaS Autonomous Insider Risk exploits the trust relationships among enterprise content, agent instructions, task planning, delegated identities, OAuth applications, connectors, SaaS platforms, browser sessions, code-execution environments, persistent context, and downstream business systems. The adversary objective is to convert content access into behavioral influence and then use legitimate enterprise authority to obtain data, alter state, perform consequential actions, preserve influence, or expand into additional systems while blending the activity into normal agent and SaaS operations.

·        The core tradecraft pattern is adversarial-content exposure followed by probable instruction influence, altered tool or authorization use, and attempted or completed unauthorized autonomous action.

·        The behavior is not dependent on one prompt phrase, model, framework, tool, connector, SaaS platform, identity, recipient, destination, campaign, actor, or proof-of-concept implementation.

·        Adversaries may use direct instructions, false authority, policy impersonation, hidden content, encoding, fragmentation, indirect goal manipulation, parameter influence, or multi-object instruction assembly.

·        Suspicious content does not establish successful trust injection without evidence that the agent’s behavior materially changed.

·        An unusual response does not establish unauthorized action without supporting planning, tool, connector, identity, SaaS, or resulting-state evidence.

·        A generated tool call does not establish execution, and a denied final action does not establish that no earlier impact occurred.

·        Valid identity and connector use do not establish authorization when the action is inconsistent with explicit user intent or approved scope.

·        Approval does not establish authorization when the executed action or parameters differ from what the user reviewed.

·        Sensitive-data access does not establish exposure without evidence of unauthorized transfer, sharing, downstream use, modification, or action.

·        Cross-connector activity may be legitimate and requires task, identity, approval, data-scope, recipient, destination, and business-context correlation.

·        Browser and computer-use agents may bypass structured connector controls and produce limited machine-readable execution telemetry.

·        Code-execution environments may extend impact into endpoints, files, credentials, cloud metadata, internal services, and operating-system functions.

·        Persistent influence may rely on memory, saved instructions, knowledge sources, workflows, rules, shared content, connector settings, or SaaS objects.

·        Persistent compromise may rely on created identities, permissions, tokens, OAuth grants, automated workflows, or other durable access mechanisms.

·        Multi-agent propagation may obscure the original content source as instructions, data, or objectives move between systems.

·        Concealment may rely on misleading completion reporting, omission of actions, record deletion, audit impairment, or security-control modification.

·        A functioning agent or successful business workflow does not establish trust because selective unauthorized activity may occur while expected operations continue.

·        Detection requires correlation across content provenance, agent planning, tool and connector use, approval parameters, identity, OAuth, SaaS access, data movement, resulting state, persistent context, browser activity, endpoint telemetry, network activity, and downstream effects.

·        Response requires treating confirmed activity as an agent, identity, data, SaaS, workflow, and enterprise-trust incident rather than only as a suspicious prompt, unsafe response, or isolated connector event.

·        The tradecraft remains durable because the adversary objective is to exploit enterprise authorization and agent decision-making regardless of the specific content source, model, tool, connector, identity, platform, or downstream target used.

S21 — Detection Strategy Overview

Detection Philosophy

Detection for Enterprise AI Agent Trust Injection and Connected SaaS Autonomous Insider Risk must treat the activity as a staged trust-manipulation-to-authorized-action chain rather than an isolated prompt-injection indicator, unusual model response, connector request, SaaS audit event, or anomalous agent-generated action.

The primary detection objective is to identify progression from adversary-controlled or compromised content entering an enterprise agent’s working context through instruction-precedence manipulation, task-goal redirection, tool-selection influence, authorization misuse, connected-SaaS access, unauthorized autonomous action, sensitive-data exposure, persistence, and downstream organizational impact.

The strongest detection value comes from correlating AI gateway, agent-runtime, orchestration, retrieval, tool-call, connector, identity, OAuth, approval, policy-enforcement, SaaS audit, data-access, collaboration, email, source-control, cloud, browser, endpoint, and network telemetry. No single signal should confirm compromise. Agents routinely process external content. Retrieved documents may contain imperative language. Approved workflows may access multiple platforms. Connectors may perform high-volume reads and writes. Agents may revise a task plan as new information becomes available.

Confidence should increase only when multiple stages align and cannot be explained by explicit user intent, approved automation, documented agent behavior, connector synchronization, attributable human approval, administrative activity, testing, evaluation, red teaming, deployment, maintenance, or incident response.

The detection model must remain behavior-driven and variant-resilient. It must not depend on one model, vendor, agent framework, prompt phrase, injection string, document type, hidden-text method, encoding method, tool name, connector, API endpoint, SaaS platform, recipient, destination, browser, user agent, model response, or post-action artifact.

Detection must preserve the distinction between adversarial-content exposure, suspected trust injection, probable instruction influence, attempted tool misuse, blocked high-impact action, unauthorized autonomous action, persistent compromise, and confirmed downstream impact.

A malicious user intentionally directing an authorized agent to perform harmful activity is not evidence of trust injection unless untrusted content or an external source materially altered the agent’s instructions, task plan, tool selection, authorization context, or downstream action.

An unsafe or unauthorized action caused by excessive agency, weak permissions, missing approval controls, or flawed workflow design is not evidence of successful trust injection unless adversarial content materially influenced the action. The detection model must support both outcomes while preserving separate root-cause classifications.

Primary Detection Anchors

·        An enterprise AI agent retrieves, opens, indexes, summarizes, interprets, or processes externally controlled content containing instructions, role claims, policy claims, approval claims, tool directives, encoded commands, hidden text, or action requests inconsistent with the initiating task.

·        Untrusted content attempts to redefine the agent’s role, priorities, system instructions, approval requirements, confidentiality rules, tool permissions, recipient restrictions, destination restrictions, or completion criteria.

·        Retrieved content instructs the agent to ignore, override, reinterpret, conceal, or bypass prior instructions, policy controls, human approval, data-handling restrictions, or tool-use limitations.

·        The agent’s task plan, action sequence, selected tools, connector sequence, data scope, recipients, destinations, or intended outcome changes materially after the content is processed.

·        A read-only, analytical, or summarization task transitions into message sending, file sharing, permission modification, record deletion, user creation, credential retrieval, workflow execution, code change, deployment, purchase, payment, or administrative action.

·        The agent invokes a write-capable, externally communicative, destructive, financial, identity-sensitive, security-sensitive, or administrative function not required by the original task.

·        Tool-call parameters contain recipients, destinations, resource identifiers, data, instructions, or action values derived from untrusted content rather than the initiating request or an approved system-of-record value.

·        The agent accesses a SaaS platform, tenant, repository, mailbox, drive, channel, ticket system, customer platform, financial system, identity service, security platform, or administrative console outside the expected task scope.

·        The agent requests or receives broader OAuth scopes, connector permissions, API privileges, delegated access, application consent, or service-account authority than the task requires.

·        A connected-SaaS action occurs under a user, agent, application, or service identity without a corresponding explicit request, approved workflow, or attributable human confirmation.

·        Sensitive information obtained through one connector is transmitted, copied, summarized, embedded, uploaded, emailed, posted, shared, or written through another connector.

·        Tool output, retrieved content, email, document, ticket, code comment, chat message, calendar entry, webpage, repository artifact, or API response influences subsequent tool use in a manner inconsistent with the initiating task.

·        The agent submits internal data, credentials, tokens, prompts, retrieved records, tool results, or confidential content to an unapproved model, domain, recipient, application, webhook, repository, API, file-sharing service, or storage location.

·        The agent attempts to suppress approval, minimize user-visible disclosure, conceal material actions, delete evidence, alter records, or report successful completion without disclosing consequential activity.

·        Agent-generated changes create persistent influence through saved instructions, behavior-changing memory, knowledge bases, vector stores, workflow definitions, templates, rules, automations, connectors, shared documents, repository content, tickets, or SaaS configuration.

·        Poisoned content influences later agent sessions, additional users, another agent, or an automated workflow.

·        Multiple agents, tools, plugins, extensions, skills, connectors, or SaaS platforms propagate the same adversarial instruction, contaminated context, or unauthorized objective.

·        The agent repeatedly retries a blocked or denied operation by changing parameters, selecting another tool, using another connector, invoking browser automation, using another identity, or decomposing the operation into smaller steps.

·        A multi-step workflow creates an unauthorized or irreversible state before a later action is denied, blocked, canceled, or fails.

·        High-impact actions recur after the initiating content is removed, the original session ends, the connector is revoked, the workflow is paused, the agent is restarted, or remediation is attempted.

Detection Prioritization Model

·        Critical priority should be assigned when adversarial or untrusted content is followed by an unauthorized high-impact action in a connected SaaS, cloud, identity, financial, source-control, customer-management, communication, security, or administrative platform.

·        Critical priority should be assigned when an agent accesses sensitive enterprise data and transfers it to an unauthorized external recipient, tenant, destination, application, model, webhook, repository, API, or storage service.

·        Critical priority should be assigned when suspected trust injection results in user creation, privilege elevation, OAuth consent, token creation, permission modification, security-control impairment, code deployment, financial action, destructive activity, or organization-wide communication.

·        Critical priority should be assigned when an agent uses one trusted connector to obtain credentials, tokens, secrets, or sensitive records and another connector to act on, transmit, or expose them.

·        Critical priority should be assigned when an agent modifies behavior-changing memory, persistent instructions, workflow logic, tool permissions, approval requirements, connector configuration, policy controls, or knowledge sources to preserve unauthorized behavior.

·        Critical priority should be assigned when agent-driven activity affects multiple users, business units, repositories, mailboxes, tenants, SaaS platforms, customer environments, or downstream systems.

·        High priority should be assigned when an agent’s task plan changes materially after processing untrusted content and results in an unexpected write, send, share, delete, administrative, financial, identity, deployment, or security action.

·        High priority should be assigned when an agent accesses regulated, privileged, confidential, customer, employee, financial, legal, source-code, credential, security, or administrative data outside the expected task scope.

·        High priority should be assigned when an agent requests broader permissions, scopes, connector access, delegated authority, or identity privileges during or immediately after processing untrusted content.

·        High priority should be assigned when a low-risk task unexpectedly produces cross-connector data movement, external communication, persistent behavior change, workflow modification, code execution, or administrative operations.

·        High priority should be assigned when an agent bypasses, suppresses, repeatedly retries, or seeks alternatives to a denied tool call, policy decision, approval gate, recipient restriction, destination restriction, or data-handling control.

·        High priority should be assigned when a multi-step workflow creates a material state change before a later control blocks completion.

·        High priority should be assigned when agent actions cannot be linked to the initiating request, task identifier, approval event, policy decision, responsible owner, or authorized business workflow.

·        Medium priority should be assigned to external content containing likely trust-injection or agent-manipulation instructions when no material change in planning, tool selection, connector use, or downstream state is observed.

·        Medium priority should be assigned when an agent proposes or attempts an unauthorized high-impact action but no consequential state change occurs.

·        Medium priority should be assigned when tool calls, connector access, recipients, destinations, or data scope differ from the established baseline but remain within the identity’s authorized permissions.

·        Medium priority should be assigned when an agent repeatedly encounters denied actions, malformed tool requests, policy failures, connector errors, or approval rejections after processing untrusted content.

·        Lower priority should be assigned to isolated injection indicators, unusual model responses, connector errors, or tool-call anomalies that align with approved testing, evaluation, administration, synchronization, user-directed automation, or documented agent behavior.

Correlation Strategy (Strict Enforcement)

Correlation must distinguish adversarial-content exposure, suspected trust injection, probable instruction influence, attempted tool misuse, blocked autonomous action, partially completed unauthorized action, unauthorized autonomous action, persistent compromise, sensitive-data exposure, and confirmed downstream impact.

Adversarial-content exposure may be established when an agent processes externally controlled or user-editable information, but it must not be promoted to suspected trust injection without material instruction, context, planning, policy, tool, or behavioral evidence.

Suspected trust injection should require an affected enterprise-agent context and one or more material instruction anomalies. Relevant anomalies include:

·        Instructions embedded in data presented as authoritative system, developer, administrator, security, compliance, legal, or user direction.

·        Requests to ignore, override, reveal, modify, suppress, or reinterpret higher-priority instructions.

·        Claims that approval, authorization, review, or policy validation already occurred when no corresponding event exists.

·        Instructions to conceal actions, suppress warnings, omit details, misrepresent results, or avoid informing the user.

·        Requests to retrieve, expose, transmit, alter, delete, or act on data unrelated to the initiating task.

·        Tool-use instructions embedded in documents, emails, webpages, code, comments, tickets, calendar entries, chat messages, file metadata, images, API responses, or tool results.

·        Encoded, obfuscated, hidden, low-visibility, multilingual, fragmented, recursively referenced, or machine-targeted instructions.

·        Requests to create behavior-changing memory, save new operating rules, modify workflows, alter policies, or influence later sessions.

·        Instructions directing the agent to another source containing additional action directives.

·        Content outside the organization’s established trusted-source and task-context baseline.

Probable instruction influence should require evidence that untrusted content materially affected agent behavior. Strong anchors include:

·        The task plan or action sequence changes after the content is processed.

·        The agent adopts goals, recipients, destinations, constraints, or completion conditions originating from external content rather than the initiating request or approved policy.

·        Tool selection changes from read-only or analytical functions to write-capable or high-impact functions.

·        The agent accesses a new connector, SaaS platform, tenant, repository, identity context, data category, or privilege set not required by the original task.

·        Tool parameters contain values derived from adversarial content rather than the user’s request, an approved configuration, or a validated system-of-record value.

·        The agent attempts to remove confirmation, approval, validation, recipient restriction, destination restriction, or review steps.

·        The agent’s user-visible response omits, minimizes, or contradicts material tool or SaaS activity.

·        Policy, authorization, approval, or connector telemetry records an action inconsistent with the initiating task.

Attempted tool misuse should require more than suspicious content or an anomalous model response. Strong anchors include:

·        A write-capable or high-impact tool request inconsistent with the user’s stated objective.

·        A tool request exceeding approved data, tenant, resource, recipient, destination, action, or privilege scope.

·        Use of a connector, application, identity, or service principal not normally associated with the agent, user, workflow, or task.

·        Repeated tool-call mutation after denial, validation failure, policy rejection, destination blocking, or approval refusal.

·        Attempts to invoke an alternate connector, browser session, API, code-execution environment, automation path, or identity to achieve the same denied objective.

·        Tool parameters containing secrets, sensitive data, unauthorized recipients, external destinations, destructive actions, privilege changes, persistence instructions, or security-control modifications.

·        Requests to enumerate additional tools, connector capabilities, permissions, tokens, identities, repositories, mailboxes, tenants, or accessible resources before taking action.

Blocked autonomous action should require evidence that a prohibited or unauthorized action reached an enforcement control and was prevented before any consequential state change occurred.

Partially completed unauthorized action should require evidence that one or more consequential steps executed before a later control denied, canceled, rolled back, or failed the remaining workflow. Partial completion must not be classified as fully blocked merely because the final intended outcome did not occur.

Unauthorized autonomous action should require evidence that an operation executed or materially changed enterprise state without valid user intent, approval, or policy authorization. Strong anchors include:

·        A message, email, post, invitation, notification, or external communication was sent.

·        A file, folder, record, ticket, repository, branch, workflow, application, or configuration was created, modified, shared, moved, or deleted.

·        A user, group, role, permission, OAuth grant, API token, application consent, service principal, access key, session, or identity object was created or changed.

·        Sensitive data was read, exported, downloaded, copied, uploaded, summarized, transmitted, shared, or exposed outside the approved task scope.

·        Code was committed, merged, executed, deployed, or used to modify production or security-sensitive systems.

·        A financial, procurement, customer, legal, human-resources, security, or administrative workflow was initiated or completed.

·        A security control, retention setting, audit configuration, alert, approval requirement, access policy, or logging path was modified or impaired.

·        Behavior-changing memory, persistent instructions, workflow logic, knowledge entries, templates, policies, automations, or connector settings were added or altered.

Approval evidence should be treated as valid only when the approving user, reviewed action, final parameter set, recipient, destination, resource, data scope, identity, time, and resulting execution can be correlated. A generic approval event must not validate an action whose final parameters changed after review.

Confirmed chain-aligned escalation should require evidence from at least two material stages unless direct audit or forensic evidence establishes unauthorized execution. Preferred correlation paths include:

·        Untrusted content containing agent-directed instructions followed by a material change in the task plan.

·        Suspected trust injection followed by selection of an unnecessary or higher-risk tool.

·        External-content processing followed by expanded connector, identity, privilege, or data access.

·        Tool-selection change followed by an unauthorized SaaS read, export, write, send, share, delete, permission, deployment, financial, or administrative action.

·        Sensitive-data retrieval through one connector followed by external transmission through another.

·        A denied operation followed by parameter mutation, alternate-tool selection, browser automation, code execution, or use of another identity.

·        A high-impact action approved for one parameter set followed by execution with materially different parameters.

·        A multi-step workflow producing an unauthorized state change before a later control blocks completion.

·        Agent-generated content followed by storage in behavior-changing memory, a knowledge base, shared document, ticket, repository, workflow, or automation that later influences another session.

·        Unauthorized SaaS activity followed by concealment, record deletion, history removal, misleading completion reporting, or suppression of user-visible evidence.

·        Credential or token access followed by downstream authentication, connector creation, API access, permission change, or privilege use.

·        Agent-driven configuration change followed by recurring unauthorized actions across later sessions, users, or agents.

·        One manipulated agent passing contaminated content or instructions to another agent that performs the consequential action.

Correlation must preserve the initiating user, agent owner, agent identity, model, model version, instruction version, policy version, task identifier, session identifier, trace identifier, retrieved-content identifier, source object, source tenant, connector, OAuth grant, tool name, normalized parameters, approval event, reviewed parameter set, executed parameter set, SaaS object, recipient, destination, identity, network session, and resulting-state relationships required to support attribution across layers.

Telemetry Prioritization

·        AI gateway, model-access gateway, enterprise-agent runtime, orchestration, planner, task, and session telemetry.

·        System, developer, user, retrieved-content, tool-result, behavior-changing memory, policy, and output-context classifications where available.

·        Prompt, response, model, model version, agent version, instruction version, policy version, timestamp, task identifier, session identifier, and trace identifier.

·        Retrieved-content source, owner, tenant, URL, document identifier, email identifier, message identifier, repository identifier, ticket identifier, trust classification, and retrieval timestamp.

·        Retrieval, search, indexing, vector-store, chunk, ranking, citation, and knowledge-base telemetry.

·        Agent task plan, step sequence, goal changes, tool-selection events, retries, exceptions, and completion state.

·        Tool name, connector name, function, normalized arguments, target resource, recipient, destination, action type, result, error, policy decision, and approval status.

·        Human confirmation, approval, denial, modification, cancellation, timeout, and exception events.

·        The exact parameters reviewed during approval and the exact parameters executed after approval.

·        OAuth consent, token issuance, scope, refresh, revocation, delegated access, application identity, service principal, API key, and connector-authorization telemetry.

·        Identity-provider, conditional-access, privileged-access, session, device, authentication, authorization, and risk telemetry.

·        SaaS audit events covering search, access, read, download, export, send, share, create, modify, delete, permission, user, role, configuration, workflow, application, and administrative activity.

·        Email, collaboration, file-storage, customer-management, ticketing, source-control, CI/CD, financial, human-resources, cloud, identity, security, and administrative-platform telemetry.

·        Data-loss prevention, information-protection, insider-risk, CASB, SaaS-security, and data-security posture events.

·        Browser, endpoint, local-agent, process, file, and network telemetry where agents use computer control, browser automation, code execution, local tools, or desktop applications.

·        DNS, proxy, firewall, API gateway, webhook, egress, flow, and network telemetry mapped to the responsible agent, connector, workload, process, application, or identity where available.

·        Prompt-injection, content-safety, model-security, policy-engine, tool-firewall, output-validation, and connector-security events.

·        Agent deployment, model update, instruction update, connector change, workflow change, policy change, evaluation, red-team exercise, maintenance, and incident-response records.

·        Audit-log deletion, forwarding interruption, policy disablement, connector removal, history deletion, behavior-changing memory alteration, and other anti-forensic telemetry.

Detection Design Constraints

·        Detection must not rely on one prompt phrase, injection string, language, encoding, model, agent framework, connector, tool, SaaS platform, or content type.

·        Detection must not assume that every imperative statement in retrieved content is malicious.

·        Detection must not classify trust injection solely from phrases such as “ignore previous instructions,” “system message,” “administrator,” “urgent,” or “confidential.”

·        Detection must distinguish adversarial instructions from quoted text, documentation, code samples, policy documents, security research, training material, and legitimate task content.

·        Detection must distinguish trust manipulation from ordinary model error, hallucination, task-planning failure, context loss, ambiguous user intent, and poorly designed automation.

·        Detection must distinguish malicious user direction from indirect trust injection.

·        Detection must distinguish excessive-agency failure from successful trust injection.

·        Detection must support unauthorized-action findings even when the exact root cause cannot be determined.

·        Detection must not infer successful compromise from a prompt-injection classifier alert without evidence of planning influence, tool misuse, unauthorized access, or state change.

·        Detection must not infer unauthorized SaaS action from agent planning or generated tool-call content when execution was blocked before any consequential state change.

·        Detection must not classify a partially completed workflow as fully blocked when earlier steps created material state changes.

·        Detection must validate whether the user explicitly requested, reviewed, approved, or reasonably expected the action.

·        Detection must verify that approval covered the final executed parameters rather than an earlier or materially different request.

·        Detection must account for approved agents that send messages, modify files, update tickets, execute code, deploy changes, process transactions, or administer SaaS platforms as part of their normal function.

·        Detection must account for legitimate cross-connector workflows, synchronization, enrichment, migration, backup, reporting, case management, incident response, and administrative automation.

·        Detection must not classify every multi-platform access sequence as suspicious.

·        Detection must validate data classification, business purpose, user authority, agent authority, connector scope, recipient, destination, and approval state.

·        Detection must not treat every denied, malformed, or retried tool call as malicious.

·        Detection must account for retries caused by schema mismatch, rate limiting, expired tokens, connector defects, network failures, service outages, or stale object references.

·        Detection must preserve the distinction between proposed action, requested tool call, blocked action, partially completed action, successful action, persistent modification, and downstream impact.

·        Detection must retain coverage when attackers change instruction wording, language, encoding, content source, retrieval path, model, agent, tool, connector, target platform, identity, action sequence, or concealment method.

·        Detection must account for attacks that produce no visibly malicious response and instead alter only tool use, data access, connector behavior, or downstream state.

·        Detection must account for attacks that use valid permissions, approved APIs, and legitimate enterprise functions without exploiting a software vulnerability.

·        Detection must not assume that the agent’s final explanation accurately represents all actions performed.

·        Detection must not treat an approved enterprise identity, application, connector, OAuth grant, service principal, or user session as inherently trustworthy.

Baseline and Deployment Requirements

·        Maintain an authoritative inventory of enterprise agents, assistants, copilots, autonomous workflows, models, model versions, runtimes, owners, business purposes, environments, and criticality.

·        Identify every data source, mailbox, drive, channel, repository, ticket system, database, SaaS platform, cloud service, API, browser, endpoint, tool, and connector each agent can access.

·        Classify each tool and connector as read-only, write-capable, externally communicative, destructive, financial, privileged, security-sensitive, identity-sensitive, or administratively consequential.

·        Record expected user populations, agent identities, service principals, OAuth applications, delegated permissions, scopes, tokens, API keys, connector owners, and tenant relationships.

·        Maintain mappings between each user, agent, model, session, task, connector, tool, OAuth grant, SaaS tenant, target resource, approval event, and downstream action.

·        Establish normal task types, content sources, tool sequences, connector combinations, data volumes, recipients, destinations, and action frequencies for each agent.

·        Define permitted and prohibited actions for each agent, connector, user role, data classification, environment, and business process.

·        Require independent policy enforcement outside the model for high-impact actions.

·        Require explicit human approval for destructive, financial, externally visible, identity-changing, security-changing, administrative, or irreversible operations unless a formally approved deterministic workflow exists.

·        Bind approvals to the exact action, final parameter set, recipient, destination, resource, data scope, identity, expiration time, and transaction context.

·        Require reapproval when material parameters change after review.

·        Preserve original or normalized security-relevant content where legally and operationally permissible.

·        Preserve tool-call arguments, policy decisions, approval states, connector responses, SaaS object identifiers, and resulting state.

·        Preserve consistent task, session, trace, retrieval, tool-call, approval, user, agent, identity, and SaaS audit identifiers across platforms.

·        Classify content sources as trusted, semi-trusted, user-controlled, externally controlled, compromised, or unverified.

·        Maintain approved recipient, destination, domain, webhook, repository, tenant, API, and data-transfer allowlists.

·        Maintain authoritative inventories of persistent instructions, behavior-changing memory, knowledge bases, vector stores, workflows, templates, policies, tools, and connector configurations.

·        Distinguish ordinary conversation retention from persistent content capable of modifying later agent behavior.

·        Forward agent, model, identity, connector, SaaS, cloud, browser, endpoint, network, policy, and approval logs to protected remote storage.

·        Test detection logic in hunt or audit mode before alert-mode deployment.

·        Validate expected behavior during model upgrades, instruction changes, agent releases, connector updates, workflow changes, synchronization, migration, backup, testing, red teaming, evaluation, and incident response.

·        Create exception handling for approved agents, service identities, automated workflows, administrative operations, security testing, and documented high-volume processes.

·        Retain sufficient history to establish first-seen content sources, tool sequences, connector combinations, recipients, destinations, permissions, workflows, persistent changes, and SaaS actions.

·        Confirm time synchronization across model, agent, identity, connector, SaaS, cloud, browser, endpoint, network, policy, approval, and SIEM systems.

Variant Resilience Requirements

·        Detection should remain effective when an attacker changes the wording, language, grammar, capitalization, spacing, encoding, obfuscation, or visual presentation of injected instructions.

·        Detection should remain effective when instructions are placed in email, documents, webpages, tickets, chat messages, calendar entries, code comments, repository issues, file metadata, images, transcripts, tool results, API responses, or knowledge-base content.

·        Detection should remain effective when instructions are fragmented across multiple content objects or retrieved over multiple agent steps.

·        Detection should remain effective when the attacker uses role claims, policy claims, urgency, authority, social engineering, task continuation, error recovery, or false approval to redirect the agent.

·        Detection should remain effective when malicious content avoids known prompt-injection phrases and instead manipulates goals, recipients, destinations, tool choices, or parameters indirectly.

·        Detection should remain effective when a different model, agent framework, orchestration system, tool protocol, browser, extension, plugin, skill, API, or connector is used.

·        Detection should remain effective when the attacker changes from direct tool invocation to browser automation, computer use, API calls, code execution, workflow creation, or another action method.

·        Detection should remain effective when unauthorized activity uses valid OAuth grants, service principals, user sessions, API tokens, or delegated permissions.

·        Detection should remain effective when the agent uses multiple legitimate tools to complete an unauthorized objective.

·        Detection should remain effective when sensitive data is transformed, summarized, encoded, compressed, embedded, translated, or divided before transfer.

·        Detection should remain effective when recipients, destinations, domains, tenants, repositories, webhooks, APIs, applications, or communication channels change.

·        Detection should remain effective when the agent conceals the activity in its final response or produces no user-visible indication of the unauthorized action.

·        Detection should remain effective when persistence is established through saved instructions, behavior-changing memory, knowledge bases, vector stores, workflow rules, templates, connector settings, shared content, repository content, tickets, or downstream SaaS objects.

·        Detection should remain effective when contaminated output is passed to another agent, user, workflow, or system that performs the consequential action.

·        Detection should remain effective when the attacker removes the initiating content, clears the session, deletes the message, modifies the document, revokes the connector, or attempts to erase audit evidence.

Operational Detection Model

·        Identify enterprise AI agents and map each agent to its model, owner, users, identities, connectors, tools, data sources, approval controls, and downstream SaaS platforms.

·        Monitor externally controlled and user-editable content entering enterprise-agent context.

·        Detect instruction-like content attempting to influence role, priority, policy, approval, confidentiality, tool selection, recipient, destination, or completion criteria.

·        Determine whether untrusted content materially changed the task plan, tool selection, connector use, data scope, recipients, destinations, or action sequence.

·        Detect transitions from read-oriented tasks to write-capable, externally communicative, destructive, privileged, financial, identity-sensitive, security-sensitive, or administrative actions.

·        Detect tool calls inconsistent with the initiating request, approved workflow, agent policy, data-handling requirement, or established baseline.

·        Detect expanded OAuth scopes, new connectors, new service identities, new tokens, new application consents, or broader delegated access.

·        Detect sensitive-data access outside the expected task scope.

·        Detect cross-connector movement of sensitive data, instructions, credentials, or internal context.

·        Detect unauthorized send, share, modify, delete, create, deploy, approve, purchase, pay, invite, permission, credential, policy, or administrative actions.

·        Detect consequential state changes created before a later workflow step is blocked.

·        Detect retries and alternate execution paths following a denied or blocked operation.

·        Detect discrepancies between approved parameters and executed parameters.

·        Detect discrepancies between user-visible responses and actual tool, connector, or SaaS activity.

·        Detect persistent changes to instructions, behavior-changing memory, knowledge, workflows, policies, tools, connectors, templates, automations, or downstream content.

·        Detect propagation of contaminated instructions or outputs between agents, users, workflows, repositories, and SaaS platforms.

·        Detect concealment, audit impairment, history deletion, artifact removal, misleading completion reporting, or suppression of approval evidence.

·        Correlate multiple stages before assigning probable or confirmed compromise.

·        Preserve separate SOC outcomes for content exposure, suspected trust injection, probable instruction influence, attempted tool misuse, blocked autonomous action, partially completed unauthorized action, unauthorized autonomous action, sensitive-data exposure, persistent compromise, and downstream organizational impact.

Explicit Non-Deployment Guardrails

·        Do not deploy a generic alert for all imperative language in content processed by an enterprise AI agent.

·        Do not deploy a generic match for “ignore previous instructions” without source, task, context, planning, tool, policy, or action evidence.

·        Do not treat a prompt-injection classifier alert as proof that the agent followed the instruction.

·        Do not treat model discussion of a tool or action as proof that the tool was invoked.

·        Do not treat a generated tool call as proof that the operation executed successfully.

·        Do not classify a workflow as fully blocked when earlier steps created material state changes.

·        Do not treat a generic approval event as proof that the final executed parameters were reviewed.

·        Do not alert on every cross-connector workflow without validating business purpose, user intent, and expected agent behavior.

·        Do not alert on every read, write, send, share, delete, update, deployment, or administrative operation when those functions are part of the approved workflow.

·        Do not treat every denied tool call, schema error, connector failure, retry, OAuth error, or approval timeout as malicious.

·        Do not infer data exposure solely from sensitive-data access without recipient, destination, transfer, output, or forensic evidence.

·        Do not infer persistence from ordinary conversation retention that cannot alter later agent behavior.

·        Do not treat an unexpected agent response as a confirmed security incident without supporting plan, tool, identity, connector, SaaS, policy, approval, or state-change evidence.

·        Do not classify malicious user-directed activity as trust injection without evidence that untrusted content altered the agent’s behavior.

·        Do not classify excessive-agency failure as trust injection without evidence of adversarial-content influence.

·        Do not attribute activity to a named actor, campaign, model, exploit, tool, or prompt-injection technique solely from generic agent or SaaS behavior.

·        Do not claim direct trust-injection coverage when retrieved content, prompt context, task planning, or tool-selection telemetry is unavailable.

·        Do not claim successful-action coverage when tool execution, connector response, or SaaS audit telemetry is unavailable.

·        Do not claim identity or permission coverage when OAuth, application, service-principal, token, scope, consent, and authorization telemetry is unavailable.

·        Do not claim data-exposure coverage from prompt, model, or network telemetry alone.

·        Do not promote a zero-event result to evidence of non-exploitation when prompts, retrieved content, task plans, tool calls, connector activity, approval events, SaaS audit records, or downstream actions were unavailable, sampled, filtered, delayed, overwritten, or deleted.

S22 — Primary Detection Signals

Figure 4

Primary Detection Signals

·        An enterprise AI agent processes externally controlled content containing instructions that conflict with the initiating request, agent policy, system instructions, approval requirements, confidentiality rules, or data-handling restrictions.

·        The content attempts to impersonate a system, developer, administrator, security, legal, compliance, or authorized-user instruction.

·        The content directs the agent to ignore, override, reinterpret, conceal, or bypass existing instructions, policy controls, approval gates, or tool restrictions.

·        The agent’s task plan, selected tools, connectors, recipients, destinations, or action scope changes after the content is processed.

·        A read-only or analytical task transitions into a write, send, share, delete, administrative, financial, identity, deployment, or security-control action.

·        A tool call contains recipients, destinations, resource identifiers, commands, data, or action parameters derived from untrusted content rather than the initiating request or approved workflow.

·        The agent invokes a connector, application, API, or SaaS platform not required by the initiating task.

·        The agent accesses sensitive or privileged data outside the expected user, task, repository, tenant, record, or business-process scope.

·        The agent transfers information obtained from one connector through another connector without an approved workflow.

·        The agent requests broader scopes, permissions, delegated access, application consent, or connector authority after processing untrusted content.

·        A high-impact tool call occurs without a valid policy decision, attributable human approval, deterministic workflow authorization, or explicit user instruction.

·        The executed parameters differ materially from the parameters reviewed during approval.

·        A multi-step workflow creates a consequential state change before a later step is denied, blocked, canceled, or fails.

·        SaaS audit telemetry confirms an unauthorized message, share, modification, deletion, permission change, user change, configuration change, workflow execution, code change, deployment, financial action, or security-control change.

·        The agent retries a denied operation using modified parameters, another connector, another identity, browser automation, code execution, or a decomposed sequence.

·        The agent’s final response omits, minimizes, or contradicts material actions recorded in tool, connector, or SaaS audit logs.

·        Persistent instructions, behavior-changing memory, workflow, knowledge-base, vector-store, template, policy, automation, or connector changes follow suspected trust injection.

·        The same unauthorized behavior recurs in later sessions, affects additional users or tenants, or propagates to another agent or workflow.

Supporting Detection Signals

·        The agent retrieves content from a first-seen, externally controlled, low-trust, user-editable, public, shared, or unauthenticated source.

·        Retrieved content contains role assertions, false policy text, false approval claims, urgency, secrecy, concealment instructions, or claims of higher authority.

·        Content includes hidden, low-contrast, off-screen, encoded, obfuscated, multilingual, fragmented, visual, or machine-targeted instructions.

·        A document, message, webpage, ticket, repository artifact, API response, or tool result includes explicit tool names, function syntax, connector directives, destinations, or action sequences.

·        Retrieved content asks the agent to expose system instructions, saved context, available tools, permissions, credentials, tokens, accessible data sources, or security controls.

·        The agent enumerates tools, connectors, scopes, permissions, repositories, mailboxes, drives, tenants, or administrative functions before an unexpected action.

·        Tool-call volume, connector count, retry frequency, task duration, or data-access volume increases materially after the content is processed.

·        The agent changes from an expected connector sequence to a rare or first-seen sequence.

·        A connector is used from an unusual agent, user, application, service identity, tenant, device, browser, network, or session context.

·        An agent identity accesses an unusual volume or diversity of sensitive data.

·        A new OAuth grant, refresh token, API token, service principal, application consent, or delegated permission appears during the task.

·        A sensitive record, file, message, ticket, source artifact, or customer object is accessed shortly before an external send, share, upload, post, webhook, or API call.

·        A tool request is blocked by policy, DLP, information protection, SaaS security, conditional access, connector restriction, or approval control.

·        The agent repeatedly modifies parameters after policy, authorization, schema, recipient, destination, or approval rejection.

·        The agent transforms, summarizes, encodes, translates, archives, or fragments data before an external transfer.

·        A new saved instruction, behavior-changing memory entry, workflow, rule, webhook, template, connector, knowledge entry, or automation appears without an approved change.

·        Agent, connector, identity, policy, approval, or SaaS logging is disabled, interrupted, reduced, or altered following suspicious activity.

Exploit Attempt and Instability Signals

·        Prompt-injection, indirect-instruction, unsafe-content, tool-abuse, excessive-agency, policy-engine, or connector-security detections occur while the agent processes external content.

·        The agent produces repeated policy conflicts, instruction-hierarchy violations, refusal reversals, approval-bypass attempts, or inconsistent safety decisions.

·        Tool calls fail because of unauthorized scope, invalid identity, denied permission, prohibited destination, blocked recipient, restricted data type, or high-impact action control.

·        The agent repeatedly changes tool parameters, destinations, identities, connectors, or execution methods after denial.

·        Connector authorization errors, OAuth failures, token errors, conditional-access blocks, application-consent denials, or delegated-permission failures follow untrusted-content processing.

·        SaaS APIs return permission, validation, policy, rate-limit, conflict, recipient, tenant, or prohibited-operation errors during an unexpected workflow.

·        The agent enters repeated planning, tool-call, connector, or retry loops after processing suspicious content.

·        Tool-call volume, connector requests, data access, model usage, or task duration increases without corresponding legitimate progress.

·        A browser, local agent, code interpreter, automation runtime, or computer-use tool attempts an action prohibited by a direct connector or policy control.

·        DLP, CASB, information-protection, email-security, SaaS-security, identity, or egress controls block transmission of sensitive data.

·        A high-impact action reaches an approval gate but is rejected, canceled, modified, or allowed to expire.

·        A multi-step unauthorized workflow partially executes before a later control blocks completion.

·        A connector, workflow, task, browser session, runtime, or agent process fails, restarts, or is terminated during repeated unauthorized attempts.

·        Rapid retries occur against the same data source, tool, SaaS object, recipient, destination, identity, or administrative function.

These signals support identification of attempted, partial, blocked, unstable, or unsuccessful trust manipulation and tool misuse but do not establish unauthorized autonomous action without supporting plan, tool, identity, connector, approval, SaaS audit, state-change, or forensic evidence.

Outbound Communication Signals

·        An agent sends, posts, uploads, shares, or transmits information to a destination not required by the initiating task.

·        First-seen or rare-recipient communication begins shortly after the agent processes untrusted content.

·        Sensitive information moves from an internal connector to an external email address, domain, tenant, repository, webhook, API, model, application, or storage service.

·        The agent communicates through a personal, unmanaged, newly created, anonymous, public, temporary, or low-reputation destination.

·        Direct-IP, unapproved API, unregistered webhook, newly observed domain, dynamic-DNS, paste, file-sharing, tunneling, or payload-hosting communication occurs.

·        The agent creates a public or externally accessible sharing link for sensitive content.

·        An email, message, post, comment, ticket, invitation, or document is sent to recipients not specified or approved by the user.

·        Outbound content contains credentials, tokens, source code, customer data, employee data, financial data, legal data, security findings, system instructions, internal policy, or confidential records.

·        The agent transforms, summarizes, encodes, translates, archives, or fragments data before external transmission.

·        A connector used primarily for internal workflow begins communicating with external or cross-tenant resources.

·        An agent sends instructions or contaminated content to another agent, bot, automation, or workflow that causes a downstream action.

·        External communication continues after the initiating content is removed, the user session ends, the connector is revoked, or the original task completes.

·        Destination rotation occurs while the agent, connector sequence, data type, timing, or action pattern remains consistent.

·        Communication recurs after agent restart, session reset, connector reauthorization, workflow restoration, or attempted remediation.

Persistence and Post-Exploitation Signals (Conditional)

This label includes post-manipulation and post-unauthorized-action activity. It does not require exploitation of a software vulnerability.

·        The agent writes unauthorized or adversarial instructions into behavior-changing memory, a knowledge base, vector store, saved prompt, template, workflow, rule, policy, or shared content source.

·        A poisoned document, message, ticket, repository artifact, calendar entry, knowledge item, or shared record is created to influence later agent activity.

·        Tool permissions, connector scopes, OAuth grants, delegated authority, service principals, API keys, tokens, or application consents are added or modified.

·        A new automation, webhook, scheduled workflow, mailbox rule, forwarding rule, repository action, CI/CD job, ticket rule, or SaaS integration is created.

·        The agent modifies system instructions, developer instructions, policy settings, tool availability, approval logic, recipient restrictions, destination restrictions, or execution constraints.

·        A new user, group, role, administrator, guest, application, bot, service account, or privileged identity is created or modified.

·        Sensitive data, credentials, tokens, secrets, or internal instructions are collected, staged, summarized, archived, or stored for later use.

·        Security controls, DLP rules, retention settings, logging, audit forwarding, approval requirements, connector restrictions, or conditional-access policies are disabled or weakened.

·        Agent history, tool-call records, messages, files, tickets, SaaS records, audit evidence, or temporary artifacts are deleted or altered.

·        The agent falsely reports that no action was taken, that approval was obtained, or that the task completed normally.

·        Unauthorized actions recur across later sessions, users, tasks, agents, or model versions.

·        A manipulated agent or workflow becomes a persistent intermediary for data access, external communication, credential use, or downstream action.

·        Customer, employee, financial, legal, operational, security, source-code, or administrative records are modified following suspected trust injection.

·        The affected agent is used for unauthorized communication, data collection, credential theft, fraud, sabotage, code modification, deployment, access provisioning, surveillance, or destructive activity.

Lateral Movement and Expansion Signals (Conditional)

·        Credentials, tokens, OAuth grants, API keys, or session material accessed by the agent are used against another SaaS platform, cloud service, repository, tenant, or administrative system.

·        The agent connects to additional mailboxes, drives, channels, repositories, ticket systems, customer platforms, identity services, financial systems, security platforms, or cloud environments outside its normal dependencies.

·        A compromised connector or agent identity is used to create another connector, application, service principal, token, workflow, automation, or agent.

·        The agent queries identity, cloud, SaaS, source-control, CI/CD, secret-management, security, or administrative APIs after the initial trust-manipulation sequence.

·        Similar adversarial content or unauthorized agent behavior appears across additional users, agents, workspaces, tenants, repositories, mailboxes, or business units.

·        Contaminated output is passed to another agent, bot, workflow, automation, or user that performs a consequential action.

·        Shared knowledge bases, vector stores, templates, documents, messages, repositories, tickets, or workflows distribute injected instructions to other agents.

·        Agent-generated invitations, shares, links, permissions, guest accounts, applications, or tokens expand access beyond the original user or tenant.

·        Data obtained from one business system is used to identify, target, authenticate to, or manipulate another system.

·        The original agent remains active as a relay, staging point, data broker, communication channel, or persistent autonomous access mechanism.

·        Customer, partner, supplier, managed-service, or downstream environments are accessed through exposed connectors, delegated relationships, shared applications, service identities, or administrative integrations.

·        Identity, cloud, SaaS, source-control, CI/CD, security-platform, VPN, or remote-access anomalies are linked to credentials or permissions exposed through the agent.

Downstream activity should remain an investigative lead unless it is temporally and behaviorally linked to the trust-injection, instruction-influence, tool-misuse, sensitive-data-access, unauthorized-action, persistence, or credential-use sequence.

Signal Usage Constraints

·        External content containing instructions does not prove trust injection.

·        A prompt-injection classifier alert does not prove that the agent followed the instruction.

·        A changed model response does not prove that planning, tool selection, connector access, or downstream behavior changed.

·        A proposed or generated tool call does not prove execution.

·        A failed or blocked tool call does not prove malicious intent.

·        A final blocked step does not prove that earlier workflow steps caused no impact.

·        An approval event does not prove that the final executed parameters were reviewed.

·        Tool-call retries may result from schema errors, rate limits, transient failures, expired sessions, service outages, or connector defects.

·        Access to multiple SaaS platforms may be normal for approved enterprise agents.

·        Sensitive-data access may be legitimate when required by the task and authorized by policy.

·        Cross-connector activity may be legitimate within approved workflows.

·        New OAuth scopes, application consents, or connector permissions may result from approved deployment or administration.

·        A high-impact SaaS action may be legitimate when supported by explicit user intent, attributable human approval, or an approved deterministic workflow.

·        External communication may result from approved email, collaboration, customer, support, reporting, integration, or notification processes.

·        Ordinary conversation retention does not establish persistence unless it can alter later agent behavior.

·        Malicious user-directed activity does not establish trust injection without evidence of external instruction influence.

·        Excessive-agency failure does not establish trust injection without evidence of adversarial-content influence.

·        Similar behavior across agents does not establish a common campaign without supporting evidence.

·        Confirmed escalation should require multiple aligned stages or direct audit and forensic evidence.

S23 — Telemetry Requirements

Endpoint and Process Execution Telemetry

Endpoint and process telemetry is required only where agents use local runtimes, browser automation, computer-use functions, code execution, desktop applications, or self-hosted orchestration components.

·        Process start and termination events from endpoints, browsers, local agents, orchestration servers, automation workers, containers, pods, virtual machines, and supporting systems where available.

·        Full process path, command line, parent and grandparent process, working directory, user, session, effective identity, container, workload, hash, signer, process identifier, and timestamp.

·        Browser, browser-extension, local-agent, desktop-automation, computer-use, shell, script-interpreter, code-interpreter, API client, command-line, package-manager, source-control, deployment, and network-tool execution.

·        Child-process creation from agent runtimes, browsers, office applications, collaboration clients, automation engines, code interpreters, connector services, and desktop applications.

·        Process ancestry preserved sufficiently to associate execution with the responsible user, agent, task, session, tool call, connector, container, workload, browser, or application context.

·        Execution associated with file creation, sensitive-data access, credential access, outbound communication, persistence, source-code changes, SaaS actions, or cleanup.

·        Application-control, reputation, malware-prevention, EDR, browser-security, container-security, and workload-protection events.

·        Execution telemetry retained across agent restart, browser restart, session reset, container replacement, workload replacement, and host reboot where supported.

Memory and Execution Telemetry

Memory telemetry is conditional and should be collected only where technically supported, legally permissible, and operationally justified.

·        Agent-runtime, browser, extension, model-client, connector, plugin, module, package, and dynamic-library loading where observable.

·        Runtime configuration changes, dynamically evaluated content, decoded instructions, generated code execution, and runtime-created functions where supported.

·        Browser, local-agent, code-execution, and automation-runtime telemetry capable of identifying scripts, commands, macros, or generated code launched on behalf of an agent.

·        Credential, token, session, clipboard, environment-variable, browser-storage, or local-secret access by agent-associated processes where collection is lawful and supported.

·        Executable memory, injected modules, or memory-resident payload behavior when agent activity expands into endpoint compromise.

·        Cross-process access, remote-memory operations, thread creation, or process injection associated with malicious tool use or downstream endpoint compromise.

·        Suspicious module loads, hooks, browser automation, credential access, network communication, or security-control impairment.

·        Correlation between the affected task, agent session, tool call, local execution, SaaS action, and network communication.

Crash and Fault Telemetry

·        Agent, AI gateway, orchestration, planner, retrieval, vector-store, connector, OAuth, API, browser, automation, and SaaS error events.

·        Instruction-hierarchy, policy, content-safety, prompt-injection, tool-authorization, data-handling, and approval-control failures.

·        Model timeout, context overflow, planning failure, repeated-loop, tool-schema, serialization, parsing, and invalid-argument errors.

·        Connector authentication, authorization, token, scope, consent, session, rate-limit, validation, conflict, and service-availability errors.

·        SaaS API permission, object, tenant, recipient, destination, policy, and prohibited-operation errors.

·        Browser, automation worker, container, pod, runtime, or service restarts occurring shortly after suspicious content processing or tool use.

·        Failed file creation, code execution, send, share, delete, permission change, credential access, webhook, API, DNS, socket, or outbound connection activity.

·        DLP, CASB, SaaS-security, email-security, identity, endpoint, browser, container, application-control, and policy blocks associated with the task.

·        Sufficient timestamps, task identifiers, session identifiers, trace identifiers, tool-call identifiers, approval identifiers, SaaS object identifiers, process identifiers, and identity identifiers to correlate failed activity with later successful execution.

Crash and fault telemetry should support detection of unsuccessful, partial, blocked, unstable, or repeatedly attempted activity but should not be treated as standalone proof of unauthorized autonomous action.

File and Persistence Telemetry

·        File creation, modification, replacement, rename, copy, extraction, upload, download, share, move, deletion, permission change, ownership change, and metadata change.

·        Full source and destination paths, repository or drive location, initiating user, agent, process, connector, identity, tenant, hash, signer, size, content type, sensitivity, creation time, modification time, and first-seen time.

·        File operations within enterprise drives, collaboration platforms, repositories, knowledge bases, vector stores, agent workspaces, automation directories, configuration paths, and shared content stores.

·        Version history and audit telemetry for system instructions, developer instructions, saved prompts, workflows, templates, policies, connector configurations, behavior-changing memory, and knowledge sources.

·        Creation or modification of scheduled workflows, mailbox rules, forwarding rules, webhooks, CI/CD jobs, repository actions, SaaS automations, identity objects, or persistent agent configurations.

·        Access to environment files, credential stores, API keys, OAuth tokens, cloud credentials, source-control tokens, service-account material, browser sessions, connector secrets, and deployment credentials.

·        Creation or modification of tunneling, proxying, remote-access, data-transfer, credential-access, automation, or cleanup tools.

·        Deletion or alteration of agent history, prompt records, tool-call logs, connector logs, SaaS audit events, messages, documents, repository artifacts, tickets, or temporary evidence.

·        Recurrence of persistent instructions, behavior-changing memory, workflow changes, connector changes, identity changes, permission changes, knowledge changes, or automation changes after remediation.

·        Deployment, synchronization, migration, backup, restoration, model update, instruction update, connector update, red-team, evaluation, and change-control context required to distinguish legitimate changes.

Network and Outbound Communication Telemetry

·        AI gateway, model API, agent runtime, connector, browser, API gateway, webhook, SaaS API, endpoint, workload, DNS, proxy, firewall, flow, EDR-network, NDR, and packet telemetry.

·        Source and destination IP, source and destination port, protocol, direction, bytes, packets, duration, connection state, certificate, domain, SNI, timestamp, identity, agent, connector, and task identifier where available.

·        Network events mapped to the responsible user, agent, process, container, workload, tool call, connector, OAuth application, service principal, or service identity.

·        First-seen and prevalence context for sources, destinations, domains, certificates, ports, protocols, APIs, webhooks, recipients, tenants, and connector sequences.

·        Model API and agent-service communication sufficient to identify the responsible enterprise agent, model, task, session, application, and tenant.

·        Outbound communication from local agents, browsers, automation runtimes, code interpreters, connector services, containers, pods, and orchestration systems.

·        DNS resolution, upload, download, payload retrieval, webhook use, API communication, tunneling, proxying, data transfer, credential use, and downstream-service access.

·        Internal traffic from the agent environment to identity services, secret stores, source repositories, CI/CD systems, databases, administrative systems, cloud metadata, orchestration APIs, and management platforms.

·        Session recurrence and timing across agent restart, browser restart, session reset, connector reauthorization, container replacement, workflow restoration, or host reboot.

·        Network visibility across internet, perimeter, internal, cloud, SaaS, endpoint, browser, container, orchestration, and segmented environments.

·        Application-layer visibility sufficient to distinguish approved model, SaaS, connector, webhook, and API communication from unauthorized data transfer or action execution where legally and operationally permitted.

Web and Application Telemetry (Conditional Availability)

·        System, developer, user, retrieved-content, tool-result, behavior-changing memory, policy, and output-context classifications.

·        Prompt and response telemetry with agent, model, model version, task, session, trace, timestamp, and policy context.

·        Retrieved-content telemetry identifying source type, source object, owner, tenant, location, trust classification, content identifier, retrieval query, rank, and timestamp.

·        Retrieval, search, indexing, vector-store, chunk, citation, and knowledge-base events.

·        Agent task-plan, step, goal-change, tool-selection, retry, exception, and completion telemetry where exposed by the platform.

·        Tool-call telemetry including function, normalized arguments, target resource, data scope, recipient, destination, action type, result, error, policy decision, approval state, and resulting object.

·        Human approval, denial, modification, cancellation, timeout, and exception telemetry.

·        The exact action and parameters presented to the approving user.

·        The exact action and parameters executed after approval.

·        OAuth, connector, application, service-principal, delegated-access, scope, token, consent, and revocation telemetry.

·        SaaS audit events for search, read, download, export, send, share, create, modify, delete, permission, user, role, configuration, workflow, application, and administrative actions.

·        Email, collaboration, file-storage, ticketing, customer-management, source-control, CI/CD, financial, human-resources, cloud, identity, security, and administrative-platform records.

·        Prompt-injection, content-safety, model-security, tool-firewall, DLP, information-protection, CASB, SaaS-security, insider-risk, and data-security posture events.

·        Agent deployment, instruction update, policy update, model update, connector update, workflow update, evaluation, testing, and administrative records.

·        Multi-agent communication and handoff telemetry identifying source agent, destination agent, transferred context, instructions, tools, and resulting actions.

Telemetry Availability Requirements

·        Confirm whether system, developer, user, retrieved-content, tool-result, behavior-changing memory, policy, and output contexts can be distinguished.

·        Confirm whether prompts and retrieved content are retained in original, normalized, hashed, redacted, classified, or security-event form.

·        Confirm whether external-content sources and individual retrieved objects can be reconstructed.

·        Confirm whether the agent’s task plan, goal changes, step sequence, and tool-selection events are logged.

·        Confirm whether tool calls retain complete normalized arguments, target resources, recipients, destinations, action types, results, and errors.

·        Confirm whether proposed, blocked, partially completed, approved, modified, and executed actions are separately recorded.

·        Confirm whether human approvals are attributable to a specific user, time, task, action, parameter set, recipient, destination, resource, identity, and data scope.

·        Confirm whether the final executed parameters can be compared with the parameters presented during approval.

·        Confirm whether connector activity can be associated with the responsible agent, user, application, service identity, task, and session.

·        Confirm whether OAuth grants, scopes, tokens, consents, service principals, delegated permissions, and connector changes are visible.

·        Confirm whether SaaS audit logs capture read, export, send, share, modify, delete, permission, configuration, workflow, identity, and administrative events.

·        Confirm whether SaaS object identifiers and resulting state can be correlated with the initiating tool call.

·        Confirm whether partial state changes created before workflow failure or blocking can be reconstructed.

·        Confirm whether DLP, information-protection, CASB, SaaS-security, identity, and policy decisions are retained.

·        Confirm whether browser, local-agent, computer-use, code-execution, endpoint, process, file, and network activity is visible where applicable.

·        Confirm whether cross-connector data movement can be reconstructed.

·        Confirm whether multi-agent handoffs preserve source, destination, transferred context, and resulting-action relationships.

·        Confirm whether persistent instructions, behavior-changing memory, knowledge-base, vector-store, workflow, template, policy, and connector changes are audited and versioned.

·        Confirm whether ordinary conversation retention can be distinguished from persistent content capable of altering later agent behavior.

·        Confirm whether agent actions performed under delegated user authority can be distinguished from actions performed directly by the human user.

·        Confirm whether logs are forwarded to protected remote storage before an agent, user, administrator, or attacker can delete or alter them.

·        Confirm whether retention is sufficient to compare behavior before and after session reset, model update, connector revocation, workflow restoration, or remediation.

·        Confirm whether model, agent, identity, connector, SaaS, cloud, browser, endpoint, network, policy, approval, and SIEM timestamps are synchronized.

·        Confirm whether approved deployments, instruction changes, connector changes, workflow updates, evaluations, red-team exercises, testing, administrative activity, and incident-response workflows are documented for suppression and validation.

Telemetry Limitations and Gaps

·        Some enterprise AI platforms do not expose complete prompts, retrieved content, task plans, tool-selection events, policy decisions, or internal execution context.

·        Privacy, legal, contractual, and data-minimization requirements may limit prompt and content retention.

·        Prompt and retrieved-content logs may be truncated, sampled, redacted, encrypted, normalized, or unavailable.

·        Retrieved documents may be divided into chunks that obscure the complete adversarial instruction.

·        Hidden, visual, encoded, or multimodal instructions may not appear accurately in text-oriented logs.

·        Prompt-injection or model-security detections may identify suspicious content without proving behavioral influence.

·        Agent platforms may record only executed tool calls and omit planning, rejected calls, modified calls, or alternate paths.

·        Tool-call logs may omit sensitive arguments, normalized values, destination details, data content, or rejected attempts.

·        Human-approval logs may record approval without preserving the exact parameters the user reviewed.

·        Approval platforms may not reveal whether parameters changed between review and execution.

·        Connector activity may appear as the human user, making direct human and agent actions difficult to distinguish.

·        Shared service accounts, OAuth applications, service principals, or delegated sessions may weaken user-level and agent-level attribution.

·        SaaS audit logs may not record read activity, searches, previews, prompt context, or data returned to the agent.

·        SaaS platforms may delay audit events or provide incomplete object, recipient, permission, or result details.

·        Partial workflow effects may persist even when the final action fails or is blocked.

·        Cross-connector data movement may not be visible when content is transformed inside the agent context.

·        Data may be summarized, encoded, translated, fragmented, or embedded before transfer.

·        Browser automation and computer-use agents may perform actions through user interfaces without structured tool-call telemetry.

·        Local agent activity may occur without endpoint, browser, process, file, or network visibility on unmanaged devices.

·        Agent execution may remain within an existing browser, runtime, or automation process without creating a new process.

·        Encrypted traffic may conceal prompts, tool arguments, data transfers, and downstream actions.

·        Network telemetry may show communication without proving which task, content source, agent step, or tool caused it.

·        Persistent influence may reside in saved instructions, behavior-changing memory, vector stores, shared content, workflow state, or SaaS objects that are not centrally audited.

·        Multi-agent systems may lose provenance as content and instructions pass between agents.

·        A successful attack may produce no visibly malicious response and minimal security errors.

·        A blocked attack may produce numerous signals without any unauthorized state change.

·        An agent may perform a harmful action using valid permissions and expected APIs, producing few traditional compromise indicators.

·        The original injected content may be deleted, changed, or unavailable by the time the incident is investigated.

·        A zero-event result does not prove absence of compromise when relevant telemetry was disabled, incomplete, sampled, filtered, overwritten, delayed, or enabled after the activity.

S24 — Detection Opportunities and Gaps

Detection Opportunities

·        Detect externally controlled and user-editable content entering enterprise-agent context.

·        Detect instructions embedded in email, documents, webpages, tickets, chat messages, calendar entries, repositories, code comments, images, metadata, API responses, and tool outputs.

·        Detect attempts to override system instructions, policy controls, approval requirements, confidentiality rules, recipient restrictions, destination restrictions, or tool permissions.

·        Detect false system, developer, administrator, security, legal, compliance, or authorized-user claims.

·        Detect instructions to conceal actions, suppress warnings, misrepresent results, or omit material tool activity.

·        Detect changes in task plans, selected tools, connector use, data scope, recipients, destinations, or completion criteria after untrusted-content processing.

·        Detect transitions from read-oriented tasks to write-capable, externally communicative, destructive, privileged, financial, identity-sensitive, security-sensitive, or administrative actions.

·        Detect tool calls inconsistent with the initiating request, approved workflow, user authority, or agent policy.

·        Detect tool parameters derived from untrusted content rather than user intent or approved configuration.

·        Detect access to new or unusual connectors, tenants, repositories, mailboxes, drives, channels, ticket systems, customer platforms, identity services, financial systems, security platforms, or administrative consoles.

·        Detect expanded OAuth scopes, delegated permissions, service principals, tokens, API keys, application consents, and connector authority.

·        Detect sensitive-data access outside the expected task, user, repository, record, tenant, or business-process scope.

·        Detect cross-connector movement of sensitive data, credentials, internal instructions, or confidential context.

·        Detect unauthorized external messages, posts, uploads, shares, webhooks, API calls, invitations, and public links.

·        Detect unauthorized file, record, ticket, repository, workflow, code, configuration, user, role, permission, policy, identity, financial, or administrative changes.

·        Detect material differences between approved parameters and executed parameters.

·        Detect partial execution that creates consequential state before a later step is blocked or fails.

·        Detect attempts to bypass approval by changing parameters, tools, connectors, identities, execution methods, or action sequencing.

·        Detect discrepancies between user-visible responses and actual tool, connector, or SaaS activity.

·        Detect persistent changes to saved instructions, behavior-changing memory, knowledge bases, vector stores, templates, workflows, policies, automations, and connector configurations.

·        Detect poisoned content influencing later sessions, users, agents, applications, or workflows.

·        Detect propagation of adversarial instructions and unauthorized objectives across multi-agent systems.

·        Detect access to credentials, tokens, secrets, internal instructions, security policies, connector configurations, and privileged records.

·        Detect security-control impairment, logging changes, retention changes, audit interruption, history deletion, and artifact removal.

·        Detect agent-driven expansion into additional SaaS, cloud, identity, source-control, CI/CD, financial, customer, security, and administrative systems.

·        Improve confidence through correlation of content, task, plan, model, tool, identity, connector, SaaS, browser, endpoint, network, policy, approval, and resulting-state evidence.

·        Generalize coverage across models, agents, frameworks, content sources, instruction forms, tools, connectors, identities, platforms, actions, and persistence methods.

Detection Gaps

·        Detection may miss the initiating instruction when prompt or retrieved-content telemetry is unavailable.

·        Detection may miss hidden, visual, encoded, fragmented, or multimodal instructions that are not preserved accurately.

·        Detection may identify suspicious content without determining whether the agent followed it.

·        Detection may fail to reconstruct task-plan or goal changes when planning telemetry is unavailable.

·        Detection may miss tool-selection influence when only executed tool calls are logged.

·        Detection may miss blocked, rejected, modified, or alternate tool attempts when platforms log only successful operations.

·        Detection may fail to distinguish direct human actions from agent actions when both use the same delegated identity.

·        Detection may fail to associate a SaaS action with the responsible prompt, content source, agent session, approval, or tool call.

·        Detection may fail to determine whether an unauthorized action resulted from trust injection, malicious user direction, excessive agency, or another workflow defect.

·        Detection may miss read activity when SaaS audit logs record only writes or administrative changes.

·        Detection may miss sensitive-data exposure that occurs entirely within agent context or generated output.

·        Detection may miss cross-connector transfer when data is transformed, summarized, encoded, translated, or fragmented.

·        Detection may misclassify approved automation, synchronization, enrichment, migration, reporting, incident response, or administrative activity.

·        Detection may miss unauthorized action performed through browser automation or computer use when structured tool telemetry is unavailable.

·        Detection may miss local execution on unmanaged endpoints or within existing browser and runtime processes.

·        Detection may miss credential access when secrets are inherited through environment variables, workload identity, browser sessions, delegated access, or connector-managed token stores.

·        Detection may miss external communication when traffic uses approved model, SaaS, proxy, integration, application, or webhook infrastructure.

·        Detection may lose task and content provenance as context passes between agents, tools, connectors, applications, and workflows.

·        Detection may miss behavior-changing persistence stored in external memory, vector stores, shared content, workflow state, repository content, or downstream SaaS objects.

·        Detection may incorrectly treat ordinary conversation retention as persistence when it cannot influence later agent behavior.

·        Detection may miss concealment when the platform does not preserve complete tool-call, approval, response, and action histories.

·        Detection may be unable to verify that the approving user reviewed the final executed parameters.

·        Detection may miss consequential partial execution when only the final workflow result is recorded.

·        Detection may be materially limited where agent vendors provide only aggregate, redacted, or user-visible activity records.

·        Detection may identify unauthorized SaaS activity without proving that trust injection caused it.

·        Detection may identify trust injection and tool misuse without determining the exact malicious content, source, or attacker.

·        Detection may not support actor, campaign, model, agent, tool, connector, or framework attribution when content, infrastructure, identities, and action methods change.

·        Detection cannot prove successful unauthorized action from prompt, model, classifier, or network telemetry alone.

·        Detection cannot prove absence of compromise when telemetry was incomplete, delayed, sampled, overwritten, deleted, or enabled after the relevant period.

Compensating Controls

·        Maintain an authoritative inventory of enterprise AI agents, assistants, autonomous workflows, models, tools, connectors, identities, owners, permissions, and business purposes.

·        Treat externally controlled content, retrieved documents, emails, webpages, tickets, messages, repository artifacts, API responses, and tool outputs as untrusted data rather than authoritative instructions.

·        Separate system instructions, user intent, retrieved content, tool results, and behavior-changing memory through explicit trust boundaries.

·        Enforce instruction hierarchy and data-versus-command separation outside the model where technically possible.

·        Limit agents to the minimum tools, connector functions, data sources, and tenants required for their approved purpose.

·        Prefer read-only connectors when write functionality is not required.

·        Separate read and write capabilities into distinct tools, identities, workflows, or approval paths.

·        Remove unused administrative, financial, destructive, identity-changing, externally communicative, and security-sensitive functions.

·        Apply least-privilege OAuth scopes, delegated permissions, API privileges, service roles, and data access.

·        Use agent-specific and task-specific identities rather than shared high-privilege service accounts.

·        Use short-lived, narrowly scoped, just-in-time credentials and tokens where supported.

·        Require independent human approval for high-impact actions.

·        Bind approvals to the exact final action, parameter set, recipient, destination, resource, data scope, identity, and expiration time.

·        Require reapproval when any material parameter changes after review.

·        Prevent agents from modifying their own instructions, policies, tool permissions, approval requirements, security controls, logging, or audit configuration.

·        Apply deterministic policy enforcement at the tool and connector boundary.

·        Validate tool arguments, recipients, destinations, data classifications, resource scopes, action types, identities, and tenant context before execution.

·        Apply transactional safeguards or rollback controls where multi-step workflows can create partial state.

·        Apply allowlists for approved domains, recipients, tenants, repositories, webhooks, APIs, applications, storage locations, and connector combinations.

·        Block direct external sharing, public links, unmanaged destinations, and cross-tenant transfers unless explicitly approved.

·        Apply DLP, information protection, CASB, SaaS-security, email-security, insider-risk, and data-security controls to agent actions.

·        Restrict agents from accessing credentials, secrets, system instructions, internal security policies, and privileged administrative records unless essential.

·        Isolate code execution, browser automation, computer use, and local tools within hardened sandboxes.

·        Restrict endpoint, filesystem, credential-store, clipboard, browser-session, local-network, metadata-service, and internet access.

·        Apply rate limits, action limits, recipient limits, data-volume limits, transaction limits, and administrative-change limits to agent tools.

·        Prevent repeated retries or alternate-tool selection after policy denial without human review.

·        Require provenance for retrieved content, tool results, agent-generated content, and multi-agent handoffs.

·        Scan and classify content before it enters agent context and again before high-impact tool use.

·        Use independent verification for high-impact actions rather than relying solely on the same model that generated the action.

·        Preserve complete agent, prompt, retrieval, planning, tool, approval, connector, identity, SaaS, browser, endpoint, and network logs in protected remote storage.

·        Version and monitor system instructions, developer instructions, policies, workflows, saved prompts, behavior-changing memory, knowledge bases, vector stores, templates, and connector configurations.

·        Establish immediate revocation procedures for OAuth grants, tokens, connectors, service identities, sessions, applications, and agent access.

·        Maintain tested response procedures for task preservation, content review, tool-call reconstruction, approval validation, SaaS audit review, token revocation, connector isolation, identity containment, partial-state recovery, downstream-state recovery, data-impact analysis, and enterprise-wide hunting.

·        Hunt across all agents and connected platforms for related content, task-plan changes, tool sequences, data access, unauthorized actions, persistent changes, connector abuse, and downstream expansion rather than limiting response to one prompt or agent.

·        Restore agent configuration, persistent context, workflows, connectors, permissions, identities, and downstream SaaS state from trusted versions when integrity cannot be established.

Non-Coverage Conditions

·        No primary trust-injection coverage exists where retrieved content, prompt context, and agent behavior are all unavailable.

·        Prompt-injection classifier telemetry alone cannot prove behavioral influence or unauthorized action.

·        Model-response-only telemetry cannot prove tool invocation, connector access, SaaS state change, or data transfer.

·        Tool-call telemetry without task, user-intent, content-source, policy, or approval context may not support reliable trust-injection attribution.

·        Tool-request telemetry cannot prove execution when connector responses and SaaS audit records are unavailable.

·        SaaS audit telemetry alone cannot prove that an AI agent rather than a human initiated the action.

·        Shared user sessions, service accounts, OAuth applications, delegated identities, or service principals materially weaken agent-level attribution.

·        Network-only telemetry cannot prove trust injection, planning influence, tool selection, SaaS state change, or sensitive-data disclosure.

·        Endpoint-only telemetry cannot prove actions performed entirely through cloud-hosted models, connectors, applications, and SaaS APIs.

·        Cloud control-plane telemetry cannot directly detect instructions embedded in email, documents, webpages, messages, tickets, repositories, or tool outputs.

·        Data-loss prevention events may establish attempted transfer but not the initiating instruction, task-plan change, or tool-selection path.

·        Read-access coverage is materially weakened when SaaS platforms do not log searches, previews, reads, downloads, exports, or returned records.

·        Cross-connector coverage is materially weakened when data provenance is lost inside the agent context.

·        Browser-automation and computer-use coverage is materially weakened when browser actions, screenshots, DOM interaction, session activity, and user-interface changes are unavailable.

·        Persistent-context coverage is materially weakened when saved instructions, behavior-changing memory, knowledge-base, vector-store, workflow, template, and policy changes are not versioned or audited.

·        Ordinary conversation retention does not support persistence coverage unless it can alter later agent behavior.

·        Multi-agent coverage is materially weakened when handoff context, source agent, destination agent, and resulting actions are unavailable.

·        Identity coverage is materially weakened when OAuth grants, scopes, tokens, applications, service principals, delegated permissions, consents, and approval events are unavailable.

·        Approval coverage is materially weakened when the reviewed and executed parameter sets cannot be compared.

·        Partial-execution coverage is materially weakened when only the final workflow outcome is recorded.

·        Sensitive-data exposure coverage is materially weakened when prompts, outputs, tool arguments, response content, transfer destinations, and SaaS object details are redacted or unavailable.

·        Unauthorized-action coverage is materially weakened when tool results, connector responses, SaaS audit records, and resulting-state evidence are unavailable.

·        A prevention or blocking event may establish attempted behavior but not successful access, modification, disclosure, persistence, or downstream impact.

·        Generic agent errors, unusual tool calls, SaaS actions, data access, or external communication do not establish trust injection without sufficient task and content linkage.

·        Unauthorized agent activity may be detectable even when the available evidence cannot distinguish trust injection from malicious user direction, excessive agency, or workflow failure.

·        Actor, campaign, model, agent, tool, connector, and prompt-technique attribution are outside direct coverage when only generic behavior is observed.

·        A zero-event result does not prove absence of compromise when telemetry was disabled, incomplete, sampled, filtered, delayed, overwritten, deleted, or collected after the relevant activity.

S25 — Ultra-Tuned Detection Engineering Rules

NDR / Network Behavioral Analytics

Detection Viability Assessment

NDR and Network Behavioral Analytics platforms can provide viable supporting coverage for this report when they can identify enterprise AI-agent workloads, map approved model and SaaS dependencies, inspect DNS, proxy, firewall, flow, API-gateway, webhook, and TLS metadata, baseline agent-associated communication, and apply approved-destination, approved-workflow, and operational-window exceptions.

NDR can identify abnormal communication, unauthorized destinations, sensitive-access-to-transfer sequences, connector bypass, and unexpected internal expansion from enterprise AI-agent workloads. It cannot directly confirm that untrusted content altered an agent’s instructions, that the agent’s task plan changed, that a human approval was valid, that a SaaS action completed, or that trust injection caused the activity. Those conclusions require agent, prompt, retrieval, tool-call, connector, identity, approval, SaaS audit, DLP, endpoint, or incident-response evidence.

Two rules survive validation:

·        Abnormal network activity from an enterprise AI-agent workload.

·        Sensitive enterprise data access followed by agent-associated external transfer.

Each rule is independently deployable and does not require another CyberDax rule to fire first.

Rule

Abnormal Network Activity From an Enterprise AI-Agent Workload

Rule Format

NDR or Network Behavioral Analytics anomaly-detection pattern using enterprise AI-agent workload identification, expected external and internal communication baselines, destination rarity, connection behavior, approved-dependency exceptions, and optional upstream agent, connector, identity, or policy context.

Detection Purpose

Detect unusual outbound communication or internal service access originating from an enterprise AI-agent runtime, orchestration service, connector host, browser-automation system, code-execution environment, container, pod, workload, or supporting server that may indicate unauthorized external communication, connector bypass, payload retrieval, callback-like behavior, credential use, or downstream expansion.

The rule does not claim that NDR directly observed trust injection, task-plan manipulation, tool-selection influence, approval bypass, sensitive-data disclosure, or successful SaaS modification.

Detection Logic

·        Limit detection to known enterprise AI-agent runtimes, orchestration services, connector hosts, browser-automation systems, code-execution environments, containers, pods, workloads, or supporting servers with reliable network identity.

·        Identify outbound communication to a new, rare, suspicious, direct-IP, prohibited, unmanaged, or role-inconsistent destination.

·        Identify callback-like, payload-retrieval-like, tunneling-like, periodic, long-lived, low-volume, unusually interactive, or destination-rotating sessions.

·        Identify access to internal systems or service categories not included in the workload’s expected dependency map.

·        Increase confidence when multiple new destinations, destination categories, ports, protocols, tenants, or internal systems are contacted within a bounded period.

·        Increase confidence when the activity follows a connector denial, policy block, approval rejection, DLP event, browser-automation event, code-execution event, credential-access event, or unexpected tool invocation where that context is available.

·        Increase confidence when communication continues after the associated user session, agent task, connector session, or approved workflow ends.

·        Exclude approved model endpoints, SaaS platforms, APIs, webhooks, mail services, repositories, update services, monitoring services, backup systems, security platforms, cloud infrastructure, content-delivery networks, and documented business integrations.

·        Do not classify rare egress as command and control or unexpected internal access as lateral movement without corroborating evidence.

·        Do not classify the activity as confirmed trust injection without upstream evidence showing that untrusted content materially influenced the agent’s behavior.

Required Telemetry

·        NDR, DNS, proxy, firewall, flow, API-gateway, webhook, TLS, or endpoint-network telemetry.

·        Enterprise AI-agent workload, runtime, connector host, browser-automation system, code-execution environment, container, pod, server, or managed-instance mapping.

·        Source and destination IP, destination domain, destination port, protocol, direction, duration, bytes, connection count, and timestamp.

·        Destination reputation, first-seen status, prevalence, ASN, geography, tenant, application, and service category.

·        Internal asset role and expected enterprise AI-agent dependency mapping.

·        Approved external-domain, external-IP, SaaS, API, webhook, tenant, and internal-dependency lookups.

·        Agent task, session, trace, connector, identity, approval, policy, DLP, endpoint, or SaaS context where available.

Engineering Implementation Instructions

·        Build a reliable inventory of enterprise AI-agent workloads and their stable network identifiers.

·        Establish expected external destinations and internal dependencies for each agent, workload role, application, connector, or deployment group.

·        Maintain separate approved-domain, approved-IP, approved-tenant, and approved-service lists for model providers, SaaS platforms, APIs, webhooks, mail, repositories, monitoring, backups, security products, updates, cloud services, and business integrations.

·        Require destination rarity, role deviation, unusual session behavior, destination rotation, continued communication after task completion, or internal dependency deviation rather than alerting on outbound traffic alone.

·        Tune shared-egress, autoscaled, serverless, containerized, multi-tenant, browser-automation, and managed-service environments separately.

·        Preserve source attribution through NAT, cloud egress, container networking, Kubernetes services, service meshes, proxies, gateways, and shared connector infrastructure where possible.

·        Use upstream agent, connector, identity, approval, policy, DLP, endpoint, or SaaS context only as enrichment. The rule must remain capable of detecting abnormal network behavior independently.

·        Test callback, transfer-volume, destination-count, port-count, session-duration, task-completion, and internal-peer thresholds in hunt mode.

·        Route activity involving identity services, secret stores, cloud metadata, source repositories, CI/CD systems, security platforms, financial systems, orchestration systems, administrative interfaces, or privileged SaaS APIs at higher priority.

·        Describe the result as abnormal enterprise AI-agent workload network activity, not confirmed trust injection, data exfiltration, command and control, credential compromise, or lateral movement.

DRI Assessment

The rule remains effective when attackers change the original injected content, model, agent framework, connector, tool, destination, port, protocol, callback interval, transfer method, internal target, or execution path. Variant resistance is reduced when attackers use approved destinations, expected internal dependencies, existing sessions, shared infrastructure, or local-only activity.

DRI

8.6

TCR Assessment

Operational confidence depends on reliable AI-agent workload identification, expected-egress baselines, internal dependency mapping, destination enrichment, approved-service exceptions, and locally tested thresholds. Full-telemetry confidence improves when network behavior can be correlated with agent, retrieval, tool-call, connector, identity, approval, SaaS, DLP, endpoint, browser, or incident-response evidence.

Operational TCR

8.3

Full-Telemetry TCR

9.0

Limitations

·        Enterprise AI-agent workloads may communicate with many external models, APIs, webhooks, SaaS platforms, repositories, and cloud services for legitimate purposes.

·        NAT, shared egress, service meshes, proxies, container overlays, browser automation, pooled connectors, and managed services may obscure the source agent or workload.

·        NDR may not identify the initiating prompt, retrieved content, task, tool call, user, approval event, process, file, or SaaS object.

·        Attackers may use approved cloud services, APIs, repositories, webhooks, SaaS platforms, or existing connections.

·        Local-only activity and same-host communication may not be visible.

·        Short encrypted sessions may resemble legitimate API, webhook, model, or connector traffic.

·        Incomplete dependency maps may cause legitimate internal communication to appear suspicious.

·        Autoscaling, deployment, connector updates, workflow changes, backup, restoration, migration, evaluation, red teaming, and maintenance can change network behavior.

·        The rule cannot prove trust injection, task-plan manipulation, sensitive-data disclosure, approval bypass, successful SaaS modification, credential compromise, or lateral movement.

Detection Query Pattern

Use this pattern as an implementation guide for platforms that support enterprise AI-agent workload grouping, destination-domain and destination-IP enrichment, expected-egress baselines, internal dependency mapping, connection-behavior analysis, task-completion context, and approved-service exceptions.

LET agent_network_activity =
dns_proxy_firewall_ndr_api_gateway_or_flow_events
WHERE source_asset IN ENV_ENTERPRISE_AI_AGENT_WORKLOADS

LET suspicious_external_activity =
agent_network_activity
WHERE connection_direction = "outbound"
AND (
destination_domain IS NULL
OR destination_domain NOT IN ENV_APPROVED_AGENT_EXTERNAL_DOMAINS
)
AND (
destination_ip IS NULL
OR destination_ip NOT IN ENV_APPROVED_AGENT_EXTERNAL_IPS
)
AND (
destination_tenant IS NULL
OR destination_tenant NOT IN ENV_APPROVED_AGENT_EXTERNAL_TENANTS
)
AND (
destination_first_seen IN (
"new",
"rare"
)
OR destination_reputation IN (
"suspicious",
"malicious"
)
OR destination_category IN (
"dynamic_dns",
"anonymous_proxy",
"tunneling",
"paste_service",
"public_file_sharing",
"temporary_storage",
"payload_hosting",
"unmanaged_saas"
)
OR direct_ip_connection = true
OR network_behavior IN (
"callback_like",
"payload_retrieval_like",
"tunneling_like",
"periodic",
"long_lived_low_volume",
"interactive",
"destination_rotation"
)
OR communication_after_task_completion = true
)

LET suspicious_internal_activity =
agent_network_activity
WHERE connection_direction = "internal"
AND destination_asset NOT IN ENV_APPROVED_AGENT_INTERNAL_DEPENDENCIES
AND (
destination_first_seen IN (
"new",
"rare"
)
OR destination_role IN ENV_SENSITIVE_INTERNAL_SERVICE_ROLES
OR unique_destination_count >= ENV_INTERNAL_DESTINATION_THRESHOLD
OR unique_destination_port_count >= ENV_INTERNAL_PORT_THRESHOLD
)

ALERT WHEN
suspicious_external_activity
OR suspicious_internal_activity

OUTPUT
source_asset,
agent_id,
agent_task_id,
source_workload_id,
source_ip,
destination_asset,
destination_domain,
destination_ip,
destination_port,
destination_tenant,
destination_role,
connection_direction,
destination_first_seen,
destination_reputation,
destination_category,
network_behavior,
session_duration,
bytes_sent,
bytes_received,
unique_destination_count,
unique_destination_port_count,
communication_after_task_completion,
correlated_connector_denial,
correlated_policy_block,
correlated_approval_rejection,
first_seen,
last_seen

Rule

Sensitive Enterprise Data Access Followed by Agent-Associated External Transfer

Rule Format

NDR or Network Behavioral Analytics correlation pattern using enterprise AI-agent identity and workload mapping, sensitive-data-access events, data-classification context, outbound network behavior, approved data-flow exceptions, and task, session, connector, workload, browser, process, or identity correlation.

Detection Purpose

Detect a sequence in which an enterprise AI agent, agent-associated identity, connector, browser session, orchestration workload, code-execution environment, or supporting asset accesses sensitive enterprise data and subsequently initiates an external transfer, upload, webhook call, API request, public-sharing action, or other outbound communication inconsistent with the approved task and connector workflow.

The rule identifies suspicious sensitive-access-to-transfer behavior without claiming that NDR directly observed trust injection or confirmed the exact content transferred.

Detection Logic

·        Limit detection to known enterprise AI agents, agent-associated identities, applications, connectors, browser-automation systems, orchestration workloads, code-execution environments, or supporting assets.

·        Identify access to credentials, tokens, secrets, regulated data, customer data, employee data, financial data, legal data, source code, security findings, privileged administrative records, or other high-value information.

·        Correlate sensitive-data access with outbound communication from the same task, trace, agent session, connector session, workload, browser session, process, source asset, application identity, or user identity.

·        Require the outbound communication to occur within a locally validated correlation window after the sensitive-data access.

·        Require the destination to be external, cross-tenant, public, personal, unmanaged, first-seen, rare, direct-IP, prohibited, or outside the approved task and connector destination set.

·        Increase confidence when the outbound volume, upload behavior, request count, destination category, session duration, or transfer timing differs materially from the source baseline.

·        Increase confidence when sensitive data is accessed through one connector and the outbound activity occurs through another connector, browser session, API, webhook, code-execution environment, or network path.

·        Increase confidence when the transfer follows a connector denial, policy block, approval rejection, recipient restriction, destination restriction, or DLP enforcement event.

·        Exclude approved reporting, synchronization, backup, migration, eDiscovery, legal, security, customer-support, incident-response, data-processing, collaboration, and administrative workflows.

·        Do not treat outbound traffic alone as evidence of sensitive-data disclosure when the upstream sensitive-access or data-classification event is unavailable.

Required Telemetry

·        Sensitive-data access events from SaaS platforms, databases, file platforms, repositories, secret stores, customer systems, financial systems, identity platforms, security platforms, cloud services, and internal applications.

·        Data-classification, sensitivity-label, DLP, information-protection, CASB, insider-risk, or data-security posture telemetry.

·        Enterprise AI-agent, task, session, trace, connector, identity, application, browser, workload, process, and source-asset identifiers.

·        NDR, DNS, proxy, firewall, flow, API-gateway, webhook, TLS, or endpoint-network telemetry.

·        Destination domain, IP, tenant, application, recipient, service, port, protocol, direction, and destination category.

·        Bytes sent, bytes received, upload indicators, request count, session duration, connection result, and first-seen context.

·        Approved source-to-destination data flows, connector combinations, recipients, tenants, APIs, webhooks, applications, and business workflows.

Engineering Implementation Instructions

·        Build a reference set containing enterprise AI agents, agent-associated users, service identities, applications, workloads, connector hosts, browser-automation systems, code-execution environments, and supporting assets.

·        Normalize sensitive-data-access events into a common schema containing the actor, agent, task, connector, resource, data classification, sensitivity, source platform, object identifier, and timestamp.

·        Correlate sensitive access and outbound activity using the strongest available key in this order: task identifier, trace identifier, agent session, connector session, workload identity, browser session, process identity, source asset, application identity, user identity, or bounded time relationship.

·        Use shorter correlation windows for interactive agents and longer locally validated windows for asynchronous or queued workflows.

·        Require a sensitive-data-access event, DLP event, data-classification event, or high-confidence sensitive-resource match before promoting the network activity from hunting to alerting.

·        Maintain approved source-to-destination, data-class-to-destination, and connector-to-connector flow mappings.

·        Apply higher priority to credentials, tokens, secrets, regulated data, customer data, employee data, financial data, legal data, source code, security findings, and privileged administrative records.

·        Apply higher priority to public links, personal recipients, unmanaged domains, cross-tenant destinations, anonymous services, public repositories, paste services, temporary storage, tunneling services, and direct-IP transfers.

·        Determine whether the transfer occurred after a connector denial, policy block, approval rejection, recipient restriction, destination restriction, or DLP enforcement event.

·        Suppress approved backups, migrations, exports, reporting, eDiscovery, legal workflows, data pipelines, support workflows, security investigations, incident response, and documented integrations.

·        Validate correlation cost, data volume, attribution quality, transfer thresholds, destination exceptions, and false positives in hunt mode before alert deployment.

·        Describe the result as sensitive enterprise data access followed by agent-associated external transfer, not confirmed trust injection or confirmed data exfiltration.

DRI Assessment

The rule remains effective when attackers change the original injected content, model, agent framework, connector, tool, destination, transfer path, encoding, data format, external service, or execution method. Variant resistance decreases when sensitive-access telemetry is unavailable, data is transformed before transfer, approved destinations are abused, or attribution is lost through shared connector, proxy, browser, or service identities.

DRI

8.8

TCR Assessment

Operational confidence depends on reliable agent and identity mapping, sensitive-data classification, data-access telemetry, outbound network visibility, approved data-flow mapping, correlation-key quality, and locally tested transfer thresholds. Full-telemetry confidence improves when network behavior can be correlated with agent, retrieval, tool-call, connector, approval, SaaS, DLP, endpoint, browser, and incident-response evidence.

Operational TCR

8.5

Full-Telemetry TCR

9.3

Limitations

·        Sensitive-data access may not be logged by all SaaS platforms, databases, repositories, file platforms, cloud services, or internal applications.

·        Read, preview, search, generated-output, and model-context activity may be absent from audit records.

·        Agent actions may appear under a human user, shared application, shared connector, service principal, or pooled service identity.

·        Shared proxies, NAT gateways, connector hosts, browser environments, and orchestration services may weaken attribution.

·        Encrypted communication may conceal transferred content.

·        Data may be summarized, encoded, translated, compressed, embedded, or fragmented before transfer.

·        Approved workflows may legitimately access sensitive data and communicate externally.

·        Outbound bytes, upload behavior, or destination rarity cannot independently prove that sensitive data was transferred.

·        Transfers occurring entirely between cloud-hosted models, connectors, and SaaS platforms may not traverse monitored network paths.

·        The rule cannot independently determine whether trust injection, malicious user direction, excessive agency, or workflow error caused the activity.

Detection Query Pattern

Use this pattern as an implementation guide for platforms that support enterprise AI-agent identity and workload grouping, sensitive-data-access normalization, data-classification enrichment, outbound network analysis, approved data-flow exceptions, aggregation, and task, session, connector, workload, browser, process, asset, application, or identity correlation.

LET agent_sensitive_access =
sensitive_data_access_events
WHERE actor_or_asset IN ENV_ENTERPRISE_AI_AGENT_IDENTITIES_AND_ASSETS
AND data_classification IN ENV_HIGH_VALUE_DATA_CLASSIFICATIONS

LET agent_external_transfer =
dns_proxy_firewall_ndr_api_gateway_webhook_or_flow_events
WHERE connection_direction = "outbound"
AND source_asset IN ENV_ENTERPRISE_AI_AGENT_WORKLOADS
AND (
destination_domain IS NULL
OR destination_domain NOT IN ENV_APPROVED_AGENT_EXTERNAL_DOMAINS
)
AND (
destination_ip IS NULL
OR destination_ip NOT IN ENV_APPROVED_AGENT_EXTERNAL_IPS
)
AND (
destination_tenant IS NULL
OR destination_tenant NOT IN ENV_APPROVED_AGENT_EXTERNAL_TENANTS
)
AND (
destination_is_external = true
OR destination_is_cross_tenant = true
OR destination_is_public = true
OR destination_is_unmanaged = true
)
AND (
bytes_sent >= ENV_SENSITIVE_TRANSFER_THRESHOLD
OR upload_detected = true
OR public_share_destination = true
OR personal_or_unmanaged_destination = true
OR destination_first_seen IN (
"new",
"rare"
)
OR cross_connector_sequence = true
OR correlated_connector_denial = true
OR correlated_policy_block = true
OR correlated_approval_rejection = true
)

ALERT WHEN
JOIN agent_sensitive_access
WITH agent_external_transfer
WHERE (
same_task_id = true
OR same_trace_id = true
OR same_agent_session_id = true
OR same_connector_session_id = true
OR same_workload_id = true
OR same_browser_session_id = true
OR same_process_id = true
OR same_source_asset = true
OR same_application_identity = true
OR same_actor_identity = true
)
AND event_sequence = "sensitive_access_then_external_transfer"
WITHIN ENV_AGENT_SENSITIVE_TRANSFER_WINDOW

OUTPUT
actor_identity,
application_identity,
agent_id,
agent_task_id,
trace_id,
agent_session_id,
connector_id,
connector_session_id,
source_platform,
resource_id,
data_classification,
source_asset,
source_workload_id,
source_process_id,
browser_session_id,
destination_domain,
destination_ip,
destination_tenant,
destination_category,
destination_reputation,
bytes_sent,
bytes_received,
upload_detected,
cross_connector_sequence,
correlated_connector_denial,
correlated_policy_block,
correlated_approval_rejection,
sensitive_access_time,
transfer_start_time,
first_seen,
last_seen

SentinelOne

Detection Viability Assessment

SentinelOne can provide viable endpoint and workload coverage for this report when enterprise AI agents use local runtimes, browser automation, desktop applications, code interpreters, connector services, self-hosted orchestration components, containers, or supporting servers.

SentinelOne can identify suspicious process execution, unexpected child processes, credential or token access, file staging, persistence, and outbound communication associated with agent activity. It cannot directly confirm that external content contained trust-injection instructions, that the agent’s task plan changed, that a human approval was valid, or that a cloud-hosted SaaS action completed. Those conclusions require agent, prompt, retrieval, tool-call, connector, identity, approval, SaaS audit, DLP, or incident-response evidence.

Two rules survive validation:

·        Unexpected command or automation execution from an enterprise AI-agent context.

·        Credential or sensitive-data access followed by staging or outbound activity.

Each rule is independently deployable and does not require another CyberDax rule to fire first.

Rule

Unexpected Command or Automation Execution From an Enterprise AI-Agent Context

Rule Format

SentinelOne behavioral-detection pattern using enterprise AI-agent process identification, parent-child process relationships, command-line analysis, script and automation-tool execution, approved-process exceptions, and optional network or connector context.

Detection Purpose

Detect unexpected operating-system command, script, browser-automation, code-execution, deployment, or administrative activity originating from an enterprise AI-agent runtime, browser, connector service, automation worker, code interpreter, orchestration component, container, or supporting process.

The rule identifies local execution behavior that may represent unauthorized tool use, browser or connector bypass, generated-code execution, payload retrieval, credential access, or downstream endpoint activity. It does not claim that SentinelOne directly observed trust injection, task-plan manipulation, approval bypass, or successful SaaS modification.

Detection Logic

·        Limit detection to known enterprise AI-agent runtimes, browsers, connector services, automation workers, code interpreters, orchestration components, containers, and supporting processes.

·        Identify child-process creation involving command shells, scripting engines, downloaders, archive utilities, source-control clients, deployment tools, package managers, credential utilities, remote-access tools, or administrative programs.

·        Detect command lines inconsistent with the approved function of the initiating agent or automation process.

·        Increase confidence when execution originates from a browser, office application, collaboration client, agent workspace, temporary directory, download directory, cache directory, user-writable path, or connector process.

·        Increase confidence when the process retrieves external content, creates or modifies scripts, writes executable files, accesses credentials, changes permissions, launches another interpreter, or initiates outbound communication.

·        Increase confidence when execution follows a denied connector action, policy block, approval rejection, browser-automation event, unexpected tool invocation, or suspicious agent task where that context is available.

·        Exclude approved development, deployment, testing, administrative, security, incident-response, browser-automation, and data-processing workflows.

·        Do not treat one shell, script interpreter, downloader, or administrative process as sufficient evidence without agent-context, ancestry, command-line, file, network, or behavioral support.

·        Do not classify the event as confirmed trust injection without upstream evidence showing that untrusted content materially influenced the agent’s behavior.

Required Telemetry

·        SentinelOne process creation and termination telemetry.

·        Full process path, command line, parent process, grandparent process, user, session, hash, signer, process identifier, and timestamp.

·        Enterprise AI-agent runtime, browser, connector, automation-worker, code-interpreter, orchestration, container, and supporting-process inventory.

·        File creation, modification, rename, deletion, hash, path, and initiating-process telemetry.

·        Network connection telemetry associated with the responsible process.

·        Credential, token, browser-storage, environment-file, secret, or sensitive-file access where available.

·        Agent task, session, connector, identity, approval, policy, or SaaS context where available.

·        Approved process, script, tool, path, deployment, and operational-window lookups.

Engineering Implementation Instructions

·        Build and maintain an authoritative inventory of enterprise AI-agent runtimes, browsers, connector services, automation workers, code interpreters, orchestration components, containers, and supporting processes.

·        Establish expected child-process behavior for each agent application, browser profile, connector service, runtime, or workload role.

·        Maintain approved process, signer, hash, script, command-line, path, tool, package-manager, source-control, deployment, and automation exceptions.

·        Require an unexpected parent-child relationship plus at least one material execution, file, credential, or network condition before promoting the detection from hunting to alerting.

·        Apply higher priority when agent-associated processes launch command shells, PowerShell, Bash, Python, JavaScript runtimes, package managers, downloaders, source-control clients, deployment tools, remote-access utilities, or credential-access utilities outside the approved workflow.

·        Apply higher priority when execution originates from temporary, cache, browser, download, collaboration, agent-workspace, or user-writable locations.

·        Apply higher priority when process execution is followed by credential access, script creation, executable-file creation, permission changes, external communication, or persistent configuration changes.

·        Tune approved software-development, CI/CD, browser-automation, security-testing, incident-response, administrative, data-science, and deployment environments separately.

·        Use connector, approval, policy, SaaS, and agent-task context only as enrichment. The rule must remain capable of detecting abnormal endpoint execution independently.

·        Validate parent-child relationships, command-line conditions, approved exceptions, and process-volume impact in hunt mode before alert deployment.

·        Describe the result as unexpected command or automation execution from an enterprise AI-agent context, not confirmed trust injection or unauthorized SaaS action.

DRI Assessment

The rule remains effective when attackers change the injected content, model, agent framework, script name, command, interpreter, browser, connector, tool, path, payload, or execution method. Variant resistance decreases when activity remains entirely inside an existing process, occurs only in a cloud-hosted service, or uses tools and child processes already approved for the agent workload.

DRI

8.7

TCR Assessment

Operational confidence depends on accurate agent-process identification, complete process ancestry, command-line visibility, approved child-process baselines, path context, and locally tested exceptions. Full-telemetry confidence improves when endpoint activity can be correlated with agent, retrieval, tool-call, connector, approval, identity, SaaS, DLP, and network evidence.

Operational TCR

8.4

Full-Telemetry TCR

9.1

Limitations

·        Cloud-hosted agents may perform all consequential actions without creating observable endpoint processes.

·        Browser automation and computer-use activity may remain inside an existing browser process.

·        Approved development, automation, deployment, security, and administrative tools may resemble suspicious execution.

·        Agent processes may share hosts, users, containers, or service identities with legitimate applications.

·        Command-line logging may be incomplete, truncated, redacted, or unavailable.

·        Script content may be generated or executed entirely in memory.

·        Signed or trusted tools may be used for unauthorized activity.

·        Short-lived processes may be missed if endpoint telemetry is delayed or filtered.

·        The rule cannot determine whether the initiating cause was trust injection, malicious user direction, excessive agency, or workflow error.

·        The rule cannot confirm whether a connected-SaaS action completed successfully.

Detection Query Pattern

Use this pattern as an implementation guide for SentinelOne environments that support enterprise AI-agent process grouping, parent-child process analysis, command-line inspection, file and network enrichment, and approved-process exceptions.

LET agent_process_activity =
sentinelone_process_events
WHERE (
parent_process IN ENV_ENTERPRISE_AI_AGENT_PROCESSES
OR grandparent_process IN ENV_ENTERPRISE_AI_AGENT_PROCESSES
)

LET suspicious_execution =
agent_process_activity
WHERE process_name IN ENV_HIGH_RISK_COMMAND_AND_AUTOMATION_PROCESSES
AND process_name NOT IN ENV_APPROVED_AGENT_CHILD_PROCESSES
AND (
command_line MATCHES ENV_SUSPICIOUS_AGENT_EXECUTION_PATTERNS
OR execution_path IN ENV_AGENT_HIGH_RISK_EXECUTION_PATHS
OR file_created = true
OR executable_file_created = true
OR credential_access_detected = true
OR outbound_connection_created = true
OR permission_change_detected = true
)

ALERT WHEN
suspicious_execution

OUTPUT
agent_id,
agent_task_id,
endpoint_name,
user_name,
parent_process_name,
parent_process_path,
grandparent_process_name,
process_name,
process_path,
command_line,
process_hash,
process_signer,
execution_path,
created_file_path,
created_file_hash,
credential_access_detected,
destination_domain,
destination_ip,
destination_port,
first_seen,
last_seen

Rule

Credential or Sensitive-Data Access Followed by Staging or Outbound Activity

Rule Format

SentinelOne behavioral-correlation pattern using enterprise AI-agent process identification, credential and sensitive-file access, file staging, archive or script creation, process ancestry, outbound network activity, and approved-workflow exceptions.

Detection Purpose

Detect an enterprise AI-agent runtime, browser, connector service, automation worker, code interpreter, orchestration component, container, or supporting process accessing credentials, tokens, secrets, sensitive files, browser sessions, environment data, source-control material, or cloud configuration and subsequently staging, transforming, archiving, or transmitting data.

The rule identifies endpoint-visible credential access, sensitive-data staging, and outbound activity without claiming that SentinelOne directly observed trust injection or confirmed data exfiltration.

Detection Logic

·        Limit detection to known enterprise AI-agent runtimes, browsers, connector services, automation workers, code interpreters, orchestration components, containers, and supporting processes.

·        Identify access to credential stores, browser credential data, session material, OAuth tokens, API keys, environment files, cloud credentials, source-control credentials, SSH material, service-account files, deployment secrets, or other sensitive local content.

·        Correlate the access with file staging, script creation, archive creation, encoding or compression activity, clipboard access, temporary-file creation, or outbound communication from the same process tree.

·        Require the staging or outbound activity to occur within a locally validated period after the sensitive access.

·        Increase confidence when the destination is new, rare, unmanaged, direct-IP, prohibited, or inconsistent with the approved agent workflow.

·        Increase confidence when the process creates an archive, encoded file, temporary collection file, script, command-output file, or data bundle after the sensitive access.

·        Increase confidence when the sequence follows a denied connector action, policy block, approval rejection, or unexpected agent task where that context is available.

·        Exclude approved credential-management, deployment, backup, migration, security, development, browser-management, incident-response, and administrative workflows.

·        Do not treat credential-file access or outbound communication alone as proof of credential theft or data disclosure.

Required Telemetry

·        SentinelOne process, file, and network telemetry.

·        Full process ancestry, command line, user, session, hash, signer, path, process identifier, and timestamp.

·        Credential-store, browser-storage, environment-file, secret-file, cloud-configuration, source-control, SSH, and service-account access telemetry where available.

·        File creation, modification, rename, compression, archive, encoding, deletion, and temporary-path activity.

·        Network destination, domain, IP, port, protocol, connection result, and bytes where available.

·        Enterprise AI-agent process and workload inventory.

·        Approved credential-management, deployment, backup, administration, security, and development exceptions.

·        Agent task, session, connector, policy, approval, DLP, identity, or SaaS context where available.

Engineering Implementation Instructions

·        Build and maintain an authoritative list of enterprise AI-agent processes, browsers, connector services, code interpreters, automation workers, orchestration components, containers, and supporting services.

·        Identify credential, token, secret, browser-storage, environment, source-control, SSH, cloud, deployment, and service-account locations relevant to each operating system and workload.

·        Normalize sensitive-access telemetry into categories such as credential store, browser session, OAuth token, API key, cloud credential, source-control credential, SSH material, environment secret, and service-account material.

·        Require sensitive access plus a material staging or outbound condition before generating a production alert.

·        Use the strongest available relationship in this order: same process, same process tree, same user session, same container, same workload, same source asset, or bounded time relationship.

·        Apply higher priority when sensitive access is followed by archive creation, encoded output, temporary collection files, scripts, command-output files, or external communication.

·        Apply higher priority when the destination is new, rare, unmanaged, direct-IP, prohibited, or outside the approved agent destination set.

·        Tune approved password managers, credential brokers, deployment systems, backup agents, security tools, source-control clients, browser-management systems, and administrative workflows separately.

·        Use connector, approval, policy, identity, DLP, and SaaS evidence only as enrichment. The rule must remain endpoint-deployable without another CyberDax rule firing first.

·        Validate credential paths, process relationships, correlation windows, staging indicators, network thresholds, and exceptions in hunt mode before alert deployment.

·        Describe the result as credential or sensitive-data access followed by staging or outbound activity, not confirmed credential theft, exfiltration, or trust injection.

DRI Assessment

The rule remains effective when attackers change the injected content, model, agent framework, credential type, file path, staging format, archive utility, script, destination, protocol, or transfer method. Variant resistance decreases when sensitive data is accessed only through cloud APIs, inherited directly by the process, retained only in memory, or transmitted through an approved destination without local staging.

DRI

8.8

TCR Assessment

Operational confidence depends on reliable agent-process mapping, sensitive-path coverage, complete process ancestry, file and network telemetry, approved-workflow exceptions, and locally tested correlation windows. Full-telemetry confidence improves when endpoint activity can be correlated with agent, connector, identity, approval, SaaS, DLP, browser, and network evidence.

Operational TCR

8.5

Full-Telemetry TCR

9.2

Limitations

·        Some credentials, tokens, secrets, and sensitive data may be accessed through cloud APIs without local file activity.

·        Sensitive values may be inherited through process environment, workload identity, browser sessions, or operating-system credential brokers.

·        Memory-only access may not produce file events.

·        Legitimate deployment, backup, development, browser, security, and administrative tools routinely access credentials and create archives or temporary files.

·        Agent actions may appear under a human user, shared service identity, connector service, or pooled runtime.

·        Shared hosts and containers may weaken attribution to a specific agent or task.

·        Encrypted network traffic may conceal transmitted content.

·        Data may be summarized, encoded, transformed, compressed, or fragmented before transmission.

·        Outbound activity may use an approved SaaS, API, webhook, repository, or cloud destination.

·        The rule cannot independently determine whether trust injection caused the activity or whether sensitive data was successfully disclosed.

Detection Query Pattern

Use this pattern as an implementation guide for SentinelOne environments that support enterprise AI-agent process grouping, credential and sensitive-file access, process-tree correlation, file staging, archive and script detection, outbound network enrichment, and approved-workflow exceptions.

LET agent_sensitive_access =
sentinelone_file_and_process_events
WHERE process_or_ancestor IN ENV_ENTERPRISE_AI_AGENT_PROCESSES
AND sensitive_resource_category IN ENV_AGENT_SENSITIVE_RESOURCE_CATEGORIES

LET staging_or_outbound_activity =
sentinelone_process_file_and_network_events
WHERE process_or_ancestor IN ENV_ENTERPRISE_AI_AGENT_PROCESSES
AND (
file_activity IN (
"archive_created",
"encoded_file_created",
"temporary_collection_file_created",
"script_created",
"command_output_created"
)
OR process_name IN ENV_AGENT_STAGING_AND_TRANSFER_PROCESSES
OR outbound_connection_created = true
)

ALERT WHEN
JOIN agent_sensitive_access
WITH staging_or_outbound_activity
WHERE (
same_process = true
OR same_process_tree = true
OR same_user_session = true
OR same_container = true
OR same_workload = true
OR same_source_asset = true
)
AND event_sequence = "sensitive_access_then_staging_or_outbound_activity"
WITHIN ENV_AGENT_SENSITIVE_ACTIVITY_WINDOW

OUTPUT
agent_id,
agent_task_id,
endpoint_name,
user_name,
process_name,
process_path,
parent_process_name,
grandparent_process_name,
command_line,
sensitive_resource_category,
sensitive_resource_path,
file_activity,
created_file_path,
created_file_hash,
destination_domain,
destination_ip,
destination_port,
bytes_sent,
correlated_policy_block,
correlated_connector_denial,
correlated_approval_rejection,
sensitive_access_time,
activity_start_time,
first_seen,
last_seen

Splunk

Detection Viability Assessment

Splunk can provide strong correlation coverage for this report when enterprise AI-agent, connector, identity, approval, SaaS, DLP, endpoint, network, and cloud audit events are normalized and retain reliable task, session, user, application, connector, object, and action identifiers.

Splunk can identify high-impact actions without valid approval, cross-connector sensitive-data transfer, alternate execution after a denied action, and consequential partial workflow execution. It cannot directly reconstruct hidden model reasoning or prove that trust injection caused the activity unless prompt, retrieval, task-plan, or agent-trace evidence is available.

Three rules survive validation:

·        High-impact agent action without valid approval.

·        Sensitive-data access followed by transfer through another connector or destination.

·        Denied agent action followed by alternate-path or partial execution.

Each rule is independently deployable and does not require another CyberDax rule to fire first.

Rule

High-Impact Agent Action Without Valid Approval

Rule Format

Splunk correlation-search pattern using enterprise AI-agent activity, approval records, policy decisions, executed-action parameters, high-impact action classification, and approved-workflow exceptions.

Detection Purpose

Detect an enterprise AI agent, agent-associated application, service identity, connector, or automation workflow performing a high-impact action without a corresponding valid approval or outside the parameters reviewed and approved by an authorized user.

The rule identifies missing approval, expired approval, rejected approval, approval-to-execution mismatch, and execution outside the approved task or workflow. It does not claim that the action resulted from trust injection unless upstream agent or content evidence supports that conclusion.

Detection Logic

·        Limit detection to enterprise AI agents, agent-associated applications, service identities, connectors, and automation workflows.

·        Identify actions classified as high impact, including external sharing, bulk data access, deletion, permission changes, identity changes, financial actions, source-control changes, deployment actions, security-control changes, workflow modifications, and administrative operations.

·        Correlate the executed action with the strongest available approval identifier, task identifier, trace identifier, workflow identifier, session identifier, user, application, connector, resource, and bounded time relationship.

·        Alert when no matching approval exists.

·        Alert when the matching approval was rejected, revoked, expired, cancelled, or issued for another user, application, connector, resource, tenant, or workflow.

·        Alert when executed parameters materially exceed or differ from approved parameters.

·        Alert when execution occurs outside the approved time window or after the associated approval was invalidated.

·        Exclude deterministic workflows that have documented standing authorization and remain within their approved scope.

·        Exclude approved break-glass, emergency-response, testing, migration, recovery, and administrative activity.

·        Do not treat an approval-recording delay as approval bypass without confirming the expected event-ingestion sequence.

Required Telemetry

·        Enterprise AI-agent, task, trace, workflow, connector, application, service-identity, and session events.

·        Approval request, decision, approver, status, timestamp, expiration, resource, action, and approved-parameter records.

·        Executed action, actor, target, resource, object, tenant, recipient, permission, quantity, and resulting status.

·        SaaS, cloud, identity, source-control, financial, security, collaboration, and administrative audit logs.

·        Policy-engine and authorization-decision events where available.

·        Approved standing-authority, deterministic-workflow, emergency-access, and operational-window lookups.

Engineering Implementation Instructions

·        Build an authoritative inventory of enterprise AI agents, agent-associated applications, connectors, service identities, workflows, and high-impact actions.

·        Normalize approval and execution records into common fields for actor, agent, task, workflow, connector, action, resource, object, tenant, parameters, timestamp, and status.

·        Use an exact approval identifier when available.

·        When an exact approval identifier is unavailable, correlate using task, trace, workflow, connector, actor, resource, action, and a locally validated time window.

·        Compare only material parameters that define the approved action, including resource, recipient, tenant, permission, quantity, scope, destination, and operation type.

·        Distinguish missing approval from approval mismatch, expired approval, rejected approval, and post-revocation execution.

·        Maintain documented standing-authority exceptions for deterministic workflows that do not require per-action human approval.

·        Account for delayed approval-event ingestion before enabling production alerting.

·        Apply higher priority to identity changes, external sharing, destructive actions, security-control modification, financial activity, source-code changes, deployment actions, and privileged administrative operations.

·        Describe the result as a high-impact agent action without valid approval, not confirmed trust injection or malicious intent.

DRI Assessment

The rule remains effective when attackers change the injected content, model, agent framework, application, connector, target object, execution sequence, or action parameters. Variant resistance decreases when approval records are incomplete, action parameters are not retained, standing authority is poorly documented, or task and workflow identifiers are unavailable.

DRI

8.9

TCR Assessment

Operational confidence depends on reliable approval telemetry, accurate high-impact action classification, consistent parameter normalization, and strong correlation between approval and execution. Full-telemetry confidence improves when agent traces, task plans, connector events, identity records, policy decisions, and resulting-state evidence are available.

Operational TCR

8.7

Full-Telemetry TCR

9.5

Limitations

·        Some agent platforms do not retain exact approved parameters.

·        Approval and execution events may arrive out of order.

·        Standing authorization may be represented outside the monitored approval system.

·        Shared service identities may weaken attribution to a specific agent or user.

·        A valid approval may still authorize an unsafe action.

·        An approval mismatch may result from workflow transformation, object renaming, or connector normalization.

·        Some high-impact actions may not produce complete audit events.

·        The rule cannot determine whether trust injection, malicious user direction, excessive agency, or operator error caused the action.

Detection Query Pattern

Use this pattern as an implementation guide for Splunk environments that support enterprise AI-agent activity grouping, approval-event normalization, executed-parameter comparison, high-impact action classification, and standing-authority exceptions.

LET high_impact_agent_actions =

normalized_agent_and_saas_events

WHERE actor_or_application IN ENV_ENTERPRISE_AI_AGENT_IDENTITIES

AND action_category IN ENV_HIGH_IMPACT_AGENT_ACTIONS

LET relevant_approval_records =

normalized_approval_events

WHERE approval_status IN (

"approved",

"rejected",

"revoked",

"expired",

"cancelled"

)

LET action_approval_evaluation =

high_impact_agent_actions

LEFT JOIN relevant_approval_records

ON (

same_approval_id = true

OR (

action_approval_id IS NULL

AND same_task_id = true

AND same_workflow_id = true

AND same_actor_or_application = true

AND same_action = true

AND same_resource = true

)

)

AND approval_time <= action_event_time

WITHIN ENV_AGENT_APPROVAL_CORRELATION_WINDOW

ALERT FROM action_approval_evaluation

WHEN (

matching_approval_found = false

OR approval_status != "approved"

OR approval_revoked = true

OR approval_expiration_time < action_event_time

OR approved_parameters_match_executed_parameters = false

OR execution_within_approved_window = false

)

AND standing_authority_match = false

AND approved_emergency_activity = false

OUTPUT

agent_id,

actor_identity,

application_identity,

task_id,

trace_id,

workflow_id,

connector_id,

approval_id,

approval_status,

approver,

approved_action,

executed_action,

approved_resource,

executed_resource,

approved_parameters,

executed_parameters,

action_result,

target_tenant,

target_recipient,

action_event_time,

approval_time,

approval_expiration_time

Rule

Sensitive-Data Access Followed by Transfer Through Another Connector or Destination

Rule Format

Splunk correlation-search pattern using enterprise AI-agent data access, data classification, connector activity, SaaS audit records, outbound destination context, approved data-flow mappings, and task, session, identity, or workload correlation.

Detection Purpose

Detect an enterprise AI agent or agent-associated identity accessing sensitive information through one service, connector, repository, or application and subsequently transferring, sharing, uploading, emailing, posting, or writing that information through another connector or to an unapproved destination.

The rule identifies cross-connector data movement and suspicious sensitive-access-to-transfer sequences without claiming that Splunk directly observed the exact content transferred or proved trust injection.

Detection Logic

·        Limit detection to enterprise AI agents, agent-associated identities, applications, connectors, workflows, and workloads.

·        Identify access to data classified as restricted, confidential, regulated, credential-related, customer, employee, financial, legal, source code, security-sensitive, or privileged administrative.

·        Correlate the sensitive access with a later external share, upload, message, post, write, API call, webhook call, repository action, or cross-tenant transfer.

·        Require the transfer to occur through another connector, another application, another tenant, another destination, or a destination outside the approved data-flow map.

·        Use the strongest available task, trace, workflow, session, connector, application, identity, object, or bounded time relationship.

·        Increase confidence when the destination is public, personal, unmanaged, cross-tenant, first-seen, or prohibited.

·        Increase confidence when the sequence follows a DLP event, connector denial, recipient restriction, policy block, or approval rejection.

·        Exclude approved reporting, synchronization, backup, migration, eDiscovery, legal, security, support, data-processing, and incident-response workflows.

·        Do not alert solely because an agent accessed sensitive data or used more than one connector.

Required Telemetry

·        Enterprise AI-agent, task, trace, workflow, session, identity, application, and connector events.

·        Sensitive-data access events from SaaS platforms, repositories, databases, file services, secret stores, customer systems, financial platforms, identity systems, and security tools.

·        Data-classification, sensitivity-label, DLP, CASB, information-protection, or insider-risk telemetry.

·        Transfer, share, upload, message, email, post, repository, webhook, API, and cross-tenant activity.

·        Source connector, destination connector, source platform, destination platform, resource, object, recipient, tenant, destination, and timestamp.

·        Approved data-flow, connector-pair, destination, tenant, recipient, and workflow lookups.

Engineering Implementation Instructions

·        Normalize sensitive-access and transfer events into common fields for actor, agent, task, workflow, connector, application, resource, object, classification, destination, tenant, recipient, action, and timestamp.

·        Use task, trace, workflow, or session identifiers when available.

·        When direct identifiers are unavailable, correlate by agent identity, application identity, connector identity, resource, user, and a locally validated time window.

·        Require a sensitive-data event plus a material transfer or sharing action.

·        Require the transfer connector, destination, recipient, tenant, or workflow to differ from or fall outside the approved data-flow definition.

·        Maintain approved connector-pair, source-to-destination, data-class-to-destination, recipient, tenant, and workflow mappings.

·        Apply higher priority to credentials, tokens, secrets, regulated data, customer records, financial data, legal data, source code, security findings, and privileged administrative records.

·        Apply higher priority to public links, personal accounts, unmanaged applications, external tenants, public repositories, paste services, and anonymous file-sharing services.

·        Account for duplicated, delayed, or retried connector events before enabling production alerting.

·        Describe the result as sensitive-data access followed by transfer through another connector or destination, not confirmed data exfiltration or trust injection.

DRI Assessment

The rule remains effective when attackers change the injected content, model, agent framework, source service, destination service, connector, object, recipient, file type, data format, or transfer method. Variant resistance decreases when data classification is unavailable, actions use approved destinations, content is transformed before transfer, or agent attribution is lost through shared identities.

DRI

9.0

TCR Assessment

Operational confidence depends on reliable data classification, complete source and destination audit logs, connector identification, approved data-flow mapping, and strong correlation identifiers. Full-telemetry confidence improves when DLP, approval, policy, agent-trace, endpoint, and network evidence are available.

Operational TCR

8.8

Full-Telemetry TCR

9.6

Limitations

·        Some services do not log read, preview, search, or generated-output activity.

·        Data classification may be missing, stale, or inconsistent.

·        Shared identities may weaken attribution to a specific agent or task.

·        Data may be summarized, transformed, translated, encoded, or fragmented before transfer.

·        Legitimate workflows may use multiple connectors.

·        An approved destination may still be misused.

·        Connector retries may create duplicate events.

·        The rule cannot prove that the transferred content was identical to the sensitive content accessed.

·        The rule cannot independently determine whether trust injection caused the sequence.

Detection Query Pattern

Use this pattern as an implementation guide for Splunk environments that support enterprise AI-agent identity grouping, sensitive-data-access normalization, connector correlation, destination enrichment, approved data-flow mapping, and bounded sequence analysis.

LET agent_sensitive_access =

normalized_sensitive_data_events

WHERE actor_or_application IN ENV_ENTERPRISE_AI_AGENT_IDENTITIES

AND data_classification IN ENV_HIGH_VALUE_DATA_CLASSIFICATIONS

LET agent_transfer_activity =

normalized_connector_and_saas_events

WHERE actor_or_application IN ENV_ENTERPRISE_AI_AGENT_IDENTITIES

AND action_category IN (

"external_share",

"upload",

"send",

"post",

"write",

"webhook",

"api_transfer",

"repository_publish",

"cross_tenant_transfer"

)

ALERT WHEN

JOIN agent_sensitive_access

WITH agent_transfer_activity

WHERE (

same_task_id = true

OR same_trace_id = true

OR same_workflow_id = true

OR same_agent_session_id = true

OR (

same_actor_or_application = true

AND same_source_resource_or_object = true

)

)

AND event_sequence = "sensitive_access_then_transfer"

AND (

source_connector != destination_connector

OR source_platform != destination_platform

OR destination_tenant != source_tenant

OR destination NOT IN ENV_APPROVED_AGENT_DATA_DESTINATIONS

)

AND approved_data_flow_match = false

WITHIN ENV_AGENT_SENSITIVE_TRANSFER_WINDOW

OUTPUT

agent_id,

actor_identity,

application_identity,

task_id,

trace_id,

workflow_id,

agent_session_id,

source_connector,

destination_connector,

source_platform,

destination_platform,

source_resource,

source_object,

data_classification,

transfer_action,

destination,

destination_tenant,

recipient,

approved_data_flow_match,

correlated_dlp_event,

correlated_policy_block,

correlated_connector_denial,

sensitive_access_time,

transfer_time

Rule

Denied Agent Action Followed by Alternate-Path or Partial Execution

Rule Format

Splunk sequence-correlation pattern using enterprise AI-agent action attempts, policy and connector denials, subsequent tool or connector use, resulting-state events, approved retry behavior, and task, workflow, identity, resource, or time-based correlation.

Detection Purpose

Detect an enterprise AI agent or agent-associated workflow receiving a denial, policy block, approval rejection, or connector failure and subsequently completing the same or a materially equivalent objective through another connector, application, browser path, API, identity, tool, or partial workflow step.

The rule identifies policy circumvention, alternate execution, and consequential partial completion without claiming that every retry or fallback represents malicious behavior.

Detection Logic

·        Limit detection to enterprise AI agents, agent-associated applications, service identities, connectors, and workflows.

·        Identify denied, blocked, rejected, or failed actions involving access, sharing, deletion, permission changes, external communication, administrative activity, deployment, financial action, or security-control modification.

·        Identify a subsequent action by the same agent, task, workflow, identity, application, or closely related execution context.

·        Require the later action to pursue the same or a materially equivalent resource, object, recipient, destination, permission, or business outcome.

·        Alert when the later action uses another connector, application, browser path, API, tool, identity, tenant, or execution method.

·        Alert when part of the denied workflow completes and produces a consequential state change before the remaining steps fail or are blocked.

·        Increase confidence when the later action succeeds or creates a persistent, externally visible, destructive, privileged, or data-transfer result.

·        Exclude documented failover, retry, resilience, queue-recovery, connector fallback, and administrative workflows.

·        Do not alert on repeated failures that produce no meaningful state change.

Required Telemetry

·        Enterprise AI-agent, task, trace, workflow, session, application, connector, and identity events.

·        Policy-denial, connector-denial, approval-rejection, authorization-failure, and action-failure events.

·        Subsequent SaaS, cloud, identity, browser, API, endpoint, source-control, financial, and administrative actions.

·        Resource, object, recipient, destination, permission, tenant, action, result, and resulting-state records.

·        Approved failover, retry, fallback, queue-recovery, testing, and operational-window lookups.

Engineering Implementation Instructions

·        Normalize denial and subsequent-action events into common fields for agent, task, workflow, connector, identity, action, resource, object, recipient, destination, tenant, permission, result, and timestamp.

·        Use exact task, trace, workflow, or session identifiers when available.

·        When direct identifiers are unavailable, correlate by agent identity, application identity, resource, target, action objective, and a locally validated time window.

·        Define material equivalence using the business objective, target resource, recipient, destination, permission, or resulting state rather than requiring identical event names.

·        Require either successful alternate execution or a consequential partial state change.

·        Maintain approved retry, failover, connector fallback, queue recovery, and resilience patterns.

·        Apply higher priority when the sequence involves external sharing, privileged identity changes, deletion, security-control changes, financial actions, deployment, source-code modification, or sensitive-data transfer.

·        Account for duplicate events and asynchronous connector completion before enabling production alerting.

·        Describe the result as denied agent activity followed by alternate-path or partial execution, not confirmed malicious intent or trust injection.

DRI Assessment

The rule remains effective when attackers change the injected content, model, agent framework, connector, tool, application, identity, action name, execution order, or fallback path. Variant resistance decreases when denial and success events cannot be linked, resulting-state telemetry is unavailable, or legitimate fallback behavior is not documented.

DRI

8.8

TCR Assessment

Operational confidence depends on complete denial telemetry, reliable agent and workflow attribution, accurate action-equivalence mapping, resulting-state visibility, and approved fallback exceptions. Full-telemetry confidence improves when approval, policy, agent-trace, browser, endpoint, SaaS, identity, and network evidence are available.

Operational TCR

8.6

Full-Telemetry TCR

9.4

Limitations

·        Legitimate applications may retry through another endpoint, connector, region, or service.

·        Asynchronous actions may complete after an apparent denial.

·        A connector may report failure even when part of the operation succeeded.

·        Duplicate or delayed events may distort sequence order.

·        Shared identities may weaken attribution to a specific agent or task.

·        Equivalent business outcomes may use different event names and object identifiers.

·        Resulting-state events may be unavailable or delayed.

·        The rule cannot determine whether alternate execution resulted from trust injection, legitimate resilience, user instruction, or workflow error.

Detection Query Pattern

Use this pattern as an implementation guide for Splunk environments that support enterprise AI-agent identity grouping, denial-event normalization, action-objective comparison, alternate-path detection, resulting-state analysis, and approved fallback exceptions.

LET denied_agent_activity =

normalized_agent_policy_connector_and_approval_events

WHERE actor_or_application IN ENV_ENTERPRISE_AI_AGENT_IDENTITIES

AND action_result IN (

"denied",

"blocked",

"rejected",

"unauthorized",

"failed_by_policy"

)

LET subsequent_agent_activity =

normalized_agent_saas_cloud_identity_browser_and_endpoint_events

WHERE actor_or_application IN ENV_ENTERPRISE_AI_AGENT_IDENTITIES

ALERT WHEN

JOIN denied_agent_activity

WITH subsequent_agent_activity

WHERE (

same_task_id = true

OR same_trace_id = true

OR same_workflow_id = true

OR same_agent_session_id = true

OR (

same_actor_or_application = true

AND same_target_context = true

)

)

AND same_or_equivalent_action_objective = true

AND (

connector_changed = true

OR application_changed = true

OR execution_path_changed = true

OR identity_changed = true

OR tenant_changed = true

OR browser_or_api_fallback = true

OR consequential_partial_state_change = true

)

AND (

subsequent_action_result = "success"

OR consequential_partial_state_change = true

)

AND approved_fallback_match = false

WITHIN ENV_AGENT_ALTERNATE_EXECUTION_WINDOW

OUTPUT

agent_id,

actor_identity,

application_identity,

task_id,

trace_id,

workflow_id,

agent_session_id,

denied_action,

denial_reason,

denied_connector,

denied_resource,

denied_destination,

subsequent_action,

subsequent_connector,

subsequent_application,

subsequent_identity,

subsequent_resource,

subsequent_destination,

execution_path_changed,

same_or_equivalent_action_objective,

subsequent_action_result,

consequential_partial_state_change,

denial_time,

subsequent_action_time

Elastic

Detection Viability Assessment

Elastic can provide strong endpoint, network, identity, cloud, and SaaS correlation coverage for this report when enterprise AI-agent workloads, processes, applications, service identities, connectors, and supporting infrastructure are identified and relevant events are normalized into Elastic Common Schema or another consistent field model.

Elastic can identify unexpected execution from agent-associated processes, sensitive-data access followed by external transfer, and unauthorized identity, permission, connector, workflow, or persistent configuration changes. It cannot directly prove that untrusted content altered an agent’s instructions or task plan unless agent, prompt, retrieval, or trace telemetry is available.

Three rules survive validation:

·        Unexpected execution from an enterprise AI-agent process or workload.

·        Sensitive-data access followed by agent-associated external transfer.

·        Unauthorized agent-associated identity, permission, or persistent configuration change.

Each rule is independently deployable and does not require another CyberDax rule to fire first.

Rule

Unexpected Execution From an Enterprise AI-Agent Process or Workload

Rule Format

Elastic behavioral-detection pattern using enterprise AI-agent process and workload identification, process ancestry, command-line analysis, file activity, network activity, approved-process exceptions, and optional agent or connector context.

Detection Purpose

Detect unexpected command, script, browser-automation, code-execution, deployment, package-management, download, or administrative activity originating from an enterprise AI-agent runtime, connector service, browser, automation worker, orchestration component, container, pod, workload, or supporting process.

The rule identifies endpoint-visible execution that may represent unauthorized tool use, connector bypass, generated-code execution, payload retrieval, credential access, or downstream activity. It does not claim that Elastic directly observed trust injection, task-plan manipulation, approval bypass, or successful SaaS modification.

Detection Logic

·        Limit detection to known enterprise AI-agent processes, runtimes, browsers, connector services, automation workers, code interpreters, orchestration components, containers, pods, and supporting workloads.

·        Identify child-process or workload execution involving command shells, scripting engines, downloaders, archive utilities, source-control clients, package managers, deployment tools, credential utilities, remote-access tools, or administrative programs.

·        Detect process ancestry or command-line behavior inconsistent with the approved function of the initiating agent or workload.

·        Increase confidence when execution originates from a browser, connector process, temporary directory, download directory, cache directory, user-writable path, agent workspace, or container write layer.

·        Increase confidence when execution creates scripts, writes executable files, changes permissions, accesses credentials, launches another interpreter, or initiates external communication.

·        Exclude approved software-development, deployment, browser-automation, testing, security, incident-response, data-processing, and administrative workflows.

·        Do not treat one shell, interpreter, package manager, downloader, or administrative utility as sufficient evidence without agent context and supporting process, file, or network behavior.

·        Do not classify the activity as confirmed trust injection without upstream evidence that untrusted content materially influenced the agent.

Required Telemetry

·        Elastic Defend, endpoint, process, container, Kubernetes, workload, and network telemetry.

·        Process name, executable path, command line, parent process, ancestor process, user, session, hash, signer, process identifier, and timestamp.

·        Enterprise AI-agent process, application, connector, container, pod, workload, and supporting-service inventory.

·        File creation, modification, rename, deletion, hash, path, and initiating-process telemetry.

·        Network connections associated with the responsible process or workload.

·        Credential, token, environment-file, browser-storage, secret, or sensitive-file access where available.

·        Approved process, script, path, tool, deployment, and operational-window lookups.

Engineering Implementation Instructions

·        Build and maintain an authoritative inventory of enterprise AI-agent processes, runtimes, browsers, connector services, automation workers, code interpreters, orchestration components, containers, pods, and supporting workloads.

·        Establish expected process ancestry and child-process behavior for each agent application, runtime, workload role, and connector.

·        Maintain approved process, signer, hash, script, command-line, path, package-manager, source-control, deployment, and automation exceptions.

·        Require an unexpected agent-associated execution relationship plus at least one material command-line, file, credential, or network condition before promoting the rule from hunting to alerting.

·        Apply higher priority when agent-associated processes launch shells, scripting engines, package managers, downloaders, source-control clients, deployment tools, remote-access utilities, or credential-access utilities outside the approved workflow.

·        Tune development, CI/CD, data-science, browser-automation, security-testing, incident-response, and administrative systems separately.

·        Preserve agent and workload attribution through container, Kubernetes, service-mesh, serverless, and shared-host environments where possible.

·        Validate process relationships, command-line patterns, approved exceptions, and event volume in hunt mode before alert deployment.

·        Describe the result as unexpected execution from an enterprise AI-agent process or workload, not confirmed trust injection or unauthorized SaaS activity.

DRI Assessment

The rule remains effective when attackers change the injected content, model, agent framework, process name, script, command, interpreter, browser, connector, tool, path, payload, or execution method. Variant resistance decreases when activity remains inside an existing process, occurs entirely in a cloud-hosted service, or uses child processes already approved for the agent workload.

DRI

8.8

TCR Assessment

Operational confidence depends on accurate agent and workload identification, complete process ancestry, command-line visibility, approved execution baselines, path context, and locally tested exceptions. Full-telemetry confidence improves when endpoint activity can be correlated with agent, retrieval, tool-call, connector, approval, identity, SaaS, DLP, and network evidence.

Operational TCR

8.5

Full-Telemetry TCR

9.2

Limitations

·        Cloud-hosted agents may perform consequential activity without creating observable endpoint processes.

·        Browser automation may remain inside an existing browser process.

·        Approved development, deployment, security, and administrative tools may resemble suspicious execution.

·        Agent processes may share hosts, users, containers, or service identities with legitimate applications.

·        Command-line data may be incomplete, truncated, redacted, or unavailable.

·        Scripts or commands may execute entirely in memory.

·        Signed or trusted tools may be used for unauthorized activity.

·        Shared container or workload infrastructure may weaken attribution to a specific agent or task.

·        The rule cannot determine whether trust injection, malicious user direction, excessive agency, or workflow error caused the activity.

Detection Query Pattern

Use this pattern as an implementation guide for Elastic environments that support enterprise AI-agent process and workload grouping, process ancestry, command-line inspection, file and network enrichment, and approved-process exceptions.

LET agent_process_activity =

elastic_process_and_workload_events

WHERE (

process_parent IN ENV_ENTERPRISE_AI_AGENT_PROCESSES

OR process_ancestor IN ENV_ENTERPRISE_AI_AGENT_PROCESSES

OR workload_id IN ENV_ENTERPRISE_AI_AGENT_WORKLOADS

)

LET suspicious_execution =

agent_process_activity

WHERE process_name IN ENV_HIGH_RISK_COMMAND_AND_AUTOMATION_PROCESSES

AND process_name NOT IN ENV_APPROVED_AGENT_CHILD_PROCESSES

AND (

command_line MATCHES ENV_SUSPICIOUS_AGENT_EXECUTION_PATTERNS

OR execution_path IN ENV_AGENT_HIGH_RISK_EXECUTION_PATHS

OR executable_file_created = true

OR credential_access_detected = true

OR outbound_connection_created = true

OR permission_change_detected = true

)

ALERT WHEN

suspicious_execution

OUTPUT

agent_id,

agent_task_id,

host_name,

container_id,

kubernetes_pod_name,

user_name,

process_parent_name,

process_ancestor_name,

process_name,

process_executable,

process_command_line,

process_hash,

process_signer,

created_file_path,

credential_access_detected,

destination_domain,

destination_ip,

destination_port,

first_seen,

last_seen

Rule

Sensitive-Data Access Followed by Agent-Associated External Transfer

Rule Format

Elastic sequence-correlation pattern using enterprise AI-agent identity and workload mapping, sensitive-data-access events, data-classification context, outbound network or SaaS transfer activity, approved data-flow exceptions, and task, session, workload, process, or identity correlation.

Detection Purpose

Detect an enterprise AI agent, agent-associated identity, connector, application, browser session, workload, or process accessing sensitive enterprise information and subsequently transferring, sharing, uploading, posting, emailing, or otherwise sending data to an external or unapproved destination.

The rule identifies suspicious sensitive-access-to-transfer behavior without claiming that Elastic directly observed the exact content transferred or proved trust injection.

Detection Logic

·        Limit detection to enterprise AI agents, agent-associated identities, applications, connectors, browsers, workloads, and processes.

·        Identify access to credentials, tokens, secrets, regulated data, customer data, employee data, financial data, legal data, source code, security findings, or privileged administrative records.

·        Correlate the sensitive access with a later outbound network connection, external share, upload, message, post, API call, webhook call, repository action, or cross-tenant transfer.

·        Use the strongest available task, trace, session, connector, workload, process, source asset, application, or identity relationship.

·        Require the destination, recipient, tenant, connector, application, or data flow to fall outside the approved workflow.

·        Increase confidence when the destination is public, personal, unmanaged, cross-tenant, first-seen, rare, prohibited, or direct-IP.

·        Increase confidence when the transfer follows a DLP event, connector denial, policy block, approval rejection, or recipient restriction.

·        Exclude approved reporting, synchronization, backup, migration, eDiscovery, legal, security, support, data-processing, and incident-response workflows.

·        Do not alert solely because an agent accessed sensitive data or initiated outbound communication.

Required Telemetry

·        Enterprise AI-agent, task, trace, session, identity, application, connector, browser, workload, process, and source-asset events.

·        Sensitive-data access events from SaaS platforms, databases, repositories, file services, secret stores, customer systems, financial platforms, identity systems, security tools, cloud services, and internal applications.

·        Data-classification, sensitivity-label, DLP, CASB, information-protection, or insider-risk telemetry.

·        Network, proxy, firewall, DNS, API-gateway, webhook, SaaS, repository, email, messaging, and sharing events.

·        Source and destination application, connector, resource, object, recipient, tenant, domain, IP, action, and timestamp.

·        Approved data-flow, connector-pair, destination, tenant, recipient, and workflow lookups.

Engineering Implementation Instructions

·        Normalize sensitive-access and transfer events into common fields for actor, agent, task, session, connector, application, workload, process, resource, object, classification, destination, tenant, recipient, action, and timestamp.

·        Use task, trace, session, connector, workload, or process identifiers when available.

·        When direct identifiers are unavailable, correlate by agent identity, application identity, source asset, resource, and a locally validated time window.

·        Require a sensitive-data event plus a material transfer, sharing, upload, or outbound communication event.

·        Require the transfer destination, recipient, tenant, connector, application, or workflow to fall outside the approved data-flow definition.

·        Maintain approved source-to-destination, connector-pair, data-class-to-destination, recipient, tenant, and workflow mappings.

·        Apply higher priority to credentials, tokens, secrets, regulated information, customer records, financial data, legal data, source code, security findings, and privileged administrative records.

·        Apply higher priority to public links, personal accounts, unmanaged applications, external tenants, public repositories, paste services, temporary storage, tunneling services, and direct-IP destinations.

·        Account for duplicate, delayed, retried, and asynchronous connector or SaaS events before enabling production alerting.

·        Describe the result as sensitive-data access followed by agent-associated external transfer, not confirmed data exfiltration or trust injection.

DRI Assessment

The rule remains effective when attackers change the injected content, model, agent framework, source service, destination service, connector, object, recipient, file type, data format, encoding, or transfer method. Variant resistance decreases when data classification is unavailable, approved destinations are abused, content is transformed before transfer, or agent attribution is lost through shared identities or workloads.

DRI

9.0

TCR Assessment

Operational confidence depends on reliable data classification, complete source and destination telemetry, approved data-flow mapping, and strong correlation identifiers. Full-telemetry confidence improves when DLP, approval, policy, agent-trace, endpoint, SaaS, browser, and network evidence are available.

Operational TCR

8.7

Full-Telemetry TCR

9.5

Limitations

·        Some services do not log read, preview, search, or generated-output activity.

·        Data classification may be missing, stale, or inconsistent.

·        Shared identities and workloads may weaken attribution to a specific agent or task.

·        Data may be summarized, transformed, translated, encoded, compressed, or fragmented before transfer.

·        Legitimate workflows may use multiple connectors or destinations.

·        An approved destination may still be misused.

·        Encrypted network traffic may conceal transferred content.

·        Transfers occurring entirely within cloud-hosted services may not create endpoint or network events.

·        The rule cannot prove that the transferred content was identical to the sensitive content accessed.

·        The rule cannot independently determine whether trust injection caused the sequence.

Detection Query Pattern

Use this pattern as an implementation guide for Elastic environments that support enterprise AI-agent identity and workload grouping, sensitive-data-access normalization, outbound network and SaaS activity, approved data-flow mapping, and bounded sequence analysis.

LET agent_sensitive_access =

normalized_sensitive_data_events

WHERE actor_or_application IN ENV_ENTERPRISE_AI_AGENT_IDENTITIES

AND data_classification IN ENV_HIGH_VALUE_DATA_CLASSIFICATIONS

LET agent_transfer_activity =

normalized_network_saas_connector_and_messaging_events

WHERE actor_or_application IN ENV_ENTERPRISE_AI_AGENT_IDENTITIES

AND action_category IN (

"external_share",

"upload",

"send",

"post",

"webhook",

"api_transfer",

"repository_publish",

"cross_tenant_transfer",

"outbound_network_transfer"

)

ALERT WHEN

JOIN agent_sensitive_access

WITH agent_transfer_activity

WHERE (

same_task_id = true

OR same_trace_id = true

OR same_agent_session_id = true

OR same_connector_session_id = true

OR same_workload_id = true

OR same_process_tree = true

OR (

same_actor_or_application = true

AND same_source_resource_or_object = true

)

)

AND event_sequence = "sensitive_access_then_transfer"

AND approved_data_flow_match = false

WITHIN ENV_AGENT_SENSITIVE_TRANSFER_WINDOW

OUTPUT

agent_id,

actor_identity,

application_identity,

task_id,

trace_id,

agent_session_id,

connector_id,

source_platform,

source_resource,

source_object,

data_classification,

transfer_action,

destination_application,

destination_connector,

destination_domain,

destination_ip,

destination_tenant,

recipient,

approved_data_flow_match,

correlated_dlp_event,

correlated_policy_block,

sensitive_access_time,

transfer_time

Rule

Unauthorized Agent-Associated Identity, Permission, or Persistent Configuration Change

Rule Format

Elastic correlation pattern using enterprise AI-agent identity and application mapping, identity-provider and cloud audit events, SaaS administrative activity, workflow and connector configuration changes, approved-change exceptions, and resulting-state validation.

Detection Purpose

Detect an enterprise AI agent, agent-associated application, connector, service identity, workload, or automation process creating or changing identities, permissions, OAuth grants, application consent, tokens, service principals, connector authorizations, workflows, policies, memory stores, instructions, or persistent configuration outside the approved task or administrative workflow.

The rule identifies privilege expansion and persistent behavioral or access changes without claiming that Elastic directly observed the trust-injection content that caused the action.

Detection Logic

·        Limit detection to enterprise AI agents, agent-associated users, applications, connectors, service identities, workloads, and automation processes.

·        Identify creation or modification of users, service identities, service principals, application registrations, OAuth grants, API tokens, credentials, roles, permissions, policies, connectors, workflows, instructions, memory stores, scheduled automation, or persistent agent configuration.

·        Require the change to fall outside an approved administrative, deployment, onboarding, integration, or change-management workflow.

·        Increase confidence when the change expands privileges, adds external access, enables new connectors, creates durable credentials, changes approval requirements, weakens security controls, or persists agent behavior.

·        Increase confidence when the change is followed by use of the new identity, permission, connector, token, workflow, or configuration.

·        Increase confidence when the activity occurs after a denial, policy block, approval rejection, or failed attempt through another identity or connector.

·        Exclude approved onboarding, deployment, integration, rotation, recovery, testing, emergency-access, and administrative changes.

·        Do not alert solely because an agent-associated identity performs a documented configuration or permission change within its approved role.

Required Telemetry

·        Enterprise AI-agent, application, connector, user, service-identity, workload, task, session, and workflow events.

·        Identity-provider, OAuth, application-consent, service-principal, token, credential, role, permission, and policy audit logs.

·        SaaS, cloud, source-control, CI/CD, security-platform, workflow, orchestration, and administrative audit events.

·        Connector, tool, agent instruction, memory, workflow, policy, and persistent-configuration change events where available.

·        Actor, application, identity, target, resource, permission, scope, tenant, connector, action, result, and timestamp.

·        Approved change request, deployment, onboarding, integration, rotation, emergency-access, and operational-window lookups.

Engineering Implementation Instructions

·        Build an authoritative inventory of enterprise AI agents, agent-associated users, applications, connectors, service identities, workloads, and authorized administrative roles.

·        Normalize identity, permission, connector, workflow, and configuration changes into common fields for actor, agent, application, identity, target, resource, permission, scope, tenant, connector, action, result, and timestamp.

·        Classify changes by effect, including privilege expansion, new external access, durable credential creation, connector enablement, approval-control modification, security-control weakening, and persistent behavior change.

·        Require an unauthorized or out-of-workflow change with a material security or persistence effect.

·        Use subsequent use of the new identity, permission, connector, token, workflow, or configuration as confidence enrichment rather than a mandatory condition.

·        Maintain approved deployment, onboarding, integration, credential-rotation, administrative, emergency-access, and change-management exceptions.

·        Apply higher priority to privileged roles, broad OAuth scopes, external application consent, durable credentials, security-control changes, approval-policy changes, public sharing, cross-tenant access, and persistent agent instructions or workflows.

·        Account for delayed, duplicated, retried, and automatically generated administrative events.

·        Describe the result as an unauthorized agent-associated identity, permission, or persistent configuration change, not confirmed trust injection or malicious intent.

DRI Assessment

The rule remains effective when attackers change the injected content, model, agent framework, identity type, connector, token, permission, scope, workflow, configuration object, or administrative interface. Variant resistance decreases when changes occur through unlogged systems, approved administrative identities, inherited permissions, or platforms that do not expose agent configuration and memory changes.

DRI

8.9

TCR Assessment

Operational confidence depends on complete identity and administrative audit logs, accurate agent and application mapping, approved-change records, material-change classification, and reliable resulting-state evidence. Full-telemetry confidence improves when agent traces, approval events, connector logs, SaaS activity, endpoint evidence, and subsequent use of the changed object are available.

Operational TCR

8.7

Full-Telemetry TCR

9.5

Limitations

·        Some agent platforms do not expose changes to instructions, memory, tools, or workflow state.

·        Shared administrative identities may weaken attribution to a specific agent or task.

·        Legitimate onboarding, integration, deployment, and credential rotation can resemble privilege expansion.

·        Broad permissions may have been approved before monitoring began.

·        Inherited roles and nested groups may obscure the effective privilege change.

·        Some SaaS and cloud services delay or omit administrative audit events.

·        Automatic application updates may change connectors, scopes, or configuration.

·        Subsequent use of a new identity, permission, or connector may occur much later.

·        The rule cannot determine whether trust injection, malicious user direction, excessive agency, or operator error caused the change.

Detection Query Pattern

Use this pattern as an implementation guide for Elastic environments that support enterprise AI-agent identity and application grouping, identity and administrative audit normalization, material-change classification, approved-change exceptions, and resulting-state enrichment.

LET agent_administrative_changes =

normalized_identity_saas_cloud_and_agent_configuration_events

WHERE actor_or_application IN ENV_ENTERPRISE_AI_AGENT_IDENTITIES

AND action_category IN (

"identity_created",

"service_principal_created",

"oauth_grant_added",

"application_consent_added",

"token_created",

"credential_created",

"role_assigned",

"permission_added",

"policy_changed",

"connector_enabled",

"workflow_changed",

"approval_control_changed",

"security_control_changed",

"agent_instruction_changed",

"agent_memory_changed",

"persistent_configuration_changed"

)

LET material_unauthorized_changes =

agent_administrative_changes

WHERE approved_change_match = false

AND (

privilege_expansion = true

OR new_external_access = true

OR durable_credential_created = true

OR connector_access_expanded = true

OR approval_control_weakened = true

OR security_control_weakened = true

OR persistent_agent_behavior_changed = true

)

ALERT WHEN

material_unauthorized_changes

OUTPUT

agent_id,

actor_identity,

application_identity,

task_id,

trace_id,

workflow_id,

target_identity,

target_application,

target_resource,

action_category,

permission_or_scope,

connector_id,

target_tenant,

privilege_expansion,

new_external_access,

durable_credential_created,

connector_access_expanded,

approval_control_weakened,

security_control_weakened,

persistent_agent_behavior_changed,

approved_change_match,

subsequent_use_detected,

event_time

QRadar

Detection Viability Assessment

QRadar can provide strong correlation coverage for this report when enterprise AI-agent, connector, identity, SaaS, cloud, DLP, network, endpoint, and approval events are normalized and associated with reliable agent, application, service-identity, task, workflow, resource, and destination context.

QRadar can identify unauthorized high-impact actions, agent-associated identity or connector expansion, and denied activity followed by successful alternate execution. It cannot directly reconstruct hidden model reasoning or prove that trust injection caused the activity unless agent, prompt, retrieval, task-plan, or trace evidence is available.

Three rules survive validation:

·        Unauthorized high-impact agent-associated action.

·        Agent-associated identity, permission, or connector expansion.

·        Denied agent activity followed by successful alternate execution.

Each rule is independently deployable and does not require another CyberDax rule to fire first.

Rule

Unauthorized High-Impact Agent-Associated Action

Rule Format

QRadar correlation-rule pattern using enterprise AI-agent identity and application mapping, high-impact action classification, approval and policy context, approved-workflow exceptions, and resulting-action evidence.

Detection Purpose

Detect an enterprise AI agent, agent-associated application, service identity, connector, or workflow performing a high-impact SaaS, cloud, identity, source-control, financial, security, collaboration, or administrative action outside an approved workflow, standing authorization, or valid approval.

The rule identifies materially unauthorized actions without claiming that QRadar directly observed trust injection or determined malicious intent.

Detection Logic

·        Limit detection to known enterprise AI agents, agent-associated applications, connectors, service identities, and workflows.

·        Identify high-impact actions involving external sharing, bulk access, deletion, permission changes, identity changes, financial activity, source-control modification, deployment, security-control changes, workflow changes, or privileged administration.

·        Require the action to fall outside an approved workflow, standing authorization, operational window, or valid approval.

·        Increase confidence when the action affects a privileged identity, sensitive resource, external tenant, public recipient, production system, security control, source repository, financial object, or regulated dataset.

·        Increase confidence when the action follows a policy denial, approval rejection, connector restriction, DLP event, or unusual agent task where that context is available.

·        Exclude approved emergency response, migration, recovery, deployment, testing, break-glass, and administrative activity.

·        Do not alert solely because an agent-associated identity performs an action classified as high impact.

·        Do not classify the event as confirmed trust injection without upstream evidence showing that untrusted content materially influenced the agent.

Required Telemetry

·        Enterprise AI-agent, application, connector, workflow, task, session, user, and service-identity events.

·        SaaS, cloud, identity, source-control, financial, security, collaboration, and administrative audit logs.

·        Approval, policy, authorization, and standing-authority records where available.

·        Actor, application, action, target, resource, object, recipient, tenant, permission, result, and timestamp.

·        Approved workflow, administrative activity, emergency access, testing, deployment, migration, and operational-window reference sets.

Engineering Implementation Instructions

·        Build authoritative reference sets for enterprise AI agents, associated applications, service identities, connectors, workflows, and high-impact actions.

·        Normalize relevant events into common properties for actor, application, agent, action, resource, object, tenant, recipient, permission, result, and timestamp.

·        Maintain reference sets for approved workflows, standing authority, emergency access, operational windows, and authorized administrative identities.

·        Require a high-impact action plus an authorization, approval, workflow, or scope violation before creating an offense.

·        Apply higher magnitude to actions affecting privileged identities, sensitive data, production systems, external tenants, public sharing, financial operations, source code, deployment systems, and security controls.

·        Use policy, approval, DLP, connector, and agent-task events as confidence enrichment where available.

·        Account for duplicated, delayed, and asynchronously completed SaaS or connector events.

·        Validate event mappings, reference sets, offense magnitude, and false positives in rule-testing or low-magnitude mode before production deployment.

·        Describe the result as an unauthorized high-impact agent-associated action, not confirmed trust injection or malicious intent.

DRI Assessment

The rule remains effective when attackers change the injected content, model, agent framework, connector, application, identity, action name, target object, or execution sequence. Variant resistance decreases when agent identities are not distinguished from shared service identities, high-impact actions are poorly classified, or approved workflows are not documented.

DRI

8.9

TCR Assessment

Operational confidence depends on reliable agent and identity mapping, complete audit logs, accurate high-impact action classification, approved-workflow reference sets, and authorization context. Full-telemetry confidence improves when approval, policy, agent-trace, connector, DLP, endpoint, and resulting-state evidence are available.

Operational TCR

8.7

Full-Telemetry TCR

9.4

Limitations

·        Some SaaS and cloud platforms may not provide complete action or resulting-state events.

·        Shared service identities may weaken attribution to a specific agent or task.

·        Approved workflows may be represented outside monitored systems.

·        High-impact classifications may require local tuning.

·        Legitimate emergency, migration, deployment, and administrative activity may resemble unauthorized action.

·        A valid approval may still authorize an unsafe action.

·        Delayed events may cause approval or workflow context to arrive after the action event.

·        The rule cannot determine whether trust injection, malicious user direction, excessive agency, or operator error caused the activity.

Detection Query Pattern

Use this pattern as an implementation guide for QRadar environments that support enterprise AI-agent identity grouping, high-impact action classification, reference-set lookups, approval and workflow enrichment, and offense generation.

LET high_impact_agent_activity =

normalized_qradar_events

WHERE actor_or_application IN REF_ENTERPRISE_AI_AGENT_IDENTITIES

AND action_category IN REF_HIGH_IMPACT_AGENT_ACTIONS

AND event_time NOT IN REF_APPROVED_AGENT_OPERATIONAL_WINDOWS

LET unauthorized_high_impact_activity =

high_impact_agent_activity

WHERE approved_workflow_match = false

AND standing_authority_match = false

AND approved_emergency_activity = false

AND (

valid_approval_match = false

OR action_outside_approved_scope = true

OR action_outside_approved_window = true

)

ALERT WHEN

unauthorized_high_impact_activity

OUTPUT

agent_id,

actor_identity,

application_identity,

task_id,

workflow_id,

connector_id,

action_category,

action_name,

target_resource,

target_object,

target_tenant,

target_recipient,

permission_or_scope,

action_result,

valid_approval_match,

approved_workflow_match,

standing_authority_match,

event_time

Rule

Agent-Associated Identity, Permission, or Connector Expansion

Rule Format

QRadar correlation-rule pattern using enterprise AI-agent identity and application mapping, identity-provider and SaaS administrative events, permission and OAuth changes, connector authorization, approved-change reference sets, and optional subsequent-use context.

Detection Purpose

Detect an enterprise AI agent, agent-associated application, connector, service identity, or workflow creating or modifying identities, roles, permissions, OAuth grants, application consent, tokens, credentials, connectors, or access paths outside an approved administrative or change-management process.

The rule identifies privilege and access expansion without claiming that QRadar directly observed the trust-injection content that caused the change.

Detection Logic

·        Limit detection to known enterprise AI agents, agent-associated users, applications, connectors, service identities, and workflows.

·        Identify creation or modification of users, service identities, service principals, application registrations, OAuth grants, consent records, API tokens, credentials, roles, permissions, policies, or connector authorizations.

·        Require the change to fall outside an approved onboarding, deployment, integration, credential-rotation, emergency-access, or administrative process.

·        Require a material effect such as privilege expansion, durable credential creation, broad scope assignment, new external access, connector enablement, cross-tenant access, or weakened approval or security controls.

·        Increase confidence when the new identity, permission, token, connector, or access path is subsequently used.

·        Increase confidence when the change follows a denial, policy block, approval rejection, or failed attempt using another identity or connector.

·        Exclude approved onboarding, integration, deployment, rotation, recovery, testing, emergency-access, and administrative changes.

·        Do not alert solely because an agent-associated identity performs a documented configuration change within its authorized role.

Required Telemetry

·        Enterprise AI-agent, application, connector, workflow, user, service-identity, task, and session events.

·        Identity-provider, OAuth, application-consent, token, credential, role, permission, policy, connector, SaaS, and cloud administrative logs.

·        Actor, application, target identity, target application, resource, tenant, scope, permission, connector, action, result, and timestamp.

·        Approved change-management, onboarding, integration, deployment, credential-rotation, emergency-access, and operational-window reference sets.

·        Subsequent authentication or use events where available.

Engineering Implementation Instructions

·        Build reference sets for enterprise AI agents, associated identities, applications, connectors, workflows, and authorized administrators.

·        Normalize identity, permission, OAuth, credential, policy, and connector events into common properties.

·        Classify material changes as privilege expansion, new external access, durable credential creation, broad scope assignment, connector enablement, cross-tenant access, or security-control weakening.

·        Require both an unauthorized change and a material access or persistence effect before generating an offense.

·        Treat subsequent use of the changed identity, token, permission, or connector as confidence enrichment rather than a mandatory condition.

·        Maintain approved onboarding, integration, deployment, credential-rotation, emergency-access, and change-management reference sets.

·        Apply higher magnitude to privileged roles, broad OAuth scopes, external consent, durable credentials, cross-tenant access, security-control changes, and approval-policy changes.

·        Account for automated service-principal creation, application updates, inherited roles, and delayed audit events.

·        Validate normalized properties, material-change classifications, reference sets, and offense magnitude before production deployment.

·        Describe the result as agent-associated identity, permission, or connector expansion, not confirmed trust injection or account compromise.

DRI Assessment

The rule remains effective when attackers change the injected content, model, agent framework, identity type, application, connector, token, permission, scope, tenant, or administrative interface. Variant resistance decreases when changes occur through unlogged systems, inherited permissions, approved administrative identities, or platforms with incomplete audit records.

DRI

8.8

TCR Assessment

Operational confidence depends on complete identity and administrative audit logs, accurate agent and application mapping, approved-change reference sets, and reliable material-change classification. Full-telemetry confidence improves when approval, policy, agent-trace, SaaS, endpoint, and subsequent-use evidence are available.

Operational TCR

8.6

Full-Telemetry TCR

9.4

Limitations

·        Some platforms may not log all OAuth, consent, token, connector, or permission changes.

·        Shared administrative identities may weaken attribution to a specific agent or task.

·        Inherited permissions and nested groups may obscure the effective privilege change.

·        Legitimate onboarding, integration, deployment, and credential rotation can resemble access expansion.

·        Broad permissions may have been approved before monitoring began.

·        Automated application updates may change scopes, connectors, or service identities.

·        Subsequent use may occur long after the original change.

·        The rule cannot determine whether trust injection, malicious user direction, excessive agency, or operator error caused the change.

Detection Query Pattern

Use this pattern as an implementation guide for QRadar environments that support enterprise AI-agent identity grouping, identity and administrative event normalization, reference-set lookups, material-change classification, and optional subsequent-use enrichment.

LET agent_identity_and_access_changes =

normalized_identity_saas_and_cloud_events

WHERE actor_or_application IN REF_ENTERPRISE_AI_AGENT_IDENTITIES

AND action_category IN (

"identity_created",

"service_principal_created",

"oauth_grant_added",

"application_consent_added",

"token_created",

"credential_created",

"role_assigned",

"permission_added",

"policy_changed",

"connector_enabled"

)

AND event_time NOT IN REF_APPROVED_AGENT_OPERATIONAL_WINDOWS

LET material_unauthorized_expansion =

agent_identity_and_access_changes

WHERE approved_change_match = false

AND (

privilege_expansion = true

OR new_external_access = true

OR durable_credential_created = true

OR broad_scope_assigned = true

OR connector_access_expanded = true

OR cross_tenant_access_enabled = true

OR security_control_weakened = true

)

ALERT WHEN

material_unauthorized_expansion

OUTPUT

agent_id,

actor_identity,

application_identity,

task_id,

workflow_id,

target_identity,

target_application,

action_category,

permission_or_scope,

connector_id,

target_tenant,

privilege_expansion,

new_external_access,

durable_credential_created,

broad_scope_assigned,

connector_access_expanded,

cross_tenant_access_enabled,

security_control_weakened,

approved_change_match,

subsequent_use_detected,

event_time

Rule

Denied Agent Activity Followed by Successful Alternate Execution

Rule Format

QRadar sequence-correlation pattern using enterprise AI-agent denial events, subsequent action events, resource and objective matching, connector or execution-path changes, approved fallback reference sets, and resulting-action evidence.

Detection Purpose

Detect an enterprise AI agent, agent-associated application, service identity, connector, or workflow receiving a denial, policy block, approval rejection, or authorization failure and subsequently completing the same or a materially equivalent objective through another connector, application, identity, tenant, browser path, API, or execution method.

The rule identifies successful alternate execution and policy circumvention without treating every retry or failover as malicious.

Detection Logic

·        Limit detection to known enterprise AI agents, agent-associated applications, connectors, service identities, and workflows.

·        Identify denied, blocked, rejected, unauthorized, or policy-failed actions involving access, sharing, deletion, permission changes, external communication, administration, deployment, financial activity, or security-control modification.

·        Identify a later action associated with the same task, workflow, session, application, identity, resource, destination, recipient, or business objective.

·        Require the later action to pursue the same or a materially equivalent outcome.

·        Require a change in connector, application, identity, tenant, browser path, API, tool, or execution method.

·        Require the later action to succeed or produce a consequential partial state change.

·        Exclude documented retry, resilience, failover, connector fallback, queue-recovery, testing, and administrative behavior.

·        Do not alert on repeated failures that produce no meaningful state change.

Required Telemetry

·        Enterprise AI-agent, task, workflow, session, application, connector, identity, and action events.

·        Policy-denial, connector-denial, approval-rejection, authorization-failure, and action-failure events.

·        Subsequent SaaS, cloud, identity, browser, API, endpoint, source-control, financial, and administrative events.

·        Resource, object, recipient, destination, permission, tenant, action, result, and resulting-state properties.

·        Approved retry, failover, connector fallback, queue-recovery, testing, and operational-window reference sets.

Engineering Implementation Instructions

·        Normalize denial and subsequent-action events into common properties for agent, task, workflow, connector, identity, action, resource, object, recipient, destination, tenant, result, and timestamp.

·        Use exact task, workflow, trace, or session identifiers when available.

·        When direct identifiers are unavailable, correlate by agent identity, application identity, target resource, recipient, destination, action objective, and a locally validated time window.

·        Define equivalent objectives using the target resource, recipient, destination, permission, action category, or resulting state.

·        Require successful alternate execution or a consequential partial state change before generating an offense.

·        Maintain approved retry, resilience, failover, connector fallback, queue-recovery, and administrative reference sets.

·        Apply higher magnitude to external sharing, privileged identity changes, deletion, financial activity, deployment, source-code modification, security-control changes, and sensitive-data transfer.

·        Account for duplicate events, connector retries, delayed status changes, and asynchronous completion.

·        Describe the result as denied agent activity followed by successful alternate execution, not confirmed trust injection or malicious intent.

DRI Assessment

The rule remains effective when attackers change the injected content, model, agent framework, connector, application, identity, action name, execution order, or fallback method. Variant resistance decreases when denial and success events cannot be linked, equivalent objectives cannot be derived, or legitimate fallback behavior is not documented.

DRI

8.8

TCR Assessment

Operational confidence depends on complete denial telemetry, reliable agent and workflow attribution, accurate objective matching, successful-action evidence, and approved fallback reference sets. Full-telemetry confidence improves when approval, policy, agent-trace, browser, endpoint, SaaS, identity, and network evidence are available.

Operational TCR

8.6

Full-Telemetry TCR

9.4

Limitations

·        Legitimate applications may retry through another connector, endpoint, region, identity, or service.

·        Asynchronous actions may complete after an apparent denial.

·        A connector may report failure even when part of the operation succeeded.

·        Duplicate or delayed events may distort sequence order.

·        Shared identities may weaken attribution to a specific agent or task.

·        Equivalent outcomes may use different event names, objects, or identifiers.

·        Resulting-state evidence may be delayed or unavailable.

·        The rule cannot determine whether alternate execution resulted from trust injection, legitimate resilience, user instruction, or workflow error.

Detection Query Pattern

Use this pattern as an implementation guide for QRadar environments that support enterprise AI-agent grouping, denial-event normalization, objective matching, alternate-path detection, resulting-action analysis, reference-set exceptions, and bounded sequence correlation.

LET denied_agent_activity =

normalized_agent_policy_connector_and_approval_events

WHERE actor_or_application IN REF_ENTERPRISE_AI_AGENT_IDENTITIES

AND action_result IN (

"denied",

"blocked",

"rejected",

"unauthorized",

"failed_by_policy"

)

AND event_time NOT IN REF_APPROVED_AGENT_OPERATIONAL_WINDOWS

LET subsequent_agent_activity =

normalized_agent_saas_cloud_identity_browser_and_endpoint_events

WHERE actor_or_application IN REF_ENTERPRISE_AI_AGENT_IDENTITIES

ALERT WHEN

JOIN denied_agent_activity

WITH subsequent_agent_activity

WHERE (

same_task_id = true

OR same_workflow_id = true

OR same_agent_session_id = true

OR (

same_actor_or_application = true

AND same_target_context = true

)

)

AND same_or_equivalent_action_objective = true

AND (

connector_changed = true

OR application_changed = true

OR identity_changed = true

OR tenant_changed = true

OR execution_path_changed = true

OR browser_or_api_fallback = true

)

AND (

subsequent_action_result = "success"

OR consequential_partial_state_change = true

)

AND approved_fallback_match = false

WITHIN ENV_AGENT_ALTERNATE_EXECUTION_WINDOW

OUTPUT

agent_id,

actor_identity,

application_identity,

task_id,

workflow_id,

agent_session_id,

denied_action,

denial_reason,

denied_connector,

denied_resource,

denied_destination,

subsequent_action,

subsequent_connector,

subsequent_application,

subsequent_identity,

subsequent_resource,

subsequent_destination,

same_or_equivalent_action_objective,

subsequent_action_result,

consequential_partial_state_change,

denial_time,

subsequent_action_time

SIGMA

Detection Viability Assessment

SIGMA can provide portable endpoint and workload coverage for this report when enterprise AI-agent runtimes, browser-automation processes, connector services, code interpreters, orchestration components, and supporting workloads produce normalized process, file, and credential-access events.

SIGMA can identify unexpected command or automation execution and agent-associated sensitive-resource access followed by staging activity. It cannot directly detect cloud-hosted trust injection, approval mismatch, cross-connector SaaS transfer, hidden task-plan changes, or successful SaaS actions without platform-specific correlation outside the SIGMA rule.

Two rules survive validation:

·        Unexpected command or automation execution from an enterprise AI-agent process.

·        Agent-associated sensitive-resource access followed by staging activity.

Each rule is independently deployable and does not require another CyberDax rule to fire first.

Rule

Unexpected Command or Automation Execution From an Enterprise AI-Agent Process

Rule Format

Portable SIGMA process-creation pattern using enterprise AI-agent parent or ancestor identification, high-risk command and automation processes, suspicious command-line context, approved-process exceptions, and supporting file or network evidence where available.

Detection Purpose

Detect an enterprise AI-agent runtime, browser-automation process, connector service, code interpreter, automation worker, orchestration component, or supporting process launching an unexpected command shell, scripting engine, downloader, package manager, source-control client, deployment tool, remote-access utility, credential utility, or administrative program with suspicious execution context.

The rule identifies endpoint-visible execution that may represent unauthorized tool use, generated-code execution, connector bypass, payload retrieval, credential access, or downstream activity. It does not claim that SIGMA directly observed trust injection, task-plan manipulation, approval bypass, or successful SaaS modification.

Detection Logic

·        Limit detection to process creation in which the parent or ancestor belongs to an approved inventory of enterprise AI-agent, connector, browser-automation, code-execution, or orchestration processes.

·        Identify command shells, scripting engines, downloaders, package managers, archive utilities, source-control clients, deployment tools, remote-access utilities, credential utilities, and administrative programs.

·        Require the child process to fall outside the approved child-process baseline for the initiating agent application or workload.

·        Require suspicious command-line context involving download, execution, credential, permission, archive, encoding, remote-access, or external-transfer behavior.

·        Increase confidence when execution occurs from a temporary, cache, browser, download, collaboration, agent-workspace, or user-writable path.

·        Exclude approved development, deployment, browser-automation, testing, security, incident-response, data-processing, and administrative workflows.

·        Do not alert solely because an agent-associated process launches a shell, interpreter, package manager, or administrative utility.

·        Do not classify the activity as confirmed trust injection without upstream evidence showing that untrusted content materially influenced the agent.

Required Telemetry

·        Process creation telemetry from Windows Security, Sysmon, Linux audit, EDR, container, or equivalent event sources.

·        Process name, executable path, command line, parent process, ancestor process where available, user, host, process identifier, hash, signer, and timestamp.

·        Enterprise AI-agent, browser-automation, connector, code-interpreter, orchestration, and supporting-process inventory.

·        Approved child-process, tool, script, path, signer, hash, and operational-window exceptions.

·        File and network enrichment where supported by the implementing platform.

Engineering Implementation Instructions

·        Build and maintain a platform-specific inventory of enterprise AI-agent and supporting processes.

·        Establish approved child-process behavior for each agent application, browser profile, connector service, runtime, and workload role.

·        Translate the portable field names to the target event source and confirm that parent-process and command-line data are consistently populated.

·        Maintain approved child-process, signer, hash, tool, script, command-line, and execution-path exceptions.

·        Require an agent-associated parent or ancestor, an unexpected high-risk child process, and suspicious command-line context.

·        Use path, file, or network context to increase severity where available.

·        Tune development, CI/CD, browser-automation, security-testing, incident-response, and administrative systems separately.

·        Validate parent-child relationships, command-line visibility, field mappings, and expected process volume before production deployment.

·        Describe the result as unexpected command or automation execution from an enterprise AI-agent process, not confirmed trust injection or unauthorized SaaS activity.

DRI Assessment

The rule remains effective when attackers change the injected content, model, agent framework, command, script name, interpreter, browser, connector, utility, path, payload, or execution method. Variant resistance decreases when activity remains inside an existing process, occurs entirely in a cloud-hosted service, or uses child processes and command patterns already approved for the agent workload.

DRI

8.5

TCR Assessment

Operational confidence depends on accurate agent-process identification, complete process ancestry, command-line visibility, approved child-process baselines, and correct field mapping. Full-telemetry confidence improves when the SIGMA match can be correlated with file, network, credential-access, agent, connector, identity, approval, and SaaS evidence.

Operational TCR

8.1

Full-Telemetry TCR

8.9

Limitations

·        Cloud-hosted agents may perform consequential actions without creating observable endpoint processes.

·        Browser automation may remain inside an existing browser process.

·        Approved development, deployment, security, and administrative tools may resemble suspicious execution.

·        Parent or ancestor data may be incomplete or unavailable.

·        Command-line data may be truncated, redacted, or missing.

·        Scripts or commands may execute entirely in memory.

·        Signed or trusted tools may be used for unauthorized activity.

·        Shared hosts, containers, and service identities may weaken attribution to a specific agent or task.

·        The rule cannot determine whether trust injection, malicious user direction, excessive agency, or workflow error caused the activity.

Detection Query Pattern

Use this pattern as an implementation guide for SIGMA-compatible event sources that support enterprise AI-agent parent-process identification, process creation, command-line inspection, execution-path context, and approved-process exceptions.

title: Unexpected Command or Automation Execution From an Enterprise AI-Agent Process

logsource:

  category: process_creation

detection:

  agent_parent:

    ParentImage|endswith:

      - '\approved_agent_runtime.exe'

      - '\approved_connector_service.exe'

      - '\approved_browser_automation.exe'

      - '/approved/agent-runtime'

      - '/approved/connector-service'

  high_risk_child:

    Image|endswith:

      - '\cmd.exe'

      - '\powershell.exe'

      - '\pwsh.exe'

      - '\wscript.exe'

      - '\cscript.exe'

      - '\python.exe'

      - '\node.exe'

      - '\curl.exe'

      - '\wget.exe'

      - '\git.exe'

      - '\ssh.exe'

      - '/sh'

      - '/bash'

      - '/python'

      - '/node'

      - '/curl'

      - '/wget'

      - '/git'

      - '/ssh'

  suspicious_context:

    CommandLine|contains:

      - 'http://'

      - 'https://'

      - 'download'

      - 'encode'

      - 'base64'

      - 'credential'

      - 'token'

      - 'chmod'

      - 'invoke'

      - 'exec'

  approved_child_process:

    Image|endswith:

      - '\approved_agent_child.exe'

      - '/approved/agent-child'

  condition: agent_parent and high_risk_child and suspicious_context and not approved_child_process

fields:

  - Computer

  - User

  - ParentImage

  - Image

  - CommandLine

  - ProcessId

  - ParentProcessId

  - Hashes

  - Signature

falsepositives:

  - Approved development, deployment, browser-automation, testing, security, and administrative activity

level: high

Rule

Agent-Associated Sensitive-Resource Access Followed by Staging Activity

Rule Format

Portable SIGMA correlation concept using enterprise AI-agent process identification, sensitive-resource access, archive or staging activity, and process-tree relationships.

Detection Purpose

Detect an enterprise AI-agent runtime, browser, connector service, code interpreter, automation worker, orchestration component, or supporting process accessing credentials, tokens, secrets, browser sessions, environment files, cloud credentials, source-control credentials, SSH material, service-account files, or other sensitive local resources and subsequently staging or transforming that information.

The rule identifies endpoint-visible sensitive-resource access followed by archive creation, temporary-file creation, script output, encoding, compression, or execution of staging and transfer utilities. It does not claim that SIGMA directly observed trust injection or confirmed credential theft or data exfiltration.

Detection Logic

·        Limit detection to sensitive-resource access by an enterprise AI-agent process or its process tree.

·        Identify access to credential stores, browser credential data, session material, OAuth tokens, API keys, environment files, cloud credentials, source-control credentials, SSH material, service-account files, deployment secrets, or other locally defined sensitive resources.

·        Correlate the access with archive creation, encoded-output creation, temporary collection files, script output, compression, or execution of staging and transfer utilities from the same process tree.

·        Require the staging activity to occur within a locally validated period after the sensitive-resource access.

·        Exclude approved credential-management, deployment, backup, migration, browser-management, development, security, incident-response, and administrative workflows.

·        Do not treat sensitive-file access, archive creation, encoding, compression, or transfer-tool execution alone as proof of credential theft or data disclosure.

Required Telemetry

·        Process creation, file access, file creation, archive, and staging events from Sysmon, Windows Security, Linux audit, EDR, container, or equivalent sources.

·        Process name, executable path, command line, parent process, process identifier, user, host, file path, and timestamp.

·        Locally defined credential, token, secret, browser-storage, cloud-configuration, source-control, SSH, environment, and service-account resource paths.

·        Enterprise AI-agent and supporting-process inventory.

·        Approved credential-management, deployment, backup, administration, security, and development exceptions.

Engineering Implementation Instructions

·        Maintain operating-system-specific lists of sensitive credential, token, secret, browser-storage, environment, cloud, source-control, SSH, deployment, and service-account resources.

·        Build and maintain an inventory of enterprise AI-agent and supporting processes.

·        Correlate sensitive-resource access with staging activity using the same process, process tree, user session, container, workload, or host.

·        Use the shortest correlation relationship supported by the target platform.

·        Require sensitive-resource access plus a material staging condition.

·        Apply higher priority when sensitive access is followed by archive creation, encoded output, temporary collection files, script output, compression, or execution of staging and transfer utilities.

·        Tune password managers, credential brokers, deployment systems, backup tools, security products, source-control clients, browser-management systems, and administrative workflows separately.

·        Validate event-source coverage, sensitive paths, process relationships, correlation windows, and exceptions before production deployment.

·        Describe the result as agent-associated sensitive-resource access followed by staging activity, not confirmed credential theft, data exfiltration, or trust injection.

DRI Assessment

The rule remains effective when attackers change the injected content, model, agent framework, credential type, file path, archive utility, staging format, script, encoding method, compression method, or transfer utility. Variant resistance decreases when sensitive data is inherited directly, retained only in memory, accessed exclusively through cloud APIs, or used without observable local staging.

DRI

8.4

TCR Assessment

Operational confidence depends on reliable agent-process mapping, sensitive-resource coverage, complete process and file telemetry, correlation support, and approved-workflow exceptions. Full-telemetry confidence improves when endpoint behavior can be correlated with agent, connector, identity, DLP, approval, SaaS, and network evidence.

Operational TCR

8.0

Full-Telemetry TCR

8.9

Limitations

·        Native SIGMA implementations may not support multi-event correlation without SIEM-specific conversion.

·        Some credentials, tokens, secrets, and sensitive data may be accessed through cloud APIs without local file activity.

·        Sensitive values may be inherited through process environment, workload identity, browser sessions, or operating-system credential brokers.

·        Memory-only access may not create file events.

·        Legitimate deployment, backup, development, browser, security, and administrative tools may access sensitive resources and create archives or temporary files.

·        Shared hosts, containers, and service identities may weaken attribution to a specific agent or task.

·        Data may be transformed, compressed, encoded, or fragmented without producing the specific staging events monitored by the rule.

·        Transfer-tool execution does not prove that data was transmitted.

·        The rule cannot independently determine whether trust injection caused the activity or whether sensitive information was successfully disclosed.

Detection Query Pattern

Use this pattern as an implementation guide for SIGMA-compatible environments that support sensitive-resource monitoring, enterprise AI-agent process grouping, file-staging detection, and event correlation.

title: Agent-Associated Sensitive-Resource Access Followed by Staging Activity

correlation:

  type: temporal

  rules:

    - agent_sensitive_resource_access

    - agent_staging_activity

  group-by:

    - Computer

    - User

    - AgentProcessTreeId

  timespan: 15m

rules:

  agent_sensitive_resource_access:

    logsource:

      category: file_access

    detection:

      agent_process:

        Image|endswith:

          - '\approved_agent_runtime.exe'

          - '\approved_connector_service.exe'

          - '\approved_browser_automation.exe'

          - '/approved/agent-runtime'

          - '/approved/connector-service'

      sensitive_resource:

        TargetFilename|contains:

          - '\Credentials'

          - '\Login Data'

          - '\.ssh\'

          - '\.aws\'

          - '\.config\gcloud\'

          - '\.azure\'

          - '\.git-credentials'

          - '\.env'

          - '/.ssh/'

          - '/.aws/'

          - '/.config/gcloud/'

          - '/.azure/'

          - '/.git-credentials'

          - '/.env'

      condition: agent_process and sensitive_resource

  agent_staging_activity:

    logsource:

      category: process_creation

    detection:

      staging_process:

        Image|endswith:

          - '\7z.exe'

          - '\rar.exe'

          - '\tar.exe'

          - '\certutil.exe'

          - '\curl.exe'

          - '\scp.exe'

          - '/tar'

          - '/gzip'

          - '/zip'

          - '/curl'

          - '/scp'

      staging_command:

        CommandLine|contains:

          - 'archive'

          - 'compress'

          - 'base64'

          - 'encode'

          - 'upload'

          - 'http://'

          - 'https://'

      condition: staging_process and staging_command

fields:

  - Computer

  - User

  - Image

  - ParentImage

  - CommandLine

  - TargetFilename

  - ProcessGuid

falsepositives:

  - Approved credential management, deployment, backup, development, browser management, security, and administrative workflows

level: high

YARA

YARA Coverage Disposition

YARA has zero deployable rules for this EXP report.

YARA is not viable as a primary S25 detection system because the report’s detection model is behavioral, agent-action based, identity and permission based, approval and policy based, SaaS and connector activity based, process-execution based, network-correlation based, and SIEM-correlation based rather than dependent on a stable malicious file or reusable malware signature.

YARA may provide limited supporting value only if a confirmed malicious script, loader, encoded payload, browser artifact, agent plugin, connector package, configuration structure, persistence component, archive, memory artifact, or reusable malware family is recovered and independently validated.

Final YARA Outcome

No YARA rules survive

AWS

Detection Viability Assessment

AWS can provide supporting cloud detection coverage for this report when enterprise AI agents, agent-associated applications, service roles, workloads, connectors, Bedrock or other AI services, IAM activity, CloudTrail events, data-access logs, and network telemetry are available and mapped to approved identities, resources, workflows, and destinations.

AWS can identify unauthorized agent-associated privilege or access expansion and sensitive-data access followed by transfer to an external or unapproved destination. It cannot independently determine whether untrusted content altered an agent’s instructions, reasoning, or task plan unless agent, prompt, retrieval, tool-use, or trace telemetry is retained.

Two rules survive validation:

·        Unauthorized agent-associated IAM, role, policy, or persistent access change.

·        Agent-associated sensitive-data access followed by external or unapproved transfer.

Each rule is independently deployable as supporting cloud coverage and does not require another CyberDax rule to fire first.

Rule

Unauthorized Agent-Associated IAM, Role, Policy, or Persistent Access Change

Rule Format

AWS cloud-correlation pattern using CloudTrail management events, IAM activity, application and workload identity mapping, approved-change context, permission and trust-policy changes, credential creation, role assumption, and optional subsequent-use enrichment.

Detection Purpose

Detect an enterprise AI agent, agent-associated application, service role, workload, connector, or automation process creating or modifying AWS identities, roles, policies, trust relationships, access keys, credentials, permissions, resource policies, or persistent access paths outside an approved administrative or deployment workflow.

The rule identifies agent-associated access expansion and persistence in AWS without claiming that AWS directly observed trust injection or determined malicious intent.

Detection Logic

·        Limit detection to known enterprise AI agents, agent-associated applications, service roles, workloads, connectors, and automation identities.

·        Identify creation or modification of IAM users, roles, policies, trust policies, access keys, login profiles, permission boundaries, resource policies, identity-provider relationships, or persistent credentials.

·        Require the change to fall outside an approved onboarding, deployment, integration, credential-rotation, emergency-access, or administrative workflow.

·        Require a material effect such as privilege expansion, broader resource access, new cross-account trust, durable credential creation, weakened permission boundaries, new role-assumption paths, or persistence.

·        Increase confidence when the new role, policy, credential, or trust relationship is subsequently used.

·        Increase confidence when the change follows an access denial, policy failure, approval rejection, or unsuccessful attempt through another role or identity.

·        Exclude approved infrastructure-as-code deployments, service onboarding, credential rotation, break-glass activity, testing, recovery, and administrative changes.

·        Do not alert solely because an agent-associated identity performs a documented IAM or resource-policy change within its authorized scope.

Required Telemetry

·        AWS CloudTrail management events.

·        IAM user, role, policy, trust-policy, access-key, login-profile, permission-boundary, identity-provider, and resource-policy changes.

·        AWS application, service-role, workload, connector, task, session, and automation-identity mapping.

·        Actor ARN, principal ID, session issuer, source identity, role session name, account, region, action, target resource, policy, result, and timestamp.

·        Approved deployment, onboarding, integration, credential-rotation, emergency-access, and administrative change records.

·        Subsequent authentication, role-assumption, or resource-access events where available.

Engineering Implementation Instructions

·        Build and maintain an authoritative inventory of enterprise AI agents, associated applications, service roles, workload identities, connectors, and automation principals.

·        Normalize IAM, STS, Organizations, KMS, S3, Lambda, Bedrock, and other relevant CloudTrail events into common fields for actor, principal, session, action, resource, account, region, policy, result, and timestamp.

·        Classify material changes as privilege expansion, cross-account trust creation, durable credential creation, permission-boundary weakening, broader resource access, new role-assumption paths, or persistence.

·        Require both an unauthorized change and a material access or persistence effect before generating an alert.

·        Treat subsequent use of the new role, credential, policy, or trust relationship as confidence enrichment rather than a mandatory condition.

·        Maintain approved infrastructure-as-code, deployment, onboarding, integration, rotation, emergency-access, recovery, and administrative exceptions.

·        Apply higher priority to administrator-equivalent access, wildcard permissions, cross-account trust, external principals, new access keys, altered trust policies, weakened permission boundaries, and access to high-value data or security services.

·        Account for automated deployment pipelines, service-linked roles, managed-service updates, and delayed CloudTrail delivery.

·        Describe the result as an unauthorized agent-associated IAM, role, policy, or persistent access change, not confirmed trust injection or account compromise.

DRI Assessment

The rule remains effective when attackers change the injected content, model, agent framework, role name, policy name, service, account, region, credential type, permission, resource, or administrative interface. Variant resistance decreases when changes occur through unmonitored accounts, approved deployment identities, inherited access paths, or services with incomplete management-event coverage.

DRI

8.8

TCR Assessment

Operational confidence depends on complete CloudTrail coverage, accurate agent and workload identity mapping, approved-change context, material-change classification, and reliable role or credential attribution. Full-telemetry confidence improves when agent traces, approval events, workload logs, identity context, resource-access events, and subsequent-use evidence are available.

Operational TCR

8.6

Full-Telemetry TCR

9.4

Limitations

·        Some AWS services may provide incomplete or delayed management events.

·        Shared roles and automation identities may weaken attribution to a specific agent or task.

·        Infrastructure-as-code and deployment pipelines may generate high volumes of legitimate access changes.

·        Service-linked roles and managed-service updates may resemble unauthorized identity changes.

·        Existing wildcard permissions or trust relationships may predate monitoring.

·        Resource-based policies may create access paths outside IAM role changes.

·        Subsequent use may occur long after the original modification.

·        The rule cannot determine whether trust injection, malicious user direction, excessive agency, or operator error caused the change.

Detection Query Pattern

Use this pattern as an implementation guide for AWS environments that support CloudTrail normalization, enterprise AI-agent identity mapping, approved-change enrichment, material-access classification, and optional subsequent-use correlation.

LET agent_associated_access_changes =

normalized_aws_cloudtrail_events

WHERE principal_or_session IN ENV_ENTERPRISE_AI_AGENT_AWS_IDENTITIES

AND event_name IN (

"CreateUser",

"CreateRole",

"CreatePolicy",

"CreatePolicyVersion",

"AttachUserPolicy",

"AttachRolePolicy",

"PutUserPolicy",

"PutRolePolicy",

"UpdateAssumeRolePolicy",

"CreateAccessKey",

"CreateLoginProfile",

"PutRolePermissionsBoundary",

"DeleteRolePermissionsBoundary",

"AddClientIDToOpenIDConnectProvider",

"CreateSAMLProvider",

"PutResourcePolicy"

)

LET material_unauthorized_access_changes =

agent_associated_access_changes

WHERE approved_change_match = false

AND (

privilege_expansion = true

OR cross_account_trust_created = true

OR durable_credential_created = true

OR permission_boundary_weakened = true

OR broader_resource_access_granted = true

OR new_role_assumption_path_created = true

OR persistent_access_created = true

)

ALERT WHEN

material_unauthorized_access_changes

OUTPUT

agent_id,

principal_arn,

principal_id,

session_issuer,

source_identity,

role_session_name,

aws_account_id,

aws_region,

event_name,

target_identity,

target_role,

target_policy,

target_resource,

privilege_expansion,

cross_account_trust_created,

durable_credential_created,

permission_boundary_weakened,

broader_resource_access_granted,

new_role_assumption_path_created,

persistent_access_created,

approved_change_match,

subsequent_use_detected,

event_time

Rule

Agent-Associated Sensitive-Data Access Followed by External or Unapproved Transfer

Rule Format

AWS cloud-correlation pattern using CloudTrail data events, S3 and service data-access logs, Bedrock or agent workload context, object and data classification, transfer or sharing events, VPC and application network telemetry, and approved data-flow exceptions.

Detection Purpose

Detect an enterprise AI agent, agent-associated application, service role, workload, connector, or automation process accessing sensitive AWS-hosted data and subsequently transferring, sharing, copying, publishing, or sending that data to an external account, public location, unapproved service, or unapproved network destination.

The rule identifies suspicious sensitive-access-to-transfer behavior in AWS without claiming that AWS directly observed the exact content transferred or proved trust injection.

Detection Logic

·        Limit detection to known enterprise AI agents, agent-associated applications, service roles, workloads, connectors, and automation identities.

·        Identify access to data classified as restricted, confidential, regulated, credential-related, customer, employee, financial, legal, source code, security-sensitive, or privileged administrative.

·        Correlate the sensitive access with a later object copy, public exposure, cross-account transfer, external API call, upload, message, webhook, repository action, or network transfer.

·        Use the strongest available task, session, workload, role session, source identity, request, object, resource, or bounded time relationship.

·        Require the destination account, bucket, service, endpoint, domain, IP address, principal, or data flow to fall outside the approved workflow.

·        Increase confidence when the destination is public, external, cross-account, first-seen, rare, direct-IP, unmanaged, or prohibited.

·        Increase confidence when the sequence follows an access denial, DLP event, policy block, approval rejection, or connector restriction.

·        Exclude approved backup, replication, migration, analytics, reporting, support, legal, security, disaster-recovery, and incident-response workflows.

·        Do not alert solely because an agent-associated identity accessed sensitive data or initiated outbound communication.

Required Telemetry

·        AWS CloudTrail management and data events.

·        S3 object-level events, access logs, object ownership, bucket policy, ACL, public-access, copy, replication, and presigned-access context where available.

·        Sensitive-data classification from Amazon Macie or another authoritative data-classification source.

·        Bedrock, Lambda, ECS, EKS, EC2, Step Functions, API Gateway, EventBridge, application, connector, and workload logs where relevant.

·        VPC Flow Logs, DNS, proxy, firewall, NAT Gateway, load-balancer, or other outbound network telemetry where available.

·        Actor ARN, principal ID, role session, source identity, account, region, resource, object, data classification, destination, recipient, action, result, and timestamp.

·        Approved account, bucket, service, endpoint, destination, and data-flow mappings.

Engineering Implementation Instructions

·        Build and maintain an authoritative inventory of enterprise AI agents, associated applications, service roles, workloads, connectors, and automation identities.

·        Normalize sensitive-data access and transfer events into common fields for principal, session, workload, resource, object, classification, destination, account, service, action, result, and timestamp.

·        Use role session, source identity, task, workload, request, object, or application identifiers when available.

·        When direct identifiers are unavailable, correlate by principal, workload, source resource, account, region, and a locally validated time window.

·        Require a sensitive-data access event plus a material transfer, copy, share, publish, or outbound communication event.

·        Require the destination account, bucket, service, principal, endpoint, or network destination to fall outside the approved data-flow definition.

·        Maintain approved account-to-account, bucket-to-bucket, service-to-service, destination, principal, and workflow mappings.

·        Apply higher priority to credentials, tokens, secrets, regulated information, customer records, financial data, legal data, source code, security findings, and privileged administrative records.

·        Apply higher priority to public buckets, external accounts, unmanaged endpoints, direct-IP destinations, anonymous access, public repositories, and newly observed destinations.

·        Account for replication, backup, analytics, migration, presigned URLs, multipart operations, duplicate events, and delayed CloudTrail delivery.

·        Describe the result as agent-associated sensitive-data access followed by external or unapproved transfer, not confirmed data exfiltration or trust injection.

DRI Assessment

The rule remains effective when attackers change the injected content, model, agent framework, source service, destination service, account, bucket, object, workload, protocol, endpoint, data format, or transfer method. Variant resistance decreases when data classification is unavailable, approved destinations are abused, data is transformed before transfer, or attribution is lost through shared roles and workloads.

DRI

8.9

TCR Assessment

Operational confidence depends on complete CloudTrail and data-event coverage, reliable data classification, accurate agent and workload mapping, approved data-flow definitions, and strong correlation identifiers. Full-telemetry confidence improves when agent traces, DLP, approval, application, connector, workload, and network evidence are available.

Operational TCR

8.6

Full-Telemetry TCR

9.4

Limitations

·        CloudTrail data events may not be enabled for all relevant resources.

·        Data classification may be missing, stale, or incomplete.

·        Shared roles and workloads may weaken attribution to a specific agent or task.

·        Data may be summarized, transformed, encoded, compressed, or fragmented before transfer.

·        Approved accounts, buckets, or services may still be misused.

·        Encrypted network traffic may conceal transferred content.

·        Some transfers may occur entirely within managed services without observable network telemetry.

·        Presigned URLs and delegated access may complicate attribution.

·        The rule cannot prove that transferred content was identical to the sensitive content accessed.

·        The rule cannot independently determine whether trust injection caused the sequence.

Detection Query Pattern

Use this pattern as an implementation guide for AWS environments that support enterprise AI-agent principal mapping, sensitive-data classification, CloudTrail data-event normalization, approved data-flow enrichment, and bounded access-to-transfer correlation.

LET agent_sensitive_data_access =

normalized_aws_data_access_events

WHERE principal_or_session IN ENV_ENTERPRISE_AI_AGENT_AWS_IDENTITIES

AND data_classification IN ENV_HIGH_VALUE_DATA_CLASSIFICATIONS

LET agent_transfer_activity =

normalized_aws_cloudtrail_application_and_network_events

WHERE principal_or_session IN ENV_ENTERPRISE_AI_AGENT_AWS_IDENTITIES

AND action_category IN (

"object_copy",

"cross_account_transfer",

"public_share",

"public_access_enabled",

"external_api_transfer",

"upload",

"message_send",

"webhook",

"repository_publish",

"outbound_network_transfer"

)

ALERT WHEN

JOIN agent_sensitive_data_access

WITH agent_transfer_activity

WHERE (

same_role_session = true

OR same_source_identity = true

OR same_task_id = true

OR same_workload_id = true

OR same_request_context = true

OR same_source_resource_or_object = true

OR same_principal_and_account = true

)

AND event_sequence = "sensitive_access_then_transfer"

AND approved_data_flow_match = false

WITHIN ENV_AWS_AGENT_SENSITIVE_TRANSFER_WINDOW

OUTPUT

agent_id,

principal_arn,

principal_id,

session_issuer,

source_identity,

role_session_name,

aws_account_id,

aws_region,

source_service,

source_resource,

source_object,

data_classification,

transfer_action,

destination_account,

destination_bucket,

destination_service,

destination_principal,

destination_domain,

destination_ip,

approved_data_flow_match,

correlated_policy_block,

correlated_access_denial,

sensitive_access_time,

transfer_time

Azure

Detection Viability Assessment

Azure can provide supporting cloud detection coverage for this report when enterprise AI agents, agent-associated applications, managed identities, service principals, workloads, connectors, Microsoft Entra ID activity, Azure resource logs, SaaS audit events, data-access telemetry, and network records are available and mapped to approved identities, resources, workflows, and destinations.

Azure can identify unauthorized agent-associated identity or privilege expansion, sensitive-data access followed by external or unapproved transfer, and denied activity followed by successful alternate execution. It cannot independently determine whether untrusted content altered an agent’s instructions, reasoning, or task plan unless agent, prompt, retrieval, tool-use, or trace telemetry is retained.

Three rules survive validation:

·        Unauthorized agent-associated identity, application, role, or permission change.

·        Agent-associated sensitive-data access followed by external or unapproved transfer.

·        Denied agent-associated action followed by successful alternate execution.

Each rule is independently deployable as supporting cloud coverage and does not require another CyberDax rule to fire first.

Rule

Unauthorized Agent-Associated Identity, Application, Role, or Permission Change

Rule Format

Azure cloud-correlation pattern using Microsoft Entra ID audit logs, Azure Activity logs, application and managed-identity mapping, approved-change context, role and permission changes, credential creation, consent activity, and optional subsequent-use enrichment.

Detection Purpose

Detect an enterprise AI agent, agent-associated application, managed identity, service principal, workload, connector, or automation process creating or modifying identities, application registrations, credentials, OAuth grants, consent, directory roles, Azure RBAC assignments, permissions, federated credentials, or persistent access paths outside an approved administrative or deployment workflow.

The rule identifies agent-associated access expansion and persistence in Azure without claiming that Azure directly observed trust injection or determined malicious intent.

Detection Logic

·        Limit detection to known enterprise AI agents, agent-associated applications, managed identities, service principals, workloads, connectors, and automation identities.

·        Identify creation or modification of users, service principals, managed identities, application registrations, credentials, federated credentials, OAuth grants, consent records, directory roles, Azure RBAC assignments, custom roles, permissions, or persistent access relationships.

·        Require the change to fall outside an approved onboarding, deployment, integration, credential-rotation, emergency-access, or administrative workflow.

·        Require a material effect such as privilege expansion, broader resource access, durable credential creation, new federated trust, broad OAuth scope, new role-assignment path, cross-tenant access, weakened controls, or persistence.

·        Increase confidence when the new role, credential, permission, application, or trust relationship is subsequently used.

·        Increase confidence when the change follows an access denial, conditional-access failure, policy block, approval rejection, or unsuccessful attempt through another identity or application.

·        Exclude approved infrastructure-as-code deployments, service onboarding, credential rotation, break-glass activity, testing, recovery, and administrative changes.

·        Do not alert solely because an agent-associated identity performs a documented identity, application, or role change within its authorized scope.

Required Telemetry

·        Microsoft Entra ID audit logs.

·        Azure Activity logs.

·        Application registration, service-principal, managed-identity, credential, federated-credential, OAuth consent, directory-role, Azure RBAC, custom-role, and permission changes.

·        Azure application, workload, connector, task, session, managed-identity, and service-principal mapping.

·        Actor identity, application ID, service-principal ID, managed identity, tenant, subscription, resource, action, permission, scope, result, and timestamp.

·        Approved deployment, onboarding, integration, credential-rotation, emergency-access, and administrative change records.

·        Subsequent authentication, token use, role use, or resource-access events where available.

Engineering Implementation Instructions

·        Build and maintain an authoritative inventory of enterprise AI agents, associated applications, managed identities, service principals, workloads, connectors, and automation principals.

·        Normalize Microsoft Entra ID audit logs and Azure Activity logs into common fields for actor, application, identity, tenant, subscription, resource, action, permission, scope, result, and timestamp.

·        Classify material changes as privilege expansion, durable credential creation, new federated trust, broad OAuth scope, new role-assignment path, cross-tenant access, broader resource access, weakened controls, or persistence.

·        Require both an unauthorized change and a material access or persistence effect before generating an alert.

·        Treat subsequent use of the new identity, role, credential, application, or permission as confidence enrichment rather than a mandatory condition.

·        Maintain approved infrastructure-as-code, deployment, onboarding, integration, rotation, emergency-access, recovery, and administrative exceptions.

·        Apply higher priority to Global Administrator or equivalent roles, privileged Azure RBAC assignments, broad application permissions, external consent, durable credentials, federated credentials, cross-tenant access, and changes affecting security or monitoring controls.

·        Account for automated deployment pipelines, managed-service operations, identity-governance workflows, and delayed audit delivery.

·        Describe the result as an unauthorized agent-associated identity, application, role, or permission change, not confirmed trust injection or account compromise.

DRI Assessment

The rule remains effective when attackers change the injected content, model, agent framework, identity type, application, managed identity, role name, permission, scope, tenant, subscription, resource, or administrative interface. Variant resistance decreases when changes occur through unmonitored tenants, approved deployment identities, inherited access paths, or services with incomplete audit coverage.

DRI

8.9

TCR Assessment

Operational confidence depends on complete Entra ID and Azure Activity logging, accurate agent and workload identity mapping, approved-change context, material-change classification, and reliable role or credential attribution. Full-telemetry confidence improves when agent traces, approval events, workload logs, identity context, resource-access events, and subsequent-use evidence are available.

Operational TCR

8.7

Full-Telemetry TCR

9.5

Limitations

·        Some Azure and Microsoft services may provide incomplete or delayed administrative events.

·        Shared applications, service principals, and managed identities may weaken attribution to a specific agent or task.

·        Infrastructure-as-code and deployment pipelines may generate high volumes of legitimate access changes.

·        Existing broad permissions or role assignments may predate monitoring.

·        Inherited roles and nested groups may obscure the effective privilege change.

·        Cross-tenant and delegated-access relationships may complicate ownership and approval context.

·        Subsequent use may occur long after the original modification.

·        The rule cannot determine whether trust injection, malicious user direction, excessive agency, or operator error caused the change.

Detection Query Pattern

Use this pattern as an implementation guide for Azure environments that support Microsoft Entra ID and Azure Activity normalization, enterprise AI-agent identity mapping, approved-change enrichment, material-access classification, and optional subsequent-use correlation.

LET agent_associated_identity_changes =

normalized_entra_and_azure_activity_events

WHERE actor_or_application IN ENV_ENTERPRISE_AI_AGENT_AZURE_IDENTITIES

AND action_category IN (

"identity_created",

"service_principal_created",

"managed_identity_created",

"application_registered",

"credential_added",

"federated_credential_added",

"oauth_grant_added",

"application_consent_added",

"directory_role_assigned",

"azure_role_assigned",

"custom_role_changed",

"permission_added",

"cross_tenant_access_changed"

)

LET material_unauthorized_identity_changes =

agent_associated_identity_changes

WHERE approved_change_match = false

AND (

privilege_expansion = true

OR durable_credential_created = true

OR federated_trust_created = true

OR broad_oauth_scope_granted = true

OR new_role_assignment_path_created = true

OR cross_tenant_access_enabled = true

OR broader_resource_access_granted = true

OR security_control_weakened = true

OR persistent_access_created = true

)

ALERT WHEN

material_unauthorized_identity_changes

OUTPUT

agent_id,

actor_identity,

application_id,

service_principal_id,

managed_identity_id,

tenant_id,

subscription_id,

action_category,

target_identity,

target_application,

target_role,

permission_or_scope,

target_resource,

privilege_expansion,

durable_credential_created,

federated_trust_created,

broad_oauth_scope_granted,

new_role_assignment_path_created,

cross_tenant_access_enabled,

broader_resource_access_granted,

security_control_weakened,

persistent_access_created,

approved_change_match,

subsequent_use_detected,

event_time

Rule

Agent-Associated Sensitive-Data Access Followed by External or Unapproved Transfer

Rule Format

Azure cloud-correlation pattern using Azure resource and data-access logs, Microsoft 365 and SaaS audit events, Microsoft Purview or another authoritative data-classification source, workload and identity mapping, transfer or sharing activity, network telemetry, and approved data-flow exceptions.

Detection Purpose

Detect an enterprise AI agent, agent-associated application, managed identity, service principal, workload, connector, or automation process accessing sensitive Azure-hosted or Microsoft cloud data and subsequently transferring, sharing, copying, publishing, or sending that data to an external tenant, public location, unapproved application, or unapproved network destination.

The rule identifies suspicious sensitive-access-to-transfer behavior without claiming that Azure directly observed the exact content transferred or proved trust injection.

Detection Logic

·        Limit detection to known enterprise AI agents, agent-associated applications, managed identities, service principals, workloads, connectors, and automation identities.

·        Identify access to data classified as restricted, confidential, regulated, credential-related, customer, employee, financial, legal, source code, security-sensitive, or privileged administrative.

·        Correlate the sensitive access with a later external share, public link, cross-tenant transfer, object copy, upload, message, email, webhook, repository action, API transfer, or outbound network transfer.

·        Use the strongest available task, session, workload, token, application, identity, request, object, resource, or bounded time relationship.

·        Require the destination tenant, account, storage location, application, recipient, endpoint, domain, IP address, or data flow to fall outside the approved workflow.

·        Increase confidence when the destination is public, external, cross-tenant, personal, unmanaged, first-seen, rare, direct-IP, or prohibited.

·        Increase confidence when the sequence follows a DLP event, access denial, conditional-access failure, policy block, approval rejection, or connector restriction.

·        Exclude approved backup, replication, migration, analytics, reporting, support, legal, security, disaster-recovery, and incident-response workflows.

·        Do not alert solely because an agent-associated identity accessed sensitive data or initiated outbound communication.

Required Telemetry

·        Microsoft Entra ID sign-in and audit logs.

·        Azure Activity logs and relevant resource logs.

·        Azure Storage, Key Vault, SQL, Cosmos DB, Data Lake, Microsoft 365, SharePoint, OneDrive, Exchange, Teams, source-control, and other relevant data-access events.

·        Microsoft Purview, DLP, sensitivity-label, CASB, or another authoritative data-classification source.

·        Azure OpenAI, Azure AI Foundry, Functions, Logic Apps, App Service, AKS, VMs, automation, application, connector, and workload logs where relevant.

·        NSG Flow Logs, Azure Firewall, DNS, proxy, API Management, Application Gateway, or other outbound network telemetry where available.

·        Actor, application, identity, tenant, subscription, resource, object, data classification, destination, recipient, action, result, and timestamp.

·        Approved tenant, application, recipient, storage, endpoint, and data-flow mappings.

Engineering Implementation Instructions

·        Build and maintain an authoritative inventory of enterprise AI agents, associated applications, managed identities, service principals, workloads, connectors, and automation identities.

·        Normalize sensitive-data access and transfer events into common fields for identity, application, session, workload, resource, object, classification, destination, tenant, recipient, action, result, and timestamp.

·        Use task, session, token, workload, request, application, identity, object, or resource identifiers when available.

·        When direct identifiers are unavailable, correlate by identity, application, workload, source resource, tenant, subscription, and a locally validated time window.

·        Require a sensitive-data access event plus a material transfer, copy, share, publish, message, or outbound communication event.

·        Require the destination tenant, application, recipient, resource, endpoint, or network destination to fall outside the approved data-flow definition.

·        Maintain approved tenant-to-tenant, application-to-application, resource-to-resource, recipient, endpoint, and workflow mappings.

·        Apply higher priority to credentials, tokens, secrets, regulated information, customer records, financial data, legal data, source code, security findings, and privileged administrative records.

·        Apply higher priority to public links, external tenants, personal accounts, unmanaged applications, public repositories, anonymous access, newly observed destinations, and direct-IP transfers.

·        Account for replication, backup, analytics, migration, delegated access, shared links, multipart operations, duplicate events, and delayed audit delivery.

·        Describe the result as agent-associated sensitive-data access followed by external or unapproved transfer, not confirmed data exfiltration or trust injection.

DRI Assessment

The rule remains effective when attackers change the injected content, model, agent framework, source service, destination service, tenant, resource, object, workload, protocol, endpoint, data format, or transfer method. Variant resistance decreases when data classification is unavailable, approved destinations are abused, data is transformed before transfer, or attribution is lost through shared applications and identities.

DRI

9.0

TCR Assessment

Operational confidence depends on complete data-access and transfer telemetry, reliable data classification, accurate agent and workload mapping, approved data-flow definitions, and strong correlation identifiers. Full-telemetry confidence improves when agent traces, DLP, approval, application, connector, workload, identity, and network evidence are available.

Operational TCR

8.7

Full-Telemetry TCR

9.5

Limitations

·        Relevant data-access logs may not be enabled for every resource or Microsoft service.

·        Data classification may be missing, stale, or incomplete.

·        Shared applications, managed identities, and service principals may weaken attribution to a specific agent or task.

·        Data may be summarized, transformed, encoded, compressed, or fragmented before transfer.

·        Approved tenants, applications, recipients, or services may still be misused.

·        Encrypted network traffic may conceal transferred content.

·        Some transfers may occur entirely within managed services without observable network telemetry.

·        Delegated access and shared links may complicate attribution.

·        The rule cannot prove that transferred content was identical to the sensitive content accessed.

·        The rule cannot independently determine whether trust injection caused the sequence.

Detection Query Pattern

Use this pattern as an implementation guide for Azure environments that support enterprise AI-agent identity mapping, sensitive-data classification, Azure and Microsoft cloud event normalization, approved data-flow enrichment, and bounded access-to-transfer correlation.

LET agent_sensitive_data_access =

normalized_azure_and_microsoft_data_access_events

WHERE actor_or_application IN ENV_ENTERPRISE_AI_AGENT_AZURE_IDENTITIES

AND data_classification IN ENV_HIGH_VALUE_DATA_CLASSIFICATIONS

LET agent_transfer_activity =

normalized_azure_microsoft_saas_and_network_events

WHERE actor_or_application IN ENV_ENTERPRISE_AI_AGENT_AZURE_IDENTITIES

AND action_category IN (

"external_share",

"public_link_created",

"cross_tenant_transfer",

"object_copy",

"upload",

"message_send",

"email_send",

"webhook",

"api_transfer",

"repository_publish",

"outbound_network_transfer"

)

ALERT WHEN

JOIN agent_sensitive_data_access

WITH agent_transfer_activity

WHERE (

same_task_id = true

OR same_agent_session_id = true

OR same_token_context = true

OR same_workload_id = true

OR same_request_context = true

OR same_application_identity = true

OR same_source_resource_or_object = true

)

AND event_sequence = "sensitive_access_then_transfer"

AND approved_data_flow_match = false

WITHIN ENV_AZURE_AGENT_SENSITIVE_TRANSFER_WINDOW

OUTPUT

agent_id,

actor_identity,

application_id,

service_principal_id,

managed_identity_id,

tenant_id,

subscription_id,

source_service,

source_resource,

source_object,

data_classification,

transfer_action,

destination_tenant,

destination_application,

destination_resource,

destination_recipient,

destination_domain,

destination_ip,

approved_data_flow_match,

correlated_dlp_event,

correlated_policy_block,

correlated_access_denial,

sensitive_access_time,

transfer_time

Rule

Denied Agent-Associated Action Followed by Successful Alternate Execution

Rule Format

Azure cloud-correlation pattern using Microsoft Entra ID, Azure Activity, resource, SaaS, approval, policy, and connector-denial events, subsequent action events, resource and objective matching, alternate identity or execution-path detection, approved fallback exceptions, and resulting-action evidence.

Detection Purpose

Detect an enterprise AI agent, agent-associated application, managed identity, service principal, workload, connector, or automation process receiving an access denial, conditional-access failure, policy block, approval rejection, connector restriction, or authorization failure and subsequently completing the same or a materially equivalent objective through another application, identity, connector, tenant, API, workflow, or execution path.

The rule identifies successful alternate execution and policy circumvention without treating every retry, failover, or service fallback as malicious.

Detection Logic

·        Limit detection to known enterprise AI agents, agent-associated applications, managed identities, service principals, workloads, connectors, and automation identities.

·        Identify denied, blocked, rejected, unauthorized, conditionally denied, or policy-failed actions involving access, sharing, deletion, permission changes, external communication, administration, deployment, financial activity, source control, or security-control modification.

·        Identify a later action associated with the same task, workflow, session, application, identity, resource, destination, recipient, or business objective.

·        Require the later action to pursue the same or a materially equivalent outcome.

·        Require a change in application, identity, service principal, managed identity, connector, tenant, API, workflow, or execution path.

·        Require the later action to succeed or produce a consequential partial state change.

·        Exclude documented retry, resilience, failover, connector fallback, queue-recovery, testing, deployment, and administrative behavior.

·        Do not alert on repeated failures that produce no meaningful state change.

Required Telemetry

·        Microsoft Entra ID sign-in and audit logs.

·        Azure Activity logs.

·        Conditional Access, policy, authorization, approval, connector, and application-denial events.

·        Subsequent Azure, Microsoft 365, SaaS, identity, API, workflow, source-control, financial, and administrative events.

·        Agent, task, workflow, session, application, identity, resource, object, recipient, destination, tenant, action, result, and resulting-state context.

·        Approved retry, failover, connector fallback, queue-recovery, deployment, testing, and operational-window mappings.

Engineering Implementation Instructions

·        Normalize denial and subsequent-action events into common fields for agent, task, workflow, application, identity, connector, action, resource, object, recipient, destination, tenant, result, and timestamp.

·        Use exact task, workflow, trace, session, token, request, or correlation identifiers when available.

·        When direct identifiers are unavailable, correlate by agent identity, application identity, resource, recipient, destination, action objective, and a locally validated time window.

·        Define equivalent objectives using the target resource, recipient, destination, permission, action category, or resulting state.

·        Require successful alternate execution or a consequential partial state change before generating an alert.

·        Maintain approved retry, resilience, failover, connector fallback, queue-recovery, deployment, and administrative exceptions.

·        Apply higher priority to external sharing, privileged identity changes, deletion, financial activity, deployment, source-code modification, security-control changes, and sensitive-data transfer.

·        Account for duplicate events, delayed status changes, token refresh, service retries, asynchronous completion, and regional failover.

·        Describe the result as denied agent-associated activity followed by successful alternate execution, not confirmed trust injection or malicious intent.

DRI Assessment

The rule remains effective when attackers change the injected content, model, agent framework, application, identity, managed identity, service principal, connector, tenant, action name, execution order, or fallback method. Variant resistance decreases when denial and success events cannot be linked, equivalent objectives cannot be derived, or legitimate fallback behavior is not documented.

DRI

8.8

TCR Assessment

Operational confidence depends on complete denial telemetry, reliable agent and workflow attribution, accurate objective matching, successful-action evidence, and approved fallback mappings. Full-telemetry confidence improves when approval, policy, agent-trace, application, endpoint, SaaS, identity, and network evidence are available.

Operational TCR

8.6

Full-Telemetry TCR

9.4

Limitations

·        Legitimate applications may retry through another application, identity, region, connector, tenant, or service.

·        Asynchronous actions may complete after an apparent denial.

·        Conditional Access or policy systems may deny one token or session while another authorized session remains valid.

·        Duplicate or delayed events may distort sequence order.

·        Shared applications and managed identities may weaken attribution to a specific agent or task.

·        Equivalent outcomes may use different event names, resources, or identifiers.

·        Resulting-state evidence may be delayed or unavailable.

·        The rule cannot determine whether alternate execution resulted from trust injection, legitimate resilience, user instruction, or workflow error.

Detection Query Pattern

Use this pattern as an implementation guide for Azure environments that support enterprise AI-agent identity grouping, denial-event normalization, objective matching, alternate-path detection, resulting-action analysis, approved fallback exceptions, and bounded sequence correlation.

LET denied_agent_activity =

normalized_entra_azure_policy_connector_and_approval_events

WHERE actor_or_application IN ENV_ENTERPRISE_AI_AGENT_AZURE_IDENTITIES

AND action_result IN (

"denied",

"blocked",

"rejected",

"unauthorized",

"conditional_access_denied",

"failed_by_policy"

)

LET subsequent_agent_activity =

normalized_azure_microsoft_saas_identity_api_and_workflow_events

WHERE actor_or_application IN ENV_ENTERPRISE_AI_AGENT_AZURE_IDENTITIES

ALERT WHEN

JOIN denied_agent_activity

WITH subsequent_agent_activity

WHERE (

same_task_id = true

OR same_workflow_id = true

OR same_agent_session_id = true

OR same_token_or_request_context = true

OR (

same_actor_or_application = true

AND same_target_context = true

)

)

AND same_or_equivalent_action_objective = true

AND (

application_changed = true

OR identity_changed = true

OR service_principal_changed = true

OR managed_identity_changed = true

OR connector_changed = true

OR tenant_changed = true

OR api_or_workflow_path_changed = true

)

AND (

subsequent_action_result = "success"

OR consequential_partial_state_change = true

)

AND approved_fallback_match = false

WITHIN ENV_AZURE_AGENT_ALTERNATE_EXECUTION_WINDOW

OUTPUT

agent_id,

actor_identity,

application_id,

service_principal_id,

managed_identity_id,

tenant_id,

subscription_id,

task_id,

workflow_id,

agent_session_id,

denied_action,

denial_reason,

denied_application,

denied_identity,

denied_resource,

denied_destination,

subsequent_action,

subsequent_application,

subsequent_identity,

subsequent_resource,

subsequent_destination,

same_or_equivalent_action_objective,

subsequent_action_result,

consequential_partial_state_change,

denial_time,

subsequent_action_time

GCP

Detection Viability Assessment

GCP can provide supporting cloud detection coverage for this report when enterprise AI agents, agent-associated applications, service accounts, workloads, connectors, Vertex AI or other AI services, Cloud Audit Logs, data-access events, IAM activity, and network telemetry are available and mapped to approved identities, resources, workflows, and destinations.

GCP can identify unauthorized agent-associated IAM or persistent-access changes and sensitive-data access followed by external or unapproved transfer. It cannot independently determine whether untrusted content altered an agent’s instructions, reasoning, or task plan unless agent, prompt, retrieval, tool-use, or trace telemetry is retained.

Two rules survive validation:

·        Unauthorized agent-associated IAM, service-account, role, or persistent-access change.

·        Agent-associated sensitive-data access followed by external or unapproved transfer.

Each rule is independently deployable as supporting cloud coverage and does not require another CyberDax rule to fire first.

Rule

Unauthorized Agent-Associated IAM, Service-Account, Role, or Persistent-Access Change

Rule Format

GCP cloud-correlation pattern using Cloud Audit Logs, IAM and service-account activity, workload and application identity mapping, approved-change context, role and policy changes, credential creation, federation changes, and optional subsequent-use enrichment.

Detection Purpose

Detect an enterprise AI agent, agent-associated application, service account, workload identity, connector, or automation process creating or modifying identities, service accounts, IAM policies, roles, service-account keys, workload-identity relationships, organization policies, or persistent access paths outside an approved administrative or deployment workflow.

The rule identifies agent-associated access expansion and persistence in GCP without claiming that GCP directly observed trust injection or determined malicious intent.

Detection Logic

·        Limit detection to known enterprise AI agents, agent-associated applications, service accounts, workload identities, connectors, and automation principals.

·        Identify creation or modification of service accounts, service-account keys, IAM policies, role bindings, custom roles, workload-identity relationships, external federation, organization policies, or persistent credentials.

·        Require the change to fall outside an approved onboarding, deployment, integration, credential-rotation, emergency-access, or administrative workflow.

·        Require a material effect such as privilege expansion, broader project or resource access, durable credential creation, new external federation, service-account impersonation capability, weakened organization controls, or persistence.

·        Increase confidence when the new role, key, policy, federation relationship, or impersonation path is subsequently used.

·        Increase confidence when the change follows an access denial, policy failure, approval rejection, or unsuccessful attempt through another identity or service account.

·        Exclude approved infrastructure-as-code deployments, service onboarding, credential rotation, break-glass activity, testing, recovery, and administrative changes.

·        Do not alert solely because an agent-associated identity performs a documented IAM or service-account change within its authorized scope.

Required Telemetry

·        GCP Admin Activity and relevant Data Access audit logs.

·        IAM policy, service-account, service-account-key, custom-role, workload-identity, federation, organization-policy, and impersonation changes.

·        Enterprise AI-agent application, service-account, workload, connector, task, session, and automation-principal mapping.

·        Principal email, service-account name, workload identity, project, folder, organization, resource, action, role, permission, result, and timestamp.

·        Approved deployment, onboarding, integration, credential-rotation, emergency-access, and administrative change records.

·        Subsequent authentication, impersonation, token use, or resource-access events where available.

Engineering Implementation Instructions

·        Build and maintain an authoritative inventory of enterprise AI agents, associated applications, service accounts, workload identities, connectors, and automation principals.

·        Normalize IAM, service-account, organization-policy, federation, and workload-identity events into common fields for principal, identity, project, resource, action, role, permission, result, and timestamp.

·        Classify material changes as privilege expansion, durable credential creation, external federation, service-account impersonation capability, broader project or resource access, weakened organization controls, or persistence.

·        Require both an unauthorized change and a material access or persistence effect before generating an alert.

·        Treat subsequent use of the new role, key, policy, federation relationship, or impersonation path as confidence enrichment rather than a mandatory condition.

·        Maintain approved infrastructure-as-code, deployment, onboarding, integration, credential-rotation, emergency-access, recovery, and administrative exceptions.

·        Apply higher priority to owner or administrator-equivalent access, broad custom roles, service-account keys, external federation, service-account impersonation, cross-project access, and changes affecting logging, security, or organization controls.

·        Account for deployment pipelines, service agents, managed-service changes, and delayed audit-log delivery.

·        Describe the result as an unauthorized agent-associated IAM, service-account, role, or persistent-access change, not confirmed trust injection or account compromise.

DRI Assessment

The rule remains effective when attackers change the injected content, model, agent framework, service account, role name, project, resource, credential type, permission, federation method, or administrative interface. Variant resistance decreases when changes occur through unmonitored projects, approved deployment identities, inherited access paths, or services with incomplete audit coverage.

DRI

8.8

TCR Assessment

Operational confidence depends on complete audit logging, accurate agent and workload identity mapping, approved-change context, material-change classification, and reliable principal attribution. Full-telemetry confidence improves when agent traces, approval events, workload logs, identity context, resource-access events, and subsequent-use evidence are available.

Operational TCR

8.6

Full-Telemetry TCR

9.4

Limitations

·        Some GCP services may provide incomplete or delayed administrative events.

·        Shared service accounts and workload identities may weaken attribution to a specific agent or task.

·        Infrastructure-as-code and deployment pipelines may generate high volumes of legitimate access changes.

·        Existing broad roles or IAM bindings may predate monitoring.

·        Inherited IAM policies may obscure the effective privilege change.

·        Google-managed service agents may create or modify access relationships during normal service operation.

·        Subsequent use may occur long after the original modification.

·        The rule cannot determine whether trust injection, malicious user direction, excessive agency, or operator error caused the change.

Detection Query Pattern

Use this pattern as an implementation guide for GCP environments that support Cloud Audit Logs normalization, enterprise AI-agent identity mapping, approved-change enrichment, material-access classification, and optional subsequent-use correlation.

LET agent_associated_access_changes =

normalized_gcp_audit_events

WHERE principal_or_identity IN ENV_ENTERPRISE_AI_AGENT_GCP_IDENTITIES

AND action_category IN (

"service_account_created",

"service_account_key_created",

"iam_policy_changed",

"role_binding_added",

"custom_role_created",

"custom_role_changed",

"workload_identity_binding_added",

"external_federation_added",

"organization_policy_changed",

"service_account_impersonation_granted"

)

LET material_unauthorized_access_changes =

agent_associated_access_changes

WHERE approved_change_match = false

AND (

privilege_expansion = true

OR durable_credential_created = true

OR external_federation_created = true

OR service_account_impersonation_enabled = true

OR broader_project_or_resource_access_granted = true

OR organization_control_weakened = true

OR persistent_access_created = true

)

ALERT WHEN

material_unauthorized_access_changes

OUTPUT

agent_id,

principal_email,

service_account_name,

workload_identity,

project_id,

folder_id,

organization_id,

action_category,

target_identity,

target_role,

target_policy,

target_resource,

privilege_expansion,

durable_credential_created,

external_federation_created,

service_account_impersonation_enabled,

broader_project_or_resource_access_granted,

organization_control_weakened,

persistent_access_created,

approved_change_match,

subsequent_use_detected,

event_time

Rule

Agent-Associated Sensitive-Data Access Followed by External or Unapproved Transfer

Rule Format

GCP cloud-correlation pattern using Data Access audit logs, Cloud Storage and service data-access events, Sensitive Data Protection or another authoritative classification source, workload and identity mapping, transfer or sharing activity, network telemetry, and approved data-flow exceptions.

Detection Purpose

Detect an enterprise AI agent, agent-associated application, service account, workload identity, connector, or automation process accessing sensitive GCP-hosted data and subsequently transferring, sharing, copying, publishing, or sending that data to an external project, public location, unapproved service, or unapproved network destination.

The rule identifies suspicious sensitive-access-to-transfer behavior in GCP without claiming that GCP directly observed the exact content transferred or proved trust injection.

Detection Logic

·        Limit detection to known enterprise AI agents, agent-associated applications, service accounts, workload identities, connectors, and automation principals.

·        Identify access to data classified as restricted, confidential, regulated, credential-related, customer, employee, financial, legal, source code, security-sensitive, or privileged administrative.

·        Correlate the sensitive access with a later object copy, public exposure, cross-project transfer, external API call, upload, message, webhook, repository action, or outbound network transfer.

·        Use the strongest available task, session, workload, principal, request, object, resource, trace, or bounded time relationship.

·        Require the destination project, bucket, service, endpoint, domain, IP address, principal, or data flow to fall outside the approved workflow.

·        Increase confidence when the destination is public, external, cross-project, first-seen, rare, direct-IP, unmanaged, or prohibited.

·        Increase confidence when the sequence follows an access denial, policy block, DLP event, approval rejection, or connector restriction.

·        Exclude approved backup, replication, migration, analytics, reporting, support, legal, security, disaster-recovery, and incident-response workflows.

·        Do not alert solely because an agent-associated identity accessed sensitive data or initiated outbound communication.

Required Telemetry

·        GCP Data Access and Admin Activity audit logs.

·        Cloud Storage object access, copy, ACL, IAM, public-access, and transfer events.

·        BigQuery, Secret Manager, Cloud SQL, Firestore, Spanner, Artifact Registry, source-control, and other relevant data-access logs.

·        Sensitive Data Protection, classification labels, DLP findings, or another authoritative data-classification source.

·        Vertex AI, Cloud Run, Cloud Functions, GKE, Compute Engine, Workflows, application, connector, and workload logs where relevant.

·        VPC Flow Logs, Cloud DNS, Secure Web Proxy, firewall, load-balancer, NAT, or other outbound network telemetry where available.

·        Principal, service account, workload identity, project, resource, object, data classification, destination, action, result, and timestamp.

·        Approved project, bucket, service, endpoint, destination, principal, and data-flow mappings.

Engineering Implementation Instructions

·        Build and maintain an authoritative inventory of enterprise AI agents, associated applications, service accounts, workload identities, connectors, and automation principals.

·        Normalize sensitive-data access and transfer events into common fields for principal, workload, resource, object, classification, destination, project, service, action, result, and timestamp.

·        Use task, session, workload, principal, trace, request, object, or resource identifiers when available.

·        When direct identifiers are unavailable, correlate by principal, workload, source resource, project, and a locally validated time window.

·        Require a sensitive-data access event plus a material transfer, copy, share, publish, or outbound communication event.

·        Require the destination project, bucket, service, principal, endpoint, or network destination to fall outside the approved data-flow definition.

·        Maintain approved project-to-project, bucket-to-bucket, service-to-service, destination, principal, and workflow mappings.

·        Apply higher priority to credentials, tokens, secrets, regulated information, customer records, financial data, legal data, source code, security findings, and privileged administrative records.

·        Apply higher priority to public buckets, external projects, unmanaged endpoints, direct-IP destinations, anonymous access, public repositories, and newly observed destinations.

·        Account for replication, backup, analytics, migration, Storage Transfer Service, signed URLs, multipart operations, duplicate events, and delayed audit-log delivery.

·        Describe the result as agent-associated sensitive-data access followed by external or unapproved transfer, not confirmed data exfiltration or trust injection.

DRI Assessment

The rule remains effective when attackers change the injected content, model, agent framework, source service, destination service, project, bucket, object, workload, protocol, endpoint, data format, or transfer method. Variant resistance decreases when data classification is unavailable, approved destinations are abused, data is transformed before transfer, or attribution is lost through shared service accounts and workloads.

DRI

8.9

TCR Assessment

Operational confidence depends on complete audit and data-access logging, reliable data classification, accurate agent and workload mapping, approved data-flow definitions, and strong correlation identifiers. Full-telemetry confidence improves when agent traces, DLP, approval, application, connector, workload, identity, and network evidence are available.

Operational TCR

8.6

Full-Telemetry TCR

9.4

Limitations

·        Data Access audit logs may not be enabled for every relevant service or resource.

·        Data classification may be missing, stale, or incomplete.

·        Shared service accounts and workload identities may weaken attribution to a specific agent or task.

·        Data may be summarized, transformed, encoded, compressed, or fragmented before transfer.

·        Approved projects, buckets, principals, or services may still be misused.

·        Encrypted network traffic may conceal transferred content.

·        Some transfers may occur entirely within managed services without observable network telemetry.

·        Signed URLs and delegated access may complicate attribution.

·        The rule cannot prove that transferred content was identical to the sensitive content accessed.

·        The rule cannot independently determine whether trust injection caused the sequence.

Detection Query Pattern

Use this pattern as an implementation guide for GCP environments that support enterprise AI-agent principal mapping, sensitive-data classification, GCP audit-event normalization, approved data-flow enrichment, and bounded access-to-transfer correlation.

LET agent_sensitive_data_access =

normalized_gcp_data_access_events

WHERE principal_or_identity IN ENV_ENTERPRISE_AI_AGENT_GCP_IDENTITIES

AND data_classification IN ENV_HIGH_VALUE_DATA_CLASSIFICATIONS

LET agent_transfer_activity =

normalized_gcp_audit_application_and_network_events

WHERE principal_or_identity IN ENV_ENTERPRISE_AI_AGENT_GCP_IDENTITIES

AND action_category IN (

"object_copy",

"cross_project_transfer",

"public_share",

"public_access_enabled",

"external_api_transfer",

"upload",

"message_send",

"webhook",

"repository_publish",

"outbound_network_transfer"

)

ALERT WHEN

JOIN agent_sensitive_data_access

WITH agent_transfer_activity

WHERE (

same_principal = true

OR same_workload_identity = true

OR same_task_id = true

OR same_session_id = true

OR same_trace_id = true

OR same_request_context = true

OR same_source_resource_or_object = true

)

AND event_sequence = "sensitive_access_then_transfer"

AND approved_data_flow_match = false

WITHIN ENV_GCP_AGENT_SENSITIVE_TRANSFER_WINDOW

OUTPUT

agent_id,

principal_email,

service_account_name,

workload_identity,

project_id,

source_service,

source_resource,

source_object,

data_classification,

transfer_action,

destination_project,

destination_bucket,

destination_service,

destination_principal,

destination_domain,

destination_ip,

approved_data_flow_match,

correlated_policy_block,

correlated_access_denial,

correlated_dlp_event,

sensitive_access_time,

transfer_time

S26 — Threat-to-Rule Traceability Matrix

Traceability Purpose

This section maps the primary behavioral threat conditions in this report to the S25 detection coverage developed across NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA, YARA, AWS, Azure, and GCP.

The traceability model is behavior-led. It does not rely on one model, AI provider, agent framework, orchestration platform, prompt phrase, injection string, language, encoding, content type, document format, tool name, connector, application, SaaS platform, cloud provider, API endpoint, recipient, destination, identity, process name, file path, campaign, actor, or static indicator as the basis for coverage.

Coverage Scope

The S25 rule set provides coverage for observable behavior associated with abnormal network activity from enterprise AI-agent workloads, unexpected command or automation execution, credential or sensitive-resource access followed by staging or transfer activity, unauthorized high-impact agent actions, sensitive-data access followed by external or unapproved transfer, denied activity followed by successful alternate execution, unauthorized administrative or persistent agent changes, abnormal connected-SaaS activity, agent-associated identity and permission expansion, and cloud-hosted sensitive-data transfer.

Coverage is strongest where agent, task, session, trace, retrieval, tool-call, connector, approval, identity, OAuth, SaaS audit, data-access, endpoint, process, file, network, cloud, DLP, policy, asset-inventory, approved-workflow, approved-destination, approved-data-flow, deployment, change-control, and incident-response telemetry can be joined into bounded behavioral sequences.

Primary Coverage Areas

·        Abnormal outbound or internal communication from an enterprise AI-agent workload

·        Unexpected command, script, browser-automation, code-execution, deployment, or administrative activity originating from an agent-associated process

·        Credential, token, secret, browser-session, environment, source-control, cloud-configuration, or other sensitive-resource access followed by staging activity

·        Unauthorized send, share, delete, modify, deploy, financial, identity, administrative, or security-control actions performed by an enterprise AI agent

·        Sensitive-data access followed by transfer, sharing, publication, messaging, upload, API activity, or communication to an external or unapproved destination

·        Denied or blocked agent activity followed by successful execution through another tool, connector, application, identity, tenant, API, workflow, browser, or execution path

·        Unauthorized changes to persistent instructions, behavior-changing memory, workflows, automations, connectors, policies, approval controls, security controls, or administrative configuration

·        Unauthorized creation or modification of identities, roles, permissions, credentials, trust relationships, OAuth grants, application consent, service accounts, or persistent access paths

·        Cross-connector and cross-platform movement of sensitive information

·        Agent-associated access to unusual SaaS resources, tenants, repositories, mailboxes, drives, applications, cloud resources, or administrative systems

·        Process-visible collection, transformation, encoding, compression, archiving, or staging of sensitive information

·        Persistent or recurring unauthorized activity across later sessions, tasks, users, agents, identities, workloads, or connected platforms

Traceability Mapping

Abnormal Network Activity From an Enterprise AI-Agent Workload

This behavior is covered where a mapped enterprise AI-agent runtime, orchestration service, connector host, browser-automation environment, code-execution environment, container, pod, workload, or supporting server communicates with an unapproved external destination or unexpected internal service and the activity is new, rare, suspicious, direct-IP, role-inconsistent, periodic, interactive, long-lived, tunneling-like, payload-retrieval-like, destination-rotating, or inconsistent with the workload’s dependency map.

Mapped Coverage

·        NDR / Network Behavioral Analytics provides primary network-behavior coverage through agent-workload mapping, destination rarity, destination reputation, connection behavior, approved-service exceptions, and internal dependency mapping

·        SentinelOne provides supporting endpoint-network evidence when communication can be attributed to an agent-associated process or process tree

·        Splunk may provide supporting investigation and correlation when agent, workload, identity, destination, network, connector, policy, approval, and task telemetry is ingested, but it does not contain a dedicated surviving S25 abnormal-network-activity rule

·        Elastic may provide supporting investigation when process, workload, network, destination, and agent context is normalized, but it does not contain a dedicated surviving S25 abnormal-network-activity rule

·        QRadar provides supporting investigation where agent assets, identities, destination properties, network behavior, reference data, and approved-service exceptions are available

·        SIGMA does not directly provide the complete network-behavior rule but may contribute process-level context for backend correlation

·        AWS, Azure, and GCP provide supporting cloud-network and workload context through platform logs, audit events, flow telemetry, application events, and mapped agent identities where available

·        YARA provides no network-behavior coverage

Coverage Qualification

·        Outbound communication alone is not sufficient

·        A new, rare, direct-IP, suspicious, or unusual destination alone is not sufficient

·        Enterprise AI agents may legitimately communicate with multiple model providers, SaaS platforms, APIs, webhooks, repositories, cloud services, mail systems, monitoring platforms, and business integrations

·        NAT, proxies, shared egress, service meshes, container overlays, browser automation, connector hosts, and managed services may weaken agent or workload attribution

·        Coverage requires reliable enterprise AI-agent workload identification, approved-destination and dependency mapping, destination or session anomalies, process attribution where available, or another corroborating signal

·        NDR cannot independently determine whether untrusted content altered the agent’s instructions or task plan

Unexpected Command or Automation Execution From an Enterprise AI-Agent Context

This behavior is covered where an enterprise AI-agent runtime, browser, connector service, automation worker, code interpreter, orchestration component, container, or supporting process launches a command shell, scripting engine, downloader, archive utility, source-control client, deployment tool, package manager, credential utility, remote-access tool, administrative program, or other high-risk process outside its approved function.

Mapped Coverage

·        SentinelOne provides primary endpoint coverage through process creation, ancestry, command-line, file, credential, path, signer, hash, and network context

·        Splunk provides supporting correlation where process events are associated with enterprise AI-agent applications, workloads, users, tasks, and approved workflows

·        Elastic provides primary endpoint and process correlation using normalized ancestry, command-line, process, file, and network telemetry

·        QRadar provides supporting investigation where endpoint DSMs expose parent process, child process, command line, user, host, asset, and agent context

·        SIGMA provides portable process-creation coverage for high-risk children of approved enterprise AI-agent processes

·        NDR provides supporting evidence when the execution produces external communication, payload retrieval, callback-like activity, or unexpected internal access

·        AWS, Azure, and GCP do not provide a dedicated surviving S25 command-execution rule. Their audit, identity, data-access, and network telemetry may provide investigative context when independently available

·        YARA provides no process-behavior coverage

Coverage Qualification

·        A shell, interpreter, downloader, archive utility, package manager, source-control client, or administrative process alone is not sufficient

·        Approved development, deployment, data-science, browser-automation, security-testing, incident-response, and administrative workflows may create similar processes

·        Coverage requires enterprise AI-agent process attribution, unexpected ancestry, suspicious command behavior, a high-risk execution path, file activity, credential access, network activity, permission changes, or another material condition

·        In-process execution may not create a new child process

·        Cloud-hosted agents may perform consequential activity without producing endpoint-visible execution

·        The event does not independently prove trust injection or successful connected-SaaS modification

Credential or Sensitive-Resource Access Followed by Staging Activity

This behavior is covered where an enterprise AI-agent process or process tree accesses credential stores, browser-session material, OAuth tokens, API keys, environment files, cloud credentials, source-control credentials, SSH material, service-account files, deployment secrets, or other sensitive local resources and subsequently creates an archive, encoded output, compressed data, temporary collection file, script, command-output file, upload preparation, or transfer-tool process.

Mapped Coverage

·        SentinelOne provides primary endpoint correlation across sensitive-resource access, process ancestry, staging, archive creation, encoding, compression, temporary-file creation, and outbound activity

·        Splunk provides supporting correlation where process, file, sensitive-resource, task, workload, user, and network events are normalized

·        Elastic provides supporting event-sequence investigation where sensitive access and staging activity can be associated with the same agent process tree or workload

·        QRadar provides supporting investigation where endpoint telemetry exposes sensitive-resource access, process lineage, staging activity, host, user, and temporal context

·        SIGMA provides portable correlation through agent-associated sensitive-resource access followed by staging activity using a normalized agent process-tree identifier

·        NDR provides supporting evidence when staging is followed by outbound communication

·        AWS, Azure, and GCP provide supporting coverage when sensitive-resource access and subsequent identity, permission, data-access, or transfer activity occurs within their respective cloud environments

·        YARA provides no behavioral staging coverage

Coverage Qualification

·        Credential-file or sensitive-resource access alone is not sufficient

·        Archive, encoding, compression, upload-tool, or transfer-tool execution alone is not sufficient

·        Transfer-tool execution does not prove that data was transmitted

·        Password managers, credential brokers, deployment systems, backup tools, security products, source-control clients, browser-management systems, and administrative workflows may create similar behavior

·        Coverage requires sensitive-resource access plus a material staging or transfer-preparation condition

·        Memory-only access, inherited environment secrets, workload identity, operating-system credential brokers, and cloud API access may not produce the monitored file-access events

·        The correlation does not independently prove credential theft, data disclosure, or trust injection

Unauthorized High-Impact Agent Action

This behavior is covered where an enterprise AI agent, application, connector, service identity, or workflow performs a consequential send, share, delete, modify, create, deploy, financial, identity, security, administrative, or externally visible action without valid user intent, attributable approval, standing authority, or an approved deterministic workflow.

Mapped Coverage

·        Splunk provides primary aggregation and correlation across agent identity, initiating task, requested action, executed action, approval, policy decision, resulting state, recipient, destination, and affected resource

·        QRadar provides primary CRE coverage using agent identities, high-impact action categories, approval records, policy outcomes, authorized workflow data, and affected-resource context

·        NDR provides supporting evidence when the high-impact action creates unusual external or internal communication

·        SentinelOne provides supporting evidence where the action requires local process, browser, script, file, or automation activity

·        Elastic may provide supporting investigation where relevant agent, SaaS, connector, identity, and resulting-state events are ingested, but it does not contain a dedicated surviving S25 high-impact-action rule

·        SIGMA provides supporting event-level process coverage but does not independently establish the complete SaaS authorization context

·        AWS, Azure, and GCP provide supporting evidence where the action modifies cloud identity, permissions, data access, resources, or external data flow

·        YARA provides no high-impact action coverage

Coverage Qualification

·        A high-impact action is not automatically unauthorized

·        Approved agents may legitimately send messages, modify files, update tickets, execute code, deploy changes, process transactions, administer SaaS platforms, or perform security operations

·        A generic approval event is not sufficient unless it can be associated with the exact action, final parameters, recipient, destination, resource, data scope, identity, and execution

·        Coverage requires evidence that the action fell outside valid user intent, attributable approval, standing authority, policy authorization, or an approved workflow

·        The rule may establish unauthorized autonomous activity even when the available evidence cannot distinguish trust injection from malicious user direction, excessive agency, or workflow failure

Sensitive-Data Access Followed by External or Unapproved Transfer

This behavior is covered where an enterprise AI agent, application, connector, identity, workload, browser session, or process accesses restricted, confidential, regulated, credential-related, customer, employee, financial, legal, source-code, security-sensitive, or privileged administrative information and subsequently transfers, shares, copies, publishes, uploads, emails, messages, posts, or sends information to an external or unapproved destination.

Mapped Coverage

·        NDR provides primary or supporting access-to-transfer correlation where sensitive-access events can be joined with agent-associated outbound network activity

·        SentinelOne provides primary endpoint coverage where local sensitive-resource access is followed by staging or outbound activity

·        Splunk provides primary correlation across data classification, source object, agent identity, connector, recipient, destination, transfer action, approval, and policy context

·        Elastic provides primary correlation where sensitive-access and transfer events share task, session, identity, application, workload, object, or bounded temporal context

·        QRadar may provide supporting investigation when sensitive-access, transfer, destination, identity, approval, and temporal events are ingested, but it does not contain a dedicated surviving S25 sensitive-data-transfer rule

·        SIGMA provides portable staging coverage but does not independently prove external transfer

·        AWS provides supporting cloud coverage for sensitive AWS-hosted data followed by transfer to an external account, bucket, service, principal, endpoint, or network destination

·        Azure provides supporting cloud and Microsoft SaaS coverage for sensitive-data access followed by external sharing, cross-tenant transfer, messaging, publication, or outbound activity

·        GCP provides supporting cloud coverage for sensitive GCP-hosted data followed by cross-project, public, external-service, API, repository, or network transfer

·        YARA provides no sensitive-access-to-transfer coverage

Coverage Qualification

·        Sensitive-data access alone is not sufficient

·        Outbound communication alone is not sufficient

·        An external recipient or destination alone is not sufficient

·        Approved reporting, synchronization, backup, migration, analytics, legal, security, support, disaster-recovery, collaboration, and incident-response workflows may create similar sequences

·        Coverage requires a meaningful relationship through task, trace, session, connector, workload, application, process, identity, source object, resource, or bounded temporal context

·        Data may be summarized, transformed, translated, encoded, compressed, embedded, or fragmented before transfer

·        The rules cannot prove that the transferred content was identical to the sensitive content accessed without content, DLP, application, or forensic evidence

·        The sequence does not independently prove that trust injection caused the activity

Denied Agent Activity Followed by Successful Alternate Execution

This behavior is covered where an enterprise AI agent receives a connector denial, policy block, approval rejection, authorization failure, conditional-access denial, recipient restriction, destination restriction, or other enforcement decision and subsequently completes the same or a materially equivalent objective through another tool, connector, application, identity, tenant, API, workflow, browser session, code-execution path, or decomposed action sequence.

Mapped Coverage

·        Splunk provides primary correlation across denied actions, subsequent actions, task and workflow identifiers, changed execution paths, objective matching, and resulting state

·        QRadar provides primary CRE coverage using denial categories, subsequent action results, changed tools or identities, target relationships, approved fallback data, and bounded temporal sequencing

·        Azure provides supporting cloud coverage for denied agent-associated actions followed by successful alternate execution through another application, identity, service principal, managed identity, connector, tenant, API, or workflow

·        NDR provides supporting evidence when alternate execution uses a different network path, destination, browser, webhook, API, or internal service

·        SentinelOne provides supporting evidence when the alternate path involves local browser automation, code execution, scripting, or another process

·        Elastic may provide supporting investigation when denial, execution-path, identity, task, target, and resulting-state events are ingested, but it does not contain a dedicated surviving S25 alternate-execution rule

·        SIGMA may identify process-level alternate execution but depends on backend correlation for the denial-to-success sequence

·        AWS and GCP may contribute denial, audit, identity, and subsequent-action events but do not contain a dedicated surviving S25 rule for the full alternate-execution sequence

·        YARA provides no denial-to-success sequence coverage

Coverage Qualification

·        A denied action alone is not sufficient

·        A retry alone is not sufficient

·        Repeated failures without a consequential state change do not establish alternate execution

·        Legitimate retry, resilience, failover, queue recovery, token refresh, regional recovery, connector fallback, deployment, and administrative behavior may create similar sequences

·        Coverage requires the same or a materially equivalent objective, a changed execution path, and a successful or consequential partial state change

·        Objective matching may be weakened where different tools and platforms describe the same business action using different event names and resource identifiers

·        The sequence does not independently determine whether the behavior resulted from trust injection, legitimate resilience, user direction, or workflow error

Unauthorized Administrative or Persistent Agent Change

This behavior is covered where an enterprise AI agent, application, connector, identity, workload, or automation process modifies persistent instructions, behavior-changing memory, knowledge sources, workflows, automations, templates, connector settings, approval controls, security controls, logging, policy, or administrative configuration outside an approved change process.

Mapped Coverage

·        Elastic provides primary behavioral coverage where persistent configuration, identity, permission, memory, workflow, connector, policy, and administrative events are normalized

·        Splunk may provide supporting investigation and correlation when administrative-change, agent-identity, approval, change-control, recurrence, and downstream-action events are ingested, but it does not contain a dedicated surviving S25 persistent-administrative-change rule

·        QRadar provides primary coverage only where the activity represents agent-associated identity, permission, or connector expansion

·        QRadar may provide supporting investigation for broader memory, workflow, policy, security-control, logging, or configuration changes when those events are ingested, but its surviving S25 rules do not directly implement general persistent-configuration coverage

·        SentinelOne provides supporting endpoint evidence where local configuration files, scripts, scheduled tasks, browser settings, agent workspaces, or automation components are modified

·        NDR provides supporting evidence where persistent changes produce recurring communication or unexpected dependencies

·        SIGMA provides process and file-adjacent supporting coverage but does not independently establish the full SaaS or agent-configuration state change

·        AWS, Azure, and GCP provide supporting coverage when the persistent change affects cloud identities, trust relationships, roles, credentials, organization controls, resource policies, applications, or permissions

·        YARA provides no general persistent-configuration coverage

Coverage Qualification

·        A configuration, policy, workflow, memory, connector, template, or automation change alone is not sufficient

·        Approved deployment, onboarding, connector update, model update, instruction update, testing, red teaming, recovery, administration, and incident response may produce similar changes

·        Ordinary conversation retention does not establish persistence unless it can alter later agent behavior

·        Coverage requires an unauthorized or unapproved change with a material effect on later behavior, access, authority, enforcement, visibility, or recurring execution

·        Persistent influence may reside in external SaaS objects, vector stores, shared documents, repositories, tickets, or knowledge systems that are not centrally audited

Agent-Associated Identity, Role, Permission, or Persistent-Access Change

This behavior is covered where an enterprise AI agent, application, service role, service principal, managed identity, service account, workload identity, connector, or automation process creates or modifies identities, roles, permissions, credentials, trust relationships, OAuth grants, consent, federation, impersonation rights, resource policies, or persistent access paths outside an approved administrative or deployment workflow.

Mapped Coverage

·        AWS provides supporting cloud coverage for unauthorized agent-associated IAM, role, policy, trust-policy, access-key, permission-boundary, federation, resource-policy, or persistent-access changes

·        Azure provides supporting cloud coverage for unauthorized agent-associated users, applications, service principals, managed identities, credentials, federated credentials, OAuth grants, consent, directory roles, Azure RBAC assignments, custom roles, and cross-tenant access changes

·        GCP provides supporting cloud coverage for unauthorized agent-associated service accounts, service-account keys, IAM policies, role bindings, custom roles, workload-identity relationships, external federation, organization policies, and service-account impersonation

·        Elastic provides primary cross-platform correlation where cloud and identity events are consistently normalized

·        QRadar provides primary CRE coverage where the activity represents agent-associated identity, permission, or connector expansion and the affected principals, permissions, connectors, and resulting access are parsed

·        Splunk may provide supporting investigation where cloud identity, agent, application, approval, policy, and change-control events are ingested, but it does not contain a dedicated surviving S25 identity-expansion rule

·        SentinelOne provides supporting evidence only when credential, configuration, or process consequences are visible on an endpoint or workload

·        NDR provides supporting evidence where new identities, credentials, or trust paths are subsequently used for unusual communication or internal access

·        SIGMA provides no complete portable cloud-identity rule for these provider-specific administrative changes

·        YARA provides no identity or permission coverage

Coverage Qualification

·        An identity, role, credential, permission, consent, or policy change alone is not sufficient

·        Approved infrastructure-as-code, onboarding, deployment, credential rotation, identity governance, recovery, break-glass, and administrative workflows may produce similar events

·        Coverage requires an unauthorized change plus a material effect such as privilege expansion, broader resource access, durable credential creation, new federation, new impersonation capability, cross-account or cross-tenant trust, weakened controls, or persistence

·        Subsequent use strengthens confidence but is not required for the initial change detection

·        Shared automation identities, inherited roles, nested groups, service agents, deployment pipelines, and managed services may weaken attribution

·        Cloud identity telemetry cannot independently determine whether trust injection caused the change

Cross-Connector and Cross-Platform Sensitive-Data Movement

This behavior is covered where an enterprise AI agent retrieves sensitive data through one connector, application, SaaS platform, cloud service, repository, mailbox, drive, database, or identity context and then transfers, posts, shares, embeds, summarizes, uploads, or writes the information through another connector or platform outside an approved workflow.

Mapped Coverage

·        Splunk provides primary correlation across source connector, destination connector, data classification, task, session, agent, user, recipient, destination, and approval context

·        Elastic provides primary correlation where source-access and destination-action events retain common task, session, agent, application, object, or identity identifiers

·        QRadar may provide supporting investigation when source-connector, destination-connector, sensitive-data, identity, recipient, destination, and temporal events are ingested, but it does not contain a dedicated surviving S25 cross-connector data-movement rule

·        NDR provides supporting evidence where the second connector or platform produces observable external or cross-tenant communication

·        SentinelOne provides supporting evidence where browser automation, local applications, scripts, staging, clipboard use, or file activity is involved

·        AWS, Azure, and GCP provide supporting coverage where the source or destination data movement occurs within their respective cloud and SaaS ecosystems

·        SIGMA provides supporting endpoint staging coverage but does not independently establish the full cross-connector sequence

·        YARA provides no cross-connector behavioral coverage

Coverage Qualification

·        Use of multiple connectors is not inherently suspicious

·        Approved synchronization, enrichment, migration, reporting, case management, support, backup, collaboration, and administrative workflows may create similar behavior

·        Coverage requires data provenance, source and destination connector mapping, task or session linkage, recipient or destination context, and approved-flow evaluation

·        Cross-connector visibility weakens when content is transformed inside the agent context or provenance is lost

·        The sequence does not prove trust injection unless untrusted content can be shown to have materially influenced the agent’s behavior

Persistent or Recurring Unauthorized Activity Across Later Sessions

This behavior is partially covered where unauthorized actions, identity changes, data transfers, network communication, administrative changes, workflow activity, or sensitive-resource access recur after the original task completes, the initiating content is removed, the user session ends, the connector is revoked, the agent restarts, or remediation is attempted.

Mapped Coverage

·        Elastic provides primary sequence and recurrence coverage where historical agent, SaaS, endpoint, cloud, identity, and persistent-configuration events are retained

·        Splunk may provide supporting historical correlation across sessions, tasks, users, agents, identities, connectors, applications, and resulting actions

·        QRadar may provide primary recurrence coverage where repeated activity is associated with its surviving high-impact-action, identity-permission-connector-expansion, or alternate-execution rules

·        QRadar may provide supporting investigation for broader recurring memory, workflow, policy, configuration, transfer, or network behavior when the relevant events are ingested

·        NDR provides supporting evidence for recurring callbacks, destination reuse, destination rotation, persistent internal dependencies, or communication continuing after task completion

·        SentinelOne provides supporting endpoint Storyline, process, file, persistence, and network evidence

·        AWS, Azure, and GCP provide supporting evidence where persistent identities, roles, credentials, trust relationships, resources, or data flows remain active

·        SIGMA provides portable event-level evidence but depends on backend temporal and cross-rule correlation

·        YARA remains non-deployable unless a stable malicious persistence artifact or reusable payload is recovered

Coverage Qualification

·        Recurrence alone is not sufficient

·        Legitimate scheduled workflows, synchronization, retries, recovery, deployment, rotation, maintenance, and recurring business processes may produce similar behavior

·        Coverage requires linkage to an unauthorized action, persistent change, unapproved identity, suspicious destination, sensitive-data sequence, or other material behavior

·        Persistent influence may reside in behavior-changing memory, saved instructions, knowledge bases, vector stores, workflows, SaaS objects, shared documents, repositories, or external systems that are not centrally audited

·        Downstream activity remains an investigative lead unless it can be linked temporally and behaviorally to the original agent-manipulation or unauthorized-action sequence

NDR / Network Behavioral Analytics Coverage Disposition

NDR / Network Behavioral Analytics provides two independently deployable rule families:

·        Abnormal network activity from an enterprise AI-agent workload

·        Sensitive enterprise data access followed by agent-associated external transfer

NDR provides primary or supporting coverage for new or unapproved destinations, unusual internal dependencies, callback-like communication, payload-retrieval-like behavior, tunneling-like sessions, destination rotation, communication after task completion, and sensitive-access-to-transfer sequences.

NDR cannot independently confirm trust injection, instruction influence, task-plan manipulation, approval validity, exact transferred content, successful SaaS modification, identity change, or the original cause of the activity.

SentinelOne Coverage Disposition

SentinelOne provides two primary endpoint rule families:

·        Unexpected command or automation execution from an enterprise AI-agent context

·        Credential or sensitive-data access followed by staging or outbound activity

Coverage depends on active endpoint or workload deployment, accurate enterprise AI-agent process mapping, complete process ancestry, sensitive-resource coverage, file and network telemetry, approved process and workflow exceptions, and reliable process-to-agent attribution.

SentinelOne does not directly observe cloud-hosted prompt context, internal agent planning, approval validity, or actions performed entirely through SaaS APIs without endpoint-visible consequences.

Splunk Coverage Disposition

Splunk provides three primary behavioral and correlation rules:

·        High-impact agent action without valid approval

·        Sensitive-data access followed by transfer through another connector or destination

·        Denied agent action followed by alternate-path or partial execution

Coverage depends on validated indexes, sourcetypes, normalized fields, authoritative enterprise AI-agent identity and application inventories, task and session identifiers, action categories, approval records, policy decisions, SaaS audit events, sensitive-data classifications, approved data flows, approved fallback paths, and resulting-state evidence.

Splunk may support investigation of execution, persistent-change, identity-expansion, network, or recurrence behavior when the relevant events are ingested, but those behaviors are not implemented as separate surviving Splunk S25 rules.

Elastic Coverage Disposition

Elastic provides three primary behavioral rules:

·        Unexpected execution from an enterprise AI-agent process or workload

·        Sensitive-data access followed by agent-associated external transfer

·        Unauthorized agent-associated identity, permission, or persistent configuration change

Coverage depends on reliable ECS or locally consistent mappings for agent identity, task, session, process, file, network, connector, SaaS action, data classification, administrative change, approval, policy, destination, and approved exceptions.

Elastic may provide supporting investigation for high-impact actions, denied-to-alternate execution, and other correlated agent behavior when the relevant events are ingested, but those behaviors are not implemented as separate surviving Elastic S25 rules.

Elastic must not promote one process, file, SaaS, cloud, identity, or network event to confirmed trust injection without supporting behavioral linkage.

QRadar Coverage Disposition

QRadar provides three primary CRE rule families:

·        Unauthorized high-impact agent-associated action

·        Agent-associated identity, permission, or connector expansion

·        Denied agent activity followed by successful alternate execution

Coverage depends on validated DSM parsing, custom properties, enterprise AI-agent asset and identity building blocks, high-impact action mappings, identity, permission and connector-change properties, denial and subsequent-success categories, approval and policy properties, approved workflow and fallback reference data, offense indexing, response limiters, and bounded temporal correlation.

QRadar may provide supporting investigation for sensitive-data transfer, cross-connector data movement, persistent memory, workflow, policy, security-control, logging, network, or broader configuration changes when the relevant events are ingested. Those behaviors are not implemented as dedicated surviving QRadar S25 rules.

QRadar cannot provide reliable coverage where the required agent, identity, application, approval, action, permission, connector, denial, resulting-state, or temporal properties are absent or inconsistently normalized.

SIGMA Coverage Disposition

SIGMA provides two portable rule families:

·        Unexpected command or automation execution from an enterprise AI-agent process

·        Agent-associated sensitive-resource access followed by staging activity

SIGMA provides portable event-level and temporal-correlation coverage for process creation, command-line behavior, sensitive-resource access, process lineage, archive or encoding activity, and transfer-tool preparation.

Coverage remains dependent on the target backend for field translation, agent-process scoping, file-access telemetry, normalized process-tree identifiers, approved-process exceptions, temporal correlation, and local path mappings. SIGMA does not independently provide the complete trust-injection-to-SaaS-action chain.

YARA Coverage Disposition

YARA has zero deployable rules for this EXP report.

YARA is not viable as a primary S25 detection system because the report’s detection model is behavioral, agent-action based, identity and permission based, approval and policy based, SaaS and connector activity based, process-execution based, network-correlation based, and SIEM-correlation based rather than dependent on a stable malicious file or reusable malware signature.

YARA may provide limited supporting value only if a confirmed malicious script, loader, encoded payload, browser artifact, agent plugin, connector package, configuration structure, persistence component, archive, memory artifact, or reusable malware family is recovered and independently validated.

Final YARA Outcome

No YARA rules survive.

AWS Coverage Disposition

AWS provides two supporting cloud rules:

·        Unauthorized agent-associated IAM, role, policy, or persistent access change

·        Agent-associated sensitive-data access followed by external or unapproved transfer

AWS provides supporting coverage through CloudTrail management and data events, IAM and STS activity, service-role and workload mapping, S3 and service data-access events, data classification, transfer activity, and network context.

AWS does not independently prove trust injection, malicious intent, exact content transfer, or account compromise from one CloudTrail, IAM, S3, workload, or network event. Coverage depends on complete audit logging, accurate agent-associated identity mapping, approved-change and approved-data-flow definitions, data classification, and reliable correlation identifiers.

Azure Coverage Disposition

Azure provides three supporting cloud rules:

·        Unauthorized agent-associated identity, application, role, or permission change

·        Agent-associated sensitive-data access followed by external or unapproved transfer

·        Denied agent-associated action followed by successful alternate execution

Azure provides supporting coverage through Microsoft Entra ID, Azure Activity, Microsoft cloud and SaaS audit events, data classification, DLP, workload identity, application, transfer, approval, policy, and resulting-action telemetry.

Azure does not independently prove trust injection, exact transferred content, or malicious intent from one identity, audit, DLP, transfer, or policy event. Coverage depends on complete logging, accurate enterprise AI-agent application and identity mapping, approved changes, approved data flows, approved fallback behavior, objective matching, and reliable resulting-state evidence.

GCP Coverage Disposition

GCP provides two supporting cloud rules:

·        Unauthorized agent-associated IAM, service-account, role, or persistent-access change

·        Agent-associated sensitive-data access followed by external or unapproved transfer

GCP provides supporting coverage through Cloud Audit Logs, IAM and service-account activity, workload identity and federation changes, Data Access events, Cloud Storage and service data access, Sensitive Data Protection, application events, and network telemetry.

GCP does not independently prove trust injection, exact content transfer, or malicious intent from one IAM, audit, storage, DLP, workload, or network event. Coverage depends on complete audit logging, accurate agent-associated principal mapping, approved-change and approved-data-flow definitions, data classification, and strong correlation identifiers.

Coverage Gaps and Non-Coverage Conditions

The S25 rule set does not independently prove that untrusted content altered an agent’s instructions, that a task-plan change resulted from trust injection, that a generated tool call executed, that a generic approval covered the final parameters, that accessed sensitive data was identical to transferred data, that a cloud identity change resulted from malicious content, that alternate execution was malicious rather than legitimate resilience, or that downstream activity resulted from the specific initiating content.

Coverage Weakens Under the Following Conditions

·        Prompt, retrieved-content, task-plan, goal-change, tool-selection, or trace telemetry is unavailable

·        Agent platforms log only successful tool calls and omit proposed, blocked, modified, rejected, or alternate actions

·        Tool-call arguments, recipients, destinations, resources, data scope, and resulting objects are truncated, redacted, normalized, or unavailable

·        Approval records do not preserve the exact parameters reviewed by the user

·        Final executed parameters cannot be compared with approved parameters

·        Agent actions and direct human actions use the same delegated identity

·        Shared service accounts, OAuth applications, service principals, managed identities, connectors, or workload identities weaken attribution

·        SaaS audit logs omit searches, previews, reads, downloads, exports, returned records, or resulting state

·        Sensitive-data classification is unavailable, stale, incomplete, or inconsistent across platforms

·        Cross-connector data provenance is lost inside the agent context

·        Data is summarized, transformed, encoded, translated, compressed, embedded, or fragmented before transfer

·        Enterprise AI-agent workloads, applications, identities, connectors, tools, cloud resources, and downstream SaaS platforms are not authoritatively inventoried

·        Approved workflows, destinations, recipients, tenants, applications, connectors, identities, data flows, fallback paths, deployments, and administrative changes are not accurately modeled

·        Browser automation and computer-use activity occurs without structured tool-call, DOM, screenshot, session, or endpoint telemetry

·        Local execution remains inside an existing browser, runtime, interpreter, automation process, or container

·        Endpoint process ancestry, command lines, file events, sensitive-resource access, process-tree identifiers, or process-to-network attribution are incomplete

·        Agent activity occurs on unmanaged endpoints or workloads without EDR, file, process, or network visibility

·        Cloud Audit Logs, CloudTrail, Entra ID, Azure Activity, SaaS audit, or data-access events are disabled, delayed, sampled, or incomplete

·        IAM, role, permission, consent, federation, credential, trust, and resource-policy changes cannot be associated with the responsible agent or application

·        Inherited roles, nested groups, shared principals, deployment pipelines, service agents, or managed-service activity obscure the effective privilege change

·        Network communication uses approved services, model providers, SaaS platforms, repositories, proxies, integrations, or existing sessions

·        NAT, proxies, service meshes, shared egress, container networking, browser infrastructure, or managed connectors obscure the responsible agent or workload

·        Local-only, same-host, cloud-internal, or SaaS-to-SaaS activity does not traverse monitored network paths

·        Denial and subsequent-success events cannot be associated with the same or a materially equivalent objective

·        Legitimate retry, failover, queue recovery, token refresh, resilience, deployment, synchronization, maintenance, or administrative behavior is not accurately modeled

·        Persistent instructions, behavior-changing memory, knowledge bases, vector stores, workflows, templates, policies, connector settings, and downstream SaaS objects are not versioned or audited

·        Multi-agent handoffs do not preserve source agent, destination agent, transferred context, instructions, tools, and resulting actions

·        One prompt classifier alert, unusual model response, tool-call anomaly, denied action, process event, sensitive-data access, outbound connection, cloud identity change, DLP event, or other isolated signal is treated as proof of compromise

·        Logs are stored only locally and can be altered, deleted, truncated, overwritten, or lost during workload replacement

·        Telemetry was enabled only after the relevant activity

·        A zero-event result is treated as proof that trust injection or unauthorized activity did not occur

Traceability Conclusion

The S25 detection set provides broad behavior-led coverage across abnormal enterprise AI-agent workload communication, unexpected command and automation execution, sensitive-resource access followed by staging, unauthorized high-impact agent actions, sensitive-data access followed by unapproved transfer, denied activity followed by alternate execution, unauthorized persistent administrative changes, cloud identity and permission expansion, cross-connector data movement, and recurring unauthorized behavior.

The surviving rules provide direct behavioral coverage for observable agent-associated endpoint, network, SaaS, identity, approval, policy, data-access, administrative, and cloud activity. They provide supporting evidence for trust injection when those behaviors can be linked to untrusted content, task-plan changes, tool-selection influence, or manipulated agent context.

The rule set intentionally avoids treating one prompt phrase, classifier alert, unusual response, tool request, denied action, high-impact SaaS event, sensitive-data access, process execution, archive creation, network connection, identity change, cloud audit event, or DLP event as proof of successful trust injection.

Detection confidence depends on correlating content exposure, agent planning, tool use, approval, policy, identity, connector, SaaS, endpoint, network, cloud, persistent change, and resulting-state evidence while preserving the distinction between adversarial-content exposure, suspected trust injection, probable instruction influence, attempted tool misuse, blocked autonomous action, partially completed unauthorized action, unauthorized autonomous action, sensitive-data exposure, persistent compromise, and confirmed downstream organizational impact.

S27 — Behavior & Log Artifacts

Purpose

This section identifies the primary behavior and log artifacts that support detection, investigation, triage, and validation for enterprise AI-agent trust manipulation, instruction influence, task-plan redirection, unauthorized tool use, connected-SaaS access, sensitive-data exposure, high-impact autonomous action, alternate-path execution, identity and permission expansion, persistent agent changes, endpoint execution, outbound communication, cleanup, recurrence, and downstream organizational impact.

The artifacts below are behavior-led. They should not be treated as proof of successful trust injection, unauthorized autonomous action, sensitive-data disclosure, credential theft, persistent compromise, downstream compromise, actor attribution, campaign attribution, or abuse of a specific model, agent framework, connector, application, or SaaS platform unless they are correlated into a coherent sequence.

Primary Artifact Categories

·        Enterprise AI-agent, model, owner, business-purpose, environment, and criticality artifacts

·        Prompt, instruction, retrieved-content, context, trust-classification, and source-provenance artifacts

·        Agent task, session, trace, plan, step, goal-change, and completion-state artifacts

·        Tool-call, connector, normalized argument, target-resource, recipient, destination, and action artifacts

·        Approval, policy, authorization, denial, exception, and executed-parameter artifacts

·        Enterprise SaaS audit, object-access, administrative-action, and resulting-state artifacts

·        Sensitive-data classification, DLP, information-protection, CASB, insider-risk, and transfer artifacts

·        OAuth, token, application, service-principal, managed-identity, service-account, permission, role, consent, and federation artifacts

·        Agent-runtime, browser, automation-worker, code-interpreter, orchestration, process, and container artifacts

·        Credential, token, secret, browser-session, environment, source-control, cloud-configuration, and sensitive-resource artifacts

·        File staging, archive, encoding, compression, temporary-file, clipboard, and transfer-preparation artifacts

·        DNS, proxy, firewall, NDR, flow, TLS, API-gateway, webhook, and endpoint-network artifacts

·        Persistent instruction, behavior-changing memory, knowledge-base, vector-store, workflow, automation, connector, template, policy, and configuration artifacts

·        Multi-agent handoff, transferred-context, source-agent, destination-agent, and resulting-action artifacts

·        Log deletion, audit impairment, history removal, evidence deletion, misleading completion, and cleanup artifacts

·        Agent restart, session reset, connector revocation, workload replacement, remediation, and recurrence artifacts

·        Approved deployment, administration, synchronization, migration, backup, testing, red-team, evaluation, maintenance, and incident-response artifacts

·        AWS CloudTrail, IAM, STS, S3, application, data-access, and network artifacts

·        Microsoft Entra ID, Azure Activity, Microsoft SaaS audit, DLP, Sentinel, and cloud-resource artifacts

·        Google Cloud Audit Logs, IAM, service-account, Cloud Storage, Sensitive Data Protection, application, and network artifacts

·        Agent, task, session, trace, connector, identity, process-tree, SaaS object, cloud resource, network session, and timestamp correlation artifacts

Enterprise AI-Agent Inventory, Ownership, and Exposure Artifacts

Relevant Artifacts

Agent identifier, agent name, assistant name, model provider, model name, model version, runtime, framework, orchestration platform, deployment environment, owner, business unit, business purpose, approved users, approved identities, approved tools, approved connectors, approved data sources, approved SaaS platforms, expected recipients, expected destinations, expected action classes, criticality, data-access level, approval requirements, policy version, instruction version, deployment version, internet exposure, browser access, code-execution capability, computer-use capability, administrative capability, and event timestamp.

Useful Log Sources

·        Enterprise AI-agent inventories

·        Configuration-management databases

·        Model and agent administration portals

·        AI gateways

·        Orchestration platforms

·        Connector-management systems

·        SaaS-security platforms

·        Identity-governance systems

·        Cloud-resource inventories

·        Endpoint and workload inventories

·        SIEM-normalized asset data

Detection Use

These artifacts define which enterprise AI agents exist, what each agent is permitted to access, which actions each agent may perform, which identities and connectors it uses, and which behaviors should be considered expected or anomalous.

They are essential for distinguishing activity associated with a monitored enterprise agent from generic user, application, SaaS, cloud, endpoint, or network activity.

Investigation Use

Investigators should determine the responsible agent, model, owner, runtime, version, task, identity, connectors, tools, data sources, approval controls, downstream platforms, and approved business purpose before interpreting prompt, tool, SaaS, identity, process, file, or network evidence.

Non-Coverage Conditions

An enterprise AI agent alone is not sufficient.

Tool access alone is not sufficient.

A high-privilege connector alone is not sufficient.

Stale or incomplete agent-to-identity, agent-to-connector, agent-to-owner, or agent-to-SaaS mappings materially weaken attribution.

Prompt, Instruction, Retrieved-Content, and Source-Provenance Artifacts

Relevant Artifacts

System instruction, developer instruction, user request, retrieved content, tool result, behavior-changing memory, output context, content source, source owner, source tenant, source URL, document identifier, email identifier, message identifier, repository identifier, ticket identifier, calendar identifier, API-response identifier, content hash, chunk identifier, retrieval query, retrieval rank, citation, trust classification, external-control state, user-editable state, instruction-like content, role claim, policy claim, approval claim, secrecy instruction, concealment instruction, tool directive, encoded content, hidden content, multilingual content, fragmented content, normalized content, classifier result, task identifier, session identifier, trace identifier, and event timestamp.

Useful Log Sources

·        AI gateways

·        Model-access gateways

·        Enterprise-agent runtimes

·        Retrieval and search systems

·        Vector stores

·        Knowledge bases

·        Email and collaboration audit logs

·        Document and file-platform audit logs

·        Repository and ticketing telemetry

·        API gateways

·        Prompt-injection and model-security platforms

·        SIEM-normalized agent telemetry

Detection Use

These artifacts support detection when externally controlled or user-editable content attempts to redefine the agent’s role, override prior instructions, claim false authorization, suppress approval, alter recipients or destinations, influence tool selection, or redirect the agent toward an unauthorized objective.

Investigation Use

Investigators should reconstruct the complete agent context and identify which content object introduced the instruction, how the content was classified, when it entered the context, whether it was retrieved or directly supplied, and whether the content materially affected later planning or action.

Non-Coverage Conditions

Imperative language alone is not sufficient.

The phrase “ignore previous instructions” alone is not sufficient.

A prompt-injection classifier alert alone is not sufficient.

Quoted security research, policy text, documentation, code examples, and training material may contain similar language.

Prompt or content logging may be limited by privacy, legal, contractual, or platform constraints.

Agent Task, Session, Trace, Plan, and Goal-Change Artifacts

Relevant Artifacts

Task identifier, session identifier, trace identifier, run identifier, initiating user, agent identity, model, model version, instruction version, policy version, initial objective, initial constraints, initial recipients, initial destinations, initial data scope, task plan, plan version, step sequence, selected tool, selected connector, goal change, recipient change, destination change, data-scope change, privilege request, action transition, retry, exception, denial, alternate path, completion state, partial completion, final response, user-visible summary, execution result, and event timestamp.

Useful Log Sources

·        Agent-runtime logs

·        Orchestration and planner telemetry

·        AI gateways

·        Tool-selection logs

·        Workflow engines

·        Automation platforms

·        Model-observability platforms

·        Trace and distributed-observability systems

·        SIEM-normalized task telemetry

Detection Use

These artifacts support detection when a read-only, analytical, or summarization task changes into a write, send, share, delete, financial, administrative, identity, deployment, security-control, or externally communicative task after untrusted content is processed.

Investigation Use

Investigators should compare the initial user request with later plans, tool selections, connectors, recipients, destinations, data scope, and completion criteria to determine whether the agent’s objective materially changed.

Non-Coverage Conditions

A plan revision alone is not sufficient.

Agents may legitimately change plans as new information becomes available.

Platforms may retain only the final plan or executed tool calls.

A changed model response does not prove that downstream behavior changed.

Tool-Call, Connector, Argument, and Action Artifacts

Relevant Artifacts

Tool name, connector name, application, function, function version, normalized arguments, original arguments, target resource, resource identifier, action type, data scope, recipient, destination, tenant, repository, mailbox, drive, channel, ticket, customer object, financial object, identity object, configuration object, requested result, actual result, error, retry, policy decision, approval requirement, approval state, execution state, resulting object, resulting state, task identifier, session identifier, trace identifier, user identity, agent identity, application identity, connector identity, and event timestamp.

Useful Log Sources

·        Enterprise-agent tool-call logs

·        Connector platforms

·        SaaS audit logs

·        API gateways

·        Workflow engines

·        Automation platforms

·        Tool-security and tool-firewall products

·        Browser-automation logs

·        Computer-use telemetry

·        SIEM-normalized application telemetry

Detection Use

These artifacts support detection when an agent invokes a tool or connector not required by the initiating task, exceeds the expected data or privilege scope, uses parameters derived from untrusted content, attempts a high-impact action, or changes execution paths after denial.

Investigation Use

Investigators should compare the tool and parameters with the initiating task, approved workflow, policy decision, approval record, expected agent function, and resulting state.

Non-Coverage Conditions

A generated tool call does not prove execution.

A failed tool call does not prove malicious intent.

Tool arguments may be redacted or truncated.

A connector may record the human user rather than the responsible agent.

Approval, Policy, Authorization, and Executed-Parameter Artifacts

Relevant Artifacts

Approval identifier, approving user, approving role, approval timestamp, reviewed action, reviewed parameters, reviewed recipient, reviewed destination, reviewed resource, reviewed data scope, reviewed identity, expiration time, policy identifier, policy version, policy result, authorization decision, denial reason, exception, override, modification, cancellation, timeout, final executed action, final executed parameters, final recipient, final destination, final resource, final identity, execution timestamp, resulting state, and event timestamp.

Useful Log Sources

·        Human-approval systems

·        Workflow platforms

·        Policy engines

·        Tool-security platforms

·        SaaS audit systems

·        Identity and access-management platforms

·        Conditional-access systems

·        Privileged-access systems

·        SIEM correlation

Detection Use

These artifacts support detection when a high-impact action occurs without approval, when approval is generic or unattributable, when parameters change after review, or when an agent completes an objective through another path after an approval or policy denial.

Investigation Use

Investigators should verify that the approving user reviewed the exact final action and parameters and that the executed operation did not materially differ from the approved operation.

Non-Coverage Conditions

An approval event alone is not sufficient.

Approval without preserved parameters cannot validate the executed action.

A policy denial alone does not prove malicious intent.

Legitimate retries, failover, and workflow recovery may follow a denial.

Enterprise SaaS Audit and Resulting-State Artifacts

Relevant Artifacts

SaaS platform, tenant, application, user, agent, service identity, action, object type, object identifier, mailbox, file, folder, drive, channel, message, ticket, repository, branch, workflow, customer record, financial record, user object, role, permission, configuration, send, share, download, export, upload, create, modify, delete, invite, publish, consent, deployment, administrative action, result, resulting state, recipient, destination, external state, public state, sensitivity, task identifier, session identifier, trace identifier, and event timestamp.

Useful Log Sources

·        Email-platform audit logs

·        Collaboration-platform audit logs

·        File-storage audit logs

·        Customer-management systems

·        Ticketing systems

·        Source-control platforms

·        CI/CD platforms

·        Financial and procurement systems

·        Human-resources systems

·        Identity platforms

·        Security platforms

·        SIEM-normalized SaaS telemetry

Detection Use

These artifacts support detection of unauthorized autonomous actions, external communications, permission changes, user or role changes, destructive actions, administrative operations, and resulting-state changes.

Investigation Use

Investigators should determine whether the SaaS action was performed by the agent, the human user, an application, or a shared identity and whether the action aligned with the initiating task and approval.

Non-Coverage Conditions

A SaaS action alone is not sufficient.

Approved agents may legitimately perform high-impact actions.

Shared identities may weaken attribution.

Some SaaS platforms do not record searches, previews, reads, or returned data.

Sensitive-Data Classification, Access, and Transfer Artifacts

Relevant Artifacts

Data classification, sensitivity label, regulated-data category, credential category, customer-data category, employee-data category, financial-data category, legal-data category, source-code category, security-data category, privileged-record category, source object, source platform, accessed fields, access method, read, search, preview, download, export, generated output, transfer action, destination, recipient, tenant, application, public-sharing state, bytes, records, object count, DLP result, information-protection result, CASB result, insider-risk result, task identifier, agent identity, connector identity, and event timestamp.

Useful Log Sources

·        SaaS audit logs

·        Data-loss prevention systems

·        Information-protection platforms

·        CASB platforms

·        Insider-risk platforms

·        Data-security posture systems

·        Database audit logs

·        File-platform logs

·        Repository audit logs

·        Cloud data-access logs

·        SIEM-normalized data telemetry

Detection Use

These artifacts support detection when an agent accesses sensitive information outside the expected task scope or transfers it through another connector, application, recipient, tenant, API, repository, webhook, or network destination.

Investigation Use

Investigators should determine what information was accessed, whether the access was necessary, where the information was sent, and whether source-to-destination provenance can be reconstructed.

Non-Coverage Conditions

Sensitive-data access alone is not sufficient.

An external transfer alone is not sufficient.

DLP may detect an attempted transfer without proving the initiating agent behavior.

Data may be transformed, summarized, translated, encoded, compressed, or fragmented before transfer.

OAuth, Application, Identity, Permission, and Persistent-Access Artifacts

Relevant Artifacts

User, group, role, application, service principal, managed identity, service account, workload identity, OAuth grant, delegated permission, application permission, API scope, token, refresh token, application consent, credential, secret, certificate, access key, service-account key, role assignment, custom role, policy, trust policy, federation, workload identity, impersonation permission, cross-account trust, cross-tenant access, resource policy, permission boundary, organization policy, creation, modification, deletion, initiator, agent association, approval, change ticket, resulting access, and event timestamp.

Useful Log Sources

·        Identity-provider logs

·        OAuth and application-consent logs

·        Microsoft Entra ID

·        AWS CloudTrail, IAM, and STS

·        Google Cloud Audit Logs and IAM

·        SaaS application-management logs

·        Privileged-access platforms

·        Identity-governance systems

·        SIEM-normalized identity telemetry

Detection Use

These artifacts support detection when an agent-associated identity, application, connector, service principal, service account, or workload identity gains new privileges, durable credentials, broader scopes, federation, impersonation capability, or persistent access outside an approved workflow.

Investigation Use

Investigators should determine what authority changed, who initiated the change, which agent or application benefited, whether the change was approved, and whether the new access was subsequently used.

Non-Coverage Conditions

An identity or permission change alone is not sufficient.

Infrastructure-as-code, onboarding, deployment, credential rotation, and identity governance may create similar events.

Inherited roles and nested groups may obscure effective privilege.

A cloud identity change does not independently prove trust injection.

Agent Runtime, Browser, Process, and Execution Artifacts

Relevant Artifacts

Process name, process path, parent process, grandparent process, process-tree identifier, process ID, process entity ID, command line, working directory, user, session, effective identity, container, pod, workload, runtime, browser, extension, automation worker, code interpreter, orchestration component, script engine, downloader, package manager, source-control client, deployment tool, credential utility, remote-access tool, administrative utility, hash, signer, loaded module, file operation, network connection, task identifier, trace identifier, and event timestamp.

Useful Log Sources

·        SentinelOne Deep Visibility

·        EDR process telemetry

·        Browser-security platforms

·        Computer-use and browser-automation logs

·        Container-runtime telemetry

·        Workload-protection platforms

·        Operating-system audit logs

·        SIEM-normalized process telemetry

Detection Use

These artifacts support detection when enterprise AI-agent processes launch unexpected command shells, scripts, downloaders, deployment tools, administrative utilities, credential tools, or other high-risk child processes.

Investigation Use

Investigators should determine whether the child process was expected for the agent, whether the command aligned with the approved workflow, and whether credential, file, network, or persistence activity followed.

Non-Coverage Conditions

A shell or interpreter alone is not sufficient.

Approved development and automation may create similar processes.

Browser automation may remain inside an existing process.

Cloud-hosted agents may create no endpoint-visible execution.

Credential, Token, Secret, and Sensitive-Resource Artifacts

Relevant Artifacts

Credential-store access, browser credential access, browser-session access, OAuth-token access, API-key access, environment-file access, environment-variable access, cloud-credential access, source-control credential access, SSH material, service-account file, deployment secret, password-manager access, clipboard access, operating-system credential-broker access, secret-store request, source process, process tree, user, session, workload identity, task identifier, and event timestamp.

Useful Log Sources

·        EDR file-access telemetry

·        Process telemetry

·        Browser-security telemetry

·        Secret-management audit logs

·        Cloud identity logs

·        Source-control audit logs

·        Operating-system audit logs

·        SIEM-normalized sensitive-resource telemetry

Detection Use

These artifacts support detection when an agent-associated process accesses credential or sensitive-resource material and later stages, transforms, archives, or transfers data.

Investigation Use

Investigators should identify the resource accessed, the responsible process tree, whether the access was expected, and whether staging or outbound activity followed.

Non-Coverage Conditions

Sensitive-resource access alone is not sufficient.

Secrets may be inherited through environment variables or workload identity.

Memory-only access may not produce file events.

Approved credential brokers and deployment systems may create similar activity.

File Staging, Archive, Encoding, and Transfer-Preparation Artifacts

Relevant Artifacts

File name, path, operation, temporary path, archive creation, compression, encoding, translation, transformation, command-output file, collection file, script creation, upload-tool execution, transfer-tool execution, clipboard access, file size, hash, first-seen time, initiating process, process-tree identifier, user, endpoint, container, workload, destination, task identifier, and event timestamp.

Useful Log Sources

·        EDR file telemetry

·        SentinelOne Deep Visibility

·        Operating-system audit logs

·        Container filesystem telemetry

·        Browser and clipboard telemetry where available

·        File-integrity monitoring

·        SIEM-normalized file telemetry

Detection Use

These artifacts support detection when sensitive-resource access is followed by archive creation, compression, encoding, collection, scripting, or transfer preparation.

Investigation Use

Investigators should determine whether the staged material originated from sensitive resources, whether the process tree was agent-associated, and whether the staged output was subsequently transmitted.

Non-Coverage Conditions

Archive creation alone is not sufficient.

Compression or encoding alone is not sufficient.

Transfer-tool execution does not prove successful transfer.

Backup, deployment, security, and administrative workflows may create similar files.

Network, DNS, Proxy, Firewall, NDR, API-Gateway, and Webhook Artifacts

Relevant Artifacts

Source IP, destination IP, source port, destination port, domain, DNS query, DNS response, protocol, TLS metadata, certificate, SNI, connection direction, duration, bytes, packets, connection state, first-seen destination, prevalence, ASN, geography, reputation, direct-IP communication, periodic behavior, interactive behavior, callback-like behavior, payload-retrieval-like behavior, tunneling-like behavior, destination rotation, communication after task completion, internal service role, source workload, source process, connector, application, agent identity, task identifier, session identifier, and event timestamp.

Useful Log Sources

·        NDR / Network Behavioral Analytics

·        SentinelOne network telemetry

·        DNS logs

·        Proxy logs

·        Firewall logs

·        Flow logs

·        API-gateway logs

·        Webhook logs

·        Endpoint-network telemetry

·        Cloud-network telemetry

·        SIEM-normalized network telemetry

Detection Use

These artifacts support detection when an enterprise AI-agent workload communicates with a new, rare, prohibited, unmanaged, direct-IP, suspicious, role-inconsistent, or unexpected internal destination.

Investigation Use

Investigators should determine whether the destination was required by the task, approved for the agent, associated with an expected connector, and preceded by suspicious tool, process, sensitive-data, or denial activity.

Non-Coverage Conditions

Outbound communication alone is not sufficient.

A rare destination alone is not sufficient.

Direct-IP communication alone is not sufficient.

Approved cloud services and existing sessions may be abused.

Encrypted traffic may conceal transferred content.

Persistent Instruction, Memory, Knowledge, Workflow, and Configuration Artifacts

Relevant Artifacts

System instruction, developer instruction, saved prompt, behavior-changing memory, knowledge-base entry, vector-store entry, template, workflow, automation, rule, policy, connector setting, tool availability, approval requirement, recipient restriction, destination restriction, execution constraint, webhook, scheduled workflow, mailbox rule, repository action, CI/CD job, shared document, ticket, version, initiator, approval, change ticket, resulting behavior, recurrence, and event timestamp.

Useful Log Sources

·        Agent-administration platforms

·        Memory and knowledge systems

·        Vector-store audit logs

·        Workflow and automation platforms

·        SaaS audit logs

·        Repository and CI/CD audit logs

·        Configuration-management systems

·        SIEM-normalized configuration telemetry

Detection Use

These artifacts support detection when unauthorized changes create persistent influence over later sessions, users, agents, tools, connectors, or SaaS actions.

Investigation Use

Investigators should compare current and trusted versions, identify who or what made the change, and determine whether later unauthorized behavior depended on the modified content or configuration.

Non-Coverage Conditions

Ordinary conversation retention is not sufficient.

A workflow or configuration change alone is not sufficient.

Approved deployment and administration may create similar changes.

Persistent influence may reside in external systems that are not centrally audited.

Multi-Agent Handoff and Propagation Artifacts

Relevant Artifacts

Source agent, destination agent, source task, destination task, transferred context, transferred instructions, transferred data, tool result, message, document, ticket, repository artifact, knowledge object, workflow event, source identity, destination identity, connector, recipient, resulting action, resulting state, task identifier, session identifier, trace identifier, and event timestamp.

Useful Log Sources

·        Multi-agent orchestration platforms

·        Workflow engines

·        Agent messaging systems

·        Collaboration platforms

·        Ticketing systems

·        Repository platforms

·        Knowledge and vector systems

·        SIEM-normalized agent telemetry

Detection Use

These artifacts support detection when manipulated content, unauthorized objectives, or sensitive information propagates from one agent to another and results in consequential action.

Investigation Use

Investigators should reconstruct the provenance of transferred context and determine which agent introduced the instruction and which agent performed the action.

Non-Coverage Conditions

Agent-to-agent communication alone is not sufficient.

Shared context may be legitimate.

Provenance may be lost as content passes between agents and tools.

The downstream agent may act under a different identity or session.

Cleanup, Audit-Impairment, and Misleading-Completion Artifacts

Relevant Artifacts

Prompt-history deletion, tool-call deletion, message deletion, file deletion, SaaS-object deletion, audit disabling, log-forwarding interruption, policy disablement, retention change, connector removal, history removal, behavior-changing memory alteration, workflow deletion, temporary-file removal, archive deletion, script deletion, browser-history deletion, misleading completion statement, false approval claim, false success statement, initiating identity, process, agent, task identifier, and event timestamp.

Useful Log Sources

·        SaaS audit logs

·        EDR file telemetry

·        Agent-platform audit logs

·        Log-forwarding platforms

·        SIEM health monitoring

·        Policy and configuration logs

·        Incident-response records

Detection Use

These artifacts support detection when evidence, logs, persistent changes, or unauthorized actions are concealed or removed after suspicious agent activity.

Investigation Use

Investigators should determine whether deletion or alteration was part of retention, privacy processing, synchronization, maintenance, remediation, or incident response and whether protected copies remain.

Non-Coverage Conditions

Deletion alone is not sufficient.

Retention policies may remove data legitimately.

Workload replacement may remove local evidence without malicious intent.

Cleanup may occur before telemetry is forwarded.

Restart, Session Reset, Connector Revocation, Remediation, and Recurrence Artifacts

Relevant Artifacts

Agent restart, browser restart, session reset, connector revocation, token revocation, application disablement, workload restart, container replacement, pod replacement, host reboot, workflow pause, configuration restoration, instruction restoration, remediation time, repeated destination, repeated action, repeated identity use, repeated sensitive-data access, repeated transfer, repeated persistent change, file reappearance, permission recurrence, and event timestamp.

Useful Log Sources

·        Agent-platform logs

·        Browser and endpoint telemetry

·        Container and orchestration telemetry

·        Identity and token logs

·        Connector-management logs

·        SaaS audit logs

·        SIEM correlation

·        NDR recurrence analytics

·        Incident-response records

Detection Use

These artifacts support detection when unauthorized agent, identity, transfer, network, or persistent behavior recurs after attempted containment or remediation.

Investigation Use

Investigators should reconstruct continuity through durable agent, application, identity, connector, object, destination, policy, resource, and task relationships when session or process identifiers change.

Non-Coverage Conditions

A restart alone is not sufficient.

A repeated action alone is not sufficient.

Approved scheduled workflows may recur.

Workload replacement may break process and local-file continuity.

Approved-Workflow, Deployment, Administration, Testing, and Incident-Response Artifacts

Relevant Artifacts

Administrator identity, privileged-access session, administrative workstation, deployment pipeline, model update, instruction update, agent release, connector update, workflow update, application onboarding, identity-governance event, backup job, migration job, synchronization job, evaluation, red-team exercise, security test, incident-response case, maintenance period, change ticket, approval record, rollback, restoration, script execution, and event timestamp.

Useful Log Sources

·        Change-management systems

·        CI/CD platforms

·        Agent-administration platforms

·        Connector-management systems

·        Privileged-access systems

·        Identity-governance systems

·        Security-testing platforms

·        Incident-response systems

·        SIEM correlation

Detection Use

These artifacts support false-positive reduction and distinguish approved deployment, administration, testing, synchronization, migration, recovery, and incident response from unauthorized activity.

Non-Coverage Conditions

Administrator activity alone is not sufficient.

A trusted deployment platform alone is not sufficient.

Broad suppression based on identity, application, signer, tool, platform, or time window is not appropriate.

AWS Identity, Data-Access, and Transfer Artifacts

Relevant Artifacts

AWS account, Region, principal ARN, user identity, assumed role, session issuer, source identity, access key, service role, workload identity, CloudTrail event name, event source, event category, management event, data event, IAM role, policy, trust policy, permission boundary, access-key creation, STS action, S3 bucket, S3 object, object sensitivity, destination account, destination bucket, external principal, network destination, source IP, VPC, flow record, approval, change ticket, resource identifier, and event timestamp.

Detection Use

These artifacts support detection of unauthorized agent-associated IAM or persistent-access changes and sensitive AWS-hosted data followed by external or unapproved transfer.

Non-Coverage Conditions

One CloudTrail event does not prove malicious activity.

IAM and S3 operations may result from approved infrastructure automation.

Coverage depends on complete management and data-event logging, accurate agent-principal mapping, data classification, approved changes, and approved data flows.

Microsoft Entra, Azure, SaaS, DLP, and Transfer Artifacts

Relevant Artifacts

Tenant ID, subscription ID, resource group, resource ID, user, application, service principal, managed identity, credential, federated credential, OAuth grant, application consent, delegated permission, application permission, directory role, Azure RBAC assignment, custom role, conditional-access result, policy result, denial, subsequent action, Microsoft SaaS object, recipient, destination, external-sharing state, cross-tenant state, DLP result, approval, task identifier, system alert ID, Sentinel result, and event timestamp.

Detection Use

These artifacts support detection of unauthorized agent-associated identity or permission changes, sensitive-data transfer, and denied actions followed by successful alternate execution.

Non-Coverage Conditions

One Entra, Azure Activity, DLP, or SaaS event does not prove trust injection.

Approved administration, onboarding, application deployment, and collaboration may create similar events.

Coverage depends on complete logging, accurate agent-application mapping, approval context, approved data flows, and reliable resulting-state evidence.

Google Cloud Identity, Data-Access, and Transfer Artifacts

Relevant Artifacts

Organization, folder, project ID, principal, service account, service-account key, IAM policy, role binding, custom role, workload-identity relationship, external federation, organization policy, service-account impersonation, Cloud Audit Logs event, Data Access event, Cloud Storage bucket, object, object sensitivity, public state, external principal, destination project, API, repository, network destination, Sensitive Data Protection result, approval, change ticket, resource identifier, and event timestamp.

Detection Use

These artifacts support detection of unauthorized agent-associated IAM or persistent-access changes and sensitive GCP-hosted data followed by external or unapproved transfer.

Non-Coverage Conditions

One IAM, Cloud Audit Logs, storage, DLP, or network event does not prove malicious activity.

Approved infrastructure automation may create similar changes.

Coverage depends on Data Access logging, accurate agent-principal mapping, data classification, approved-change records, and approved data flows.

YARA Artifact Disposition

YARA has no deployable primary-rule artifact set for this EXP report.

YARA is not viable as a primary artifact model because the report’s detection surface is behavioral, agent-context based, tool and connector based, SaaS-action based, approval and policy based, identity and permission based, process-execution based, network-correlation based, cloud-audit based, and SIEM-correlation based rather than dependent on stable malicious file content.

YARA may become useful only if a confirmed malicious script, loader, encoded payload, browser artifact, agent plugin, connector package, configuration structure, persistence component, archive, memory artifact, or reusable malware family is recovered and independently linked to the incident.

Final YARA Outcome

No YARA rules survive.

S28 — Detection Strategy and SOC Implementation Guidance

Figure 5

Purpose

This section provides implementation guidance for operationalizing the S25 rule set and S26 traceability model across NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA, YARA, AWS, Azure, GCP, enterprise-agent platforms, AI gateways, identity, SaaS, endpoint, network, SIEM, SOAR, cloud, data-security, and incident-response environments.

The detection strategy is sequence-based. It prioritizes correlated behavior over single-event alerting and avoids treating one prompt phrase, classifier result, model response, plan change, tool call, approval event, denial, SaaS action, sensitive-data access, process, file, network connection, cloud identity event, DLP result, actor name, campaign name, malware family, or static indicator as proof of compromise.

Implementation Strategy

Deploy the detection model in layered stages:

·        Enterprise AI-agent, model, owner, business-purpose, environment, criticality, identity, tool, connector, data-source, and downstream-SaaS inventory first

·        Normal task types, content sources, tool sequences, connector combinations, recipients, destinations, data volumes, and action frequencies second

·        System, developer, user, retrieved-content, tool-result, behavior-changing memory, policy, and output-context telemetry third

·        Task, session, trace, plan, goal-change, step-sequence, retry, exception, and completion-state telemetry fourth

·        Tool-call, connector, normalized-argument, target-resource, recipient, destination, action, result, and error telemetry fifth

·        Human approval, policy, authorization, denial, exception, and final executed-parameter telemetry sixth

·        SaaS search, read, download, export, send, share, create, modify, delete, permission, configuration, workflow, identity, financial, and administrative telemetry seventh

·        Sensitive-data classification, DLP, information-protection, CASB, insider-risk, and transfer telemetry eighth

·        OAuth, application, service-principal, managed-identity, service-account, role, permission, token, consent, federation, and persistent-access telemetry ninth

·        Browser, local-agent, automation-worker, code-interpreter, orchestration, process ancestry, command-line, file, and network telemetry tenth

·        Credential, token, secret, browser-session, environment, source-control, cloud-configuration, and sensitive-resource context eleventh

·        Persistent instruction, behavior-changing memory, knowledge-base, vector-store, workflow, automation, connector, template, policy, and configuration context twelfth

·        Multi-agent handoff, transferred-context, source-agent, destination-agent, and resulting-action context thirteenth

·        Cleanup, audit impairment, misleading completion, restart, session reset, connector revocation, remediation, and recurrence context fourteenth

·        Approved deployment, administration, synchronization, migration, backup, evaluation, testing, red teaming, maintenance, and incident-response context fifteenth

·        AWS, Azure, and GCP identity, data-access, cloud-audit, application, transfer, and network context sixteenth

·        Alert promotion only after telemetry validation, false-positive baselining, suppression governance, query testing, triage-playbook alignment, and ownership assignment

Telemetry Normalization Requirements

Implementation requires normalized entity and time correlation across agent, model, content, task, trace, plan, tool, connector, approval, policy, identity, SaaS, data, process, file, network, cloud, change-management, SOAR, incident-response, and SIEM telemetry.

Minimum Normalization Requirements

·        Agent ID

·        Agent name

·        Agent owner

·        Agent business purpose

·        Agent criticality

·        Model provider

·        Model name

·        Model version

·        Agent version

·        Instruction version

·        Policy version

·        Runtime

·        Framework

·        Deployment environment

·        Task ID

·        Session ID

·        Trace ID

·        Run ID

·        Initiating user

·        Agent identity

·        Application identity

·        Connector identity

·        Service principal

·        Managed identity

·        Service account

·        Workload identity

·        Source content type

·        Source object ID

·        Source owner

·        Source tenant

·        Source location

·        Trust classification

·        External-control state

·        Content hash

·        Retrieval query

·        Retrieval rank

·        Retrieved chunk ID

·        Initial objective

·        Initial task type

·        Initial recipient

·        Initial destination

·        Initial data scope

·        Plan version

·        Goal-change state

·        Tool name

·        Connector name

·        Function

·        Original arguments

·        Normalized arguments

·        Target resource

·        Target object ID

·        Action type

·        Action result

·        Error category

·        Retry state

·        Approval ID

·        Approving user

·        Reviewed action

·        Reviewed parameters

·        Executed action

·        Executed parameters

·        Reviewed recipient

·        Executed recipient

·        Reviewed destination

·        Executed destination

·        Reviewed identity

·        Executed identity

·        Policy ID

·        Policy result

·        Authorization result

·        Denial reason

·        Exception state

·        SaaS platform

·        SaaS tenant

·        SaaS object type

·        SaaS object ID

·        SaaS action

·        Resulting state

·        Data classification

·        Sensitivity label

·        Source data object

·        Transfer action

·        Transfer destination

·        Recipient

·        External-sharing state

·        Cross-tenant state

·        DLP result

·        CASB result

·        Insider-risk result

·        OAuth grant

·        Delegated permission

·        Application permission

·        Token type

·        Consent event

·        Role assignment

·        Policy change

·        Trust relationship

·        Federation state

·        Credential creation

·        Process name

·        Process path

·        Parent process

·        Grandparent process

·        Process ID

·        Process entity ID

·        Agent process-tree ID

·        Command line

·        User

·        User session

·        Working directory

·        Container ID

·        Pod ID

·        Workload ID

·        File name

·        File path

·        File operation

·        File hash

·        File first-seen time

·        Sensitive-resource category

·        Archive state

·        Encoding state

·        Compression state

·        Temporary-file state

·        Destination IP

·        Destination domain

·        Destination port

·        Destination tenant

·        Protocol

·        Connection direction

·        Connection duration

·        Bytes sent

·        Bytes received

·        Destination first-seen state

·        Destination prevalence

·        Destination reputation

·        Destination category

·        Network behavior

·        Internal service role

·        Communication-after-task state

·        Persistent-change type

·        Memory object

·        Knowledge object

·        Workflow object

·        Connector configuration

·        Policy object

·        Approval-control object

·        Security-control object

·        Multi-agent source

·        Multi-agent destination

·        Transferred-context ID

·        Cleanup target

·        Audit-impairment type

·        Restart or reset type

·        Remediation time

·        Approved-workflow context

·        Approved-recipient state

·        Approved-destination state

·        Approved-data-flow state

·        Approved-fallback state

·        Change ticket

·        Deployment record

·        Incident-response case ID

·        AWS account and Region

·        AWS principal and role

·        AWS resource ID

·        Azure tenant and subscription

·        Azure application and service principal

·        Azure resource ID

·        GCP organization and project

·        GCP principal and service account

·        GCP resource ID

·        Event timestamp

·        Telemetry source

Correlation Requirements

Rules should use bounded correlation windows that reflect the relationship between untrusted-content processing, planning changes, tool use, approval, SaaS action, sensitive-data access, transfer, denial, alternate execution, identity expansion, endpoint execution, persistent change, cleanup, and recurrence.

Recommended Starting Windows

·        Untrusted-content processing to material task-plan or goal change within 5 to 15 minutes

·        Task-plan change to unexpected tool or connector selection within 15 minutes

·        Untrusted-content processing to high-impact tool request within 30 minutes

·        Tool request to SaaS execution or resulting-state change within 15 minutes

·        Approval review to final execution within the approved transaction lifetime

·        Approval-parameter comparison at execution time

·        Sensitive-data access to external or unapproved transfer within 15 to 60 minutes

·        Sensitive-resource access to staging activity within 15 minutes

·        Unexpected agent-associated process execution to file or network activity within 15 minutes

·        Connector or policy denial to alternate-path execution within 30 minutes

·        Denied action to consequential partial state change within 30 minutes

·        Identity, permission, application, consent, token, or role change within the responsible agent task or deployment window

·        Unauthorized persistent configuration change to recurring activity within 24 hours

·        Cross-connector sensitive-data movement within one task, trace, session, or locally validated asynchronous workflow window

·        Multi-agent handoff to consequential downstream action within 30 minutes

·        Suspicious activity to cleanup or audit impairment within 60 minutes

·        Suspicious behavior recurring after session reset, agent restart, connector revocation, token revocation, workload replacement, or remediation within 24 hours

·        Similar behavior across multiple agents, users, tenants, applications, or business units within 8 hours

·        Continued activity after containment, identity disablement, connector revocation, policy restoration, or configuration rollback within 24 hours

These windows should be tightened for interactive agents and extended only when task, trace, agent, connector, workflow, identity, SaaS object, process tree, cloud resource, SOAR, or incident-response continuity supports the extension.

Alert Promotion Guidance

Do not promote a hunt or correlation search into alert mode until:

·        Enterprise agents and owners are inventoried

·        Agent business purpose and criticality are defined

·        Models, versions, runtimes, frameworks, and deployment environments are mapped

·        Agent users, identities, applications, service principals, service accounts, and workload identities are mapped

·        Approved tools, connectors, data sources, SaaS platforms, recipients, destinations, and action classes are documented

·        Normal task types and tool sequences are baselined

·        System, developer, user, retrieved-content, tool-result, memory, policy, and output contexts can be distinguished

·        Prompt and retrieved-content retention limitations are understood

·        Content provenance and trust classifications are validated

·        Task, session, trace, plan, step, and goal-change fields are validated

·        Tool calls retain normalized arguments, targets, recipients, destinations, results, and errors

·        Proposed, blocked, approved, partially completed, and executed actions can be distinguished

·        Approval systems preserve the exact reviewed parameters

·        Final executed parameters can be compared with approved parameters

·        SaaS audit logs capture the required read, export, send, share, modify, delete, permission, configuration, workflow, and identity events

·        Human and agent actions can be distinguished where possible

·        Sensitive-data classifications and DLP mappings are validated

·        Approved source-to-destination and connector-to-connector data flows are documented

·        OAuth grants, scopes, tokens, consents, applications, service principals, roles, permissions, and federation events are visible

·        Enterprise AI-agent processes and workloads are mapped

·        Process ancestry, command-line, sensitive-resource, file, and network fields are validated

·        Agent process-tree identifiers are available or locally normalized

·        Approved child processes, scripts, tools, paths, and automation are documented

·        Approved external destinations and internal dependencies are mapped

·        Persistent instruction, memory, knowledge, workflow, policy, template, automation, and connector changes are versioned and audited

·        Multi-agent handoff telemetry preserves provenance

·        Restart, session reset, connector revocation, token revocation, workload replacement, remediation, and recurrence can be reconstructed

·        AWS CloudTrail management and data events are enabled where applicable

·        Microsoft Entra ID, Azure Activity, Microsoft SaaS audit, and DLP events are retained where applicable

·        Google Cloud Audit Logs and Data Access events are enabled where applicable

·        Cloud principal and resource mappings are accurate

·        Query performance, alert volume, severity, routing, enrichment, ownership, and triage guidance are tested

False-Positive Control

False-positive control should use agent-specific task baselines, approved content sources, approved tool and connector combinations, expected action classes, approved recipients, approved destinations, approved data flows, approval records, policy decisions, identity inventories, SaaS object mappings, process baselines, destination inventories, change records, deployment records, testing windows, cloud-resource inventories, and incident-response cases.

Common False-Positive Sources

·        Legitimate external-content processing

·        Approved document summarization

·        Approved email and message processing

·        Search and retrieval systems

·        Knowledge-base ingestion

·        Public or shared content analysis

·        Approved cross-connector workflows

·        Reporting and analytics

·        Synchronization

·        Migration

·        Backup and restoration

·        Customer-support automation

·        Case-management automation

·        Ticket enrichment

·        Repository automation

·        CI/CD activity

·        Code generation and testing

·        Browser automation

·        Computer-use agents

·        Data-science workflows

·        Security testing

·        Red-team exercises

·        Model evaluation

·        Agent evaluation

·        Incident response

·        Administrative automation

·        Identity onboarding

·        Application deployment

·        Credential rotation

·        OAuth consent administration

·        Role and permission management

·        Infrastructure-as-code

·        Data-loss prevention testing

·        Approved external sharing

·        Approved customer communication

·        Approved financial or procurement workflows

·        Approved human-resources workflows

·        Approved security operations

·        Cloud-service agents

·        Monitoring and health checks

·        Token refresh

·        Connector retry

·        Queue recovery

·        Regional failover

·        Workflow resilience

·        Model update

·        Instruction update

·        Connector update

·        Policy update

·        Emergency containment or remediation

Triage Guidance

Initial triage should determine whether suspicious activity forms a coherent content-to-plan-to-tool-to-action sequence rather than a single-event anomaly.

Triage Questions

·        Which enterprise agent, model, version, runtime, framework, and owner were involved

·        What was the initiating user request

·        What was the agent’s approved business purpose

·        Which external or user-editable content entered the agent context

·        What was the source, owner, tenant, and trust classification of the content

·        Did the content contain role claims, policy claims, false approval, secrecy, concealment, tool directives, or instructions inconsistent with the task

·        Did the agent’s task plan, goal, recipients, destinations, data scope, tool selection, or connector sequence change after processing the content

·        Did a read-only or analytical task transition into a write, send, share, delete, financial, identity, deployment, security, or administrative action

·        Which tool or connector was selected

·        Were the tool arguments derived from the user request, an approved configuration, or untrusted content

·        Was the tool or connector required by the initiating task

·        Did the action exceed the expected resource, data, recipient, destination, tenant, or privilege scope

·        Was human approval required

·        Who approved the action

·        What exact action and parameters were reviewed

·        Did the final executed parameters differ from the reviewed parameters

·        Was the action blocked, denied, modified, canceled, or allowed to expire

·        Did the agent retry the action using another tool, connector, identity, browser, API, application, tenant, or workflow

·        Did an alternate path create a consequential partial or complete state change

·        Which SaaS platform and object were affected

·        Did a message, share, file, permission, user, role, workflow, application, financial object, deployment, or security control change

·        Did the agent access sensitive or privileged data

·        Was the sensitive access required by the task

·        Was the information transferred through another connector, recipient, tenant, API, repository, webhook, application, or network destination

·        Can the accessed data and transferred content be linked

·        Did DLP, CASB, information protection, insider-risk, or data-security controls detect or block the action

·        Did the agent request broader OAuth scopes, permissions, consent, tokens, roles, or delegated authority

·        Were new identities, service principals, managed identities, service accounts, credentials, keys, federation, or impersonation rights created

·        Did an agent-associated process launch a command shell, interpreter, downloader, deployment tool, package manager, source-control client, credential utility, remote-access tool, or administrative program

·        Did the process access credentials, tokens, browser sessions, environment files, cloud credentials, source-control credentials, SSH material, or service-account files

·        Did staging, archive creation, encoding, compression, temporary-file creation, script creation, or outbound communication follow

·        Did the workload communicate with a new, rare, direct-IP, prohibited, unmanaged, suspicious, or unexpected internal destination

·        Did communication continue after the task, user session, or connector session ended

·        Were persistent instructions, behavior-changing memory, knowledge entries, workflows, templates, policies, automations, connectors, or approval controls changed

·        Did the same behavior recur in later sessions or affect additional users, agents, tenants, repositories, mailboxes, or business units

·        Was contaminated context transferred to another agent or workflow

·        Were prompts, tool calls, messages, files, audit events, histories, or persistent changes deleted or altered

·        Did the agent’s final response omit or contradict material tool or SaaS activity

·        Did behavior recur after agent restart, session reset, connector revocation, token revocation, workload replacement, configuration restoration, or remediation

·        Is the activity explained by approved deployment, administration, synchronization, migration, testing, evaluation, red teaming, maintenance, or incident response

Escalation Guidance

Escalate when multiple behavior classes align in sequence, especially when untrusted content is followed by a material plan change, unexpected tool selection, sensitive-data access, unauthorized high-impact action, alternate-path execution, identity expansion, persistent change, endpoint execution, external transfer, cleanup, or recurrence.

Higher-Priority Escalation Conditions

·        Untrusted content contains instructions inconsistent with the initiating task

·        The content falsely claims system, developer, administrator, legal, compliance, security, or approval authority

·        The agent’s task plan or objective changes materially after processing the content

·        A read-only task transitions into a high-impact action

·        Tool parameters contain recipients, destinations, resources, or actions originating from untrusted content

·        A high-impact action occurs without valid approval

·        Final executed parameters differ from approved parameters

·        A denied action is completed through another tool, connector, identity, tenant, API, browser, or workflow

·        A multi-step workflow creates consequential state before a later control blocks completion

·        Sensitive-data access is followed by an external or unapproved transfer

·        Data moves from one connector through another without an approved workflow

·        A new OAuth grant, token, credential, role, consent, federation, or persistent-access path appears during the task

·        An agent-associated process launches a command, script, downloader, deployment tool, or administrative utility outside the approved workflow

·        Sensitive-resource access is followed by archive creation, staging, encoding, compression, or outbound communication

·        The agent workload contacts a new, rare, direct-IP, prohibited, unmanaged, suspicious, or role-inconsistent destination

·        Persistent instructions, memory, workflow, policy, connector, approval, logging, or security-control settings change without approval

·        Unauthorized behavior recurs across later sessions, users, agents, identities, or SaaS platforms

·        Contaminated context propagates to another agent that performs the consequential action

·        Logs, history, messages, files, audit evidence, or persistent artifacts are removed after suspicious activity

·        The agent falsely reports that no action occurred or that approval was obtained

·        Similar activity appears across multiple agents, users, tenants, repositories, mailboxes, or business units

·        Multiple systems independently show aligned content, tool, SaaS, identity, endpoint, network, and resulting-state behavior

Deployment Guardrails

Do not deploy these detections as fully automated blocking, isolation, identity disabling, token revocation, application deletion, workflow rollback, file deletion, SaaS-object deletion, or cloud-resource destruction logic without local validation.

Do not treat one prompt phrase, classifier result, unusual response, plan change, tool call, approval event, denial, SaaS action, sensitive-data access, child process, archive, outbound connection, rare destination, cloud identity change, DLP result, or static indicator as proof of compromise.

Do not attribute prompt-only, tool-only, SaaS-only, identity-only, endpoint-only, network-only, cloud-only, or single-event anomalies to successful trust injection, confirmed data exposure, persistent compromise, actor activity, or campaign activity without reliable lineage.

Do not enable high-confidence alerting until platform-specific schemas, fields, agent mappings, identity mappings, connector mappings, task and trace identifiers, approval parameters, SaaS objects, data classifications, process mappings, cloud resources, enrichment sources, exception lists, false-positive baselines, query performance, triage readiness, and escalation criteria have been validated.

S29 — Detection Coverage Summary

Coverage Summary

The S25 detection set provides broad behavior-led coverage for abnormal enterprise AI-agent workload communication, unexpected command or automation execution, credential or sensitive-resource access followed by staging or outbound activity, unauthorized high-impact agent actions, sensitive-data access followed by external or unapproved transfer, denied agent activity followed by alternate execution, unauthorized identity and permission expansion, and unauthorized persistent configuration change.

Coverage is strongest when enterprise-agent inventories, content provenance, task and trace telemetry, tool-call records, approval parameters, SaaS audit logs, sensitive-data classifications, identity events, endpoint process and file telemetry, network telemetry, cloud audit logs, approved workflows, and SIEM correlation are normalized into bounded sequences.

The detection model intentionally avoids prompt-phrase-only conclusions, classifier-only conclusions, model-response-only conclusions, tool-call-only conclusions, approval-event-only conclusions, SaaS-action-only conclusions, process-name-only matching, rare-destination-only matching, cloud-event-only conclusions, actor names, campaign names, malware-family names, and other single-event conclusions.

Strong Coverage Areas

·        Abnormal communication from mapped enterprise AI-agent workloads

·        New, rare, suspicious, direct-IP, prohibited, unmanaged, or role-inconsistent destinations

·        Unexpected internal service access inconsistent with the agent dependency map

·        Unexpected command or automation execution from agent-associated processes

·        High-risk child processes with supporting command-line, file, credential, or network behavior

·        Sensitive-resource access followed by staging, archive creation, encoding, compression, or outbound activity

·        High-impact agent actions without valid approval

·        Material differences between reviewed and executed parameters

·        Sensitive-data access followed by external or unapproved transfer

·        Cross-connector sensitive-data movement where source and destination provenance is retained

·        Denied activity followed by successful alternate execution

·        Unauthorized identity, permission, connector, role, consent, credential, federation, or persistent-access changes

·        Unauthorized persistent changes to instructions, behavior-changing memory, workflows, policies, templates, automations, or connector settings where audited

·        AWS agent-associated IAM and sensitive-data-transfer behavior

·        Azure agent-associated identity, transfer, and alternate-execution behavior

·        GCP agent-associated IAM and sensitive-data-transfer behavior

Moderate Coverage Areas

·        Trust-injection attempts where suspicious content is retained but task-plan influence is incomplete

·        Task-plan changes where the initiating content cannot be reconstructed

·        High-impact actions where approval context is partial

·        Sensitive-data transfer where content equivalence cannot be established

·        Cross-connector movement where data is transformed inside the agent context

·        Agent attribution where the connector records the human user

·        Process execution where browser or runtime ancestry is incomplete

·        Sensitive-resource access where memory, environment, or workload identity is involved

·        Persistent behavior where memory, workflow, policy, or connector telemetry is partial

·        Multi-agent propagation where transferred-context provenance is incomplete

·        Recurrence where task, session, process, or workload continuity is lost

·        SIGMA portability across backend products

·        Cloud identity and data-transfer behavior where principal or resource mappings are incomplete

Limited Coverage Areas

·        Trust injection when prompts and retrieved content are unavailable

·        Hidden, visual, encoded, fragmented, or multimodal instructions not preserved in logs

·        Successful instruction influence when task-plan and tool-selection telemetry is unavailable

·        Cloud-hosted actions performed without endpoint-visible execution

·        Browser and computer-use activity without structured action telemetry

·        Sensitive-data access performed entirely inside model or agent context

·        Data transformed, summarized, translated, encoded, compressed, embedded, or fragmented before transfer

·        Sensitive-data transfer through approved destinations or existing sessions

·        Actions performed under shared users, applications, service principals, or delegated sessions

·        Credential access through memory, inherited environment variables, workload identity, operating-system brokers, or secret services without visible file access

·        In-process execution without new process creation

·        Local, loopback, same-host, cloud-internal, or SaaS-to-SaaS activity outside monitored network paths

·        Persistent influence stored in unaudited memory, vector stores, shared documents, repositories, tickets, or SaaS objects

·        Multi-agent activity where provenance is lost between agents

·        Cleanup completed before forwarding

·        Activity delayed beyond retention or correlation windows

·        Cloud activity that produces no complete management, data-access, application, or network event

Non-Covered Areas

The S25 rule set does not directly prove:

·        That untrusted content altered an agent’s instructions

·        The exact malicious instruction followed

·        That a task-plan change resulted from trust injection

·        That a generated tool call executed

·        That a denied action reflected malicious intent

·        That a generic approval covered the final executed parameters

·        That accessed sensitive data was identical to transferred content

·        The exact data disclosed when content inspection is unavailable

·        That an identity or permission change resulted from trust injection

·        That an alternate path was malicious rather than legitimate resilience

·        That an unauthorized action resulted from trust injection rather than malicious user direction, excessive agency, or workflow error

·        That persistent influence originated from a specific content object when provenance is unavailable

·        Successful credential theft

·        Successful downstream compromise

·        Confirmed command-and-control operation

·        Destructive impact

·        Actor attribution

·        Campaign attribution

·        Malware-family attribution

·        Exploit-tool attribution

·        Abuse of a specific model, agent framework, connector, application, or SaaS platform when only generic behavior is observed

These outcomes require investigation, corroborating telemetry, forensic evidence, and incident-specific validation.

System Coverage Summary

NDR / Network Behavioral Analytics

NDR provides two primary behavioral rules for abnormal network activity from an enterprise AI-agent workload and sensitive enterprise data access followed by agent-associated external transfer.

NDR supplies strong evidence for new or unapproved destinations, unexpected internal dependencies, callback-like communication, payload-retrieval-like behavior, tunneling-like sessions, destination rotation, communication after task completion, and sensitive-access-to-transfer sequences.

NDR does not independently confirm trust injection, instruction influence, approval validity, exact transferred content, successful SaaS modification, identity change, or the original cause of the activity.

SentinelOne

SentinelOne provides two primary endpoint rules for unexpected command or automation execution from an enterprise AI-agent context and credential or sensitive-data access followed by staging or outbound activity.

Coverage includes Deep Visibility process, file, endpoint, network, parent-child, process-tree, command-line, hash, signer, path, sensitive-resource, and process-identifier context.

SentinelOne does not directly observe cloud-hosted prompt context, internal task planning, approval validity, or actions performed entirely through SaaS APIs without endpoint-visible consequences.

Splunk

Splunk provides three primary behavioral and correlation rules for high-impact agent action without valid approval, sensitive-data access followed by transfer through another connector or destination, and denied agent action followed by alternate-path or partial execution.

Coverage depends on reliable indexes, sourcetypes, normalized fields, enterprise-agent and identity inventories, task and session identifiers, tool and connector mappings, approval records, policy decisions, SaaS audit events, data classifications, approved data flows, approved fallback paths, and resulting-state evidence.

Elastic

Elastic provides three primary rules for unexpected execution from an enterprise AI-agent process or workload, sensitive-data access followed by agent-associated external transfer, and unauthorized agent-associated identity, permission, or persistent configuration change.

Coverage depends on ECS-compatible or locally consistent mappings, task and session identifiers, process and file telemetry, SaaS and identity events, data classifications, destination context, administrative-change mappings, temporal correlation, and approved exceptions.

QRadar

QRadar provides three primary CRE rules for unauthorized high-impact agent-associated action, agent-associated identity, permission, or connector expansion, and denied agent activity followed by successful alternate execution.

Coverage depends on DSM parsing, custom properties, agent and identity building blocks, action categories, approval and policy fields, identity and connector changes, denial and subsequent-success properties, reference sets, offense indexing, response limiters, and bounded temporal correlation.

SIGMA

SIGMA provides two portable rule families for unexpected command or automation execution from an enterprise AI-agent process and agent-associated sensitive-resource access followed by staging activity.

Production value depends on backend translation, local process and file mappings, normalized agent process-tree identifiers, compatible event sources, temporal correlation, agent scoping, exceptions, and approved-workflow handling.

YARA

YARA has zero deployable rules because no stable malicious script, loader, encoded payload, browser artifact, agent plugin, connector package, configuration structure, persistence artifact, archive, memory artifact, or reusable malware family is established.

AWS

AWS provides two supporting native rules for unauthorized agent-associated IAM, role, policy, or persistent-access change and agent-associated sensitive-data access followed by external or unapproved transfer.

AWS does not independently establish trust injection, malicious intent, exact content transfer, or account compromise from one CloudTrail, IAM, S3, workload, or network event.

Azure

Azure provides three supporting cloud rules for unauthorized agent-associated identity, application, role, or permission change, agent-associated sensitive-data access followed by external or unapproved transfer, and denied agent-associated action followed by successful alternate execution.

Azure does not independently establish trust injection, exact content transfer, or malicious intent from one identity, audit, DLP, transfer, or policy event.

GCP

GCP provides two supporting cloud rules for unauthorized agent-associated IAM, service-account, role, or persistent-access change and agent-associated sensitive-data access followed by external or unapproved transfer.

GCP does not independently establish trust injection, exact content transfer, or malicious intent from one IAM, audit, storage, DLP, workload, or network event.

Coverage Conclusion

The detection set provides strong practical coverage for observable enterprise behavior associated with abnormal agent workload communication, unexpected agent-associated execution, sensitive-resource access followed by staging, high-impact actions without valid approval, sensitive-data access followed by external transfer, alternate-path execution, identity and permission expansion, and persistent configuration change.

It is strongest when multiple telemetry classes align in sequence and weakest where trust injection, task-plan influence, SaaS action, sensitive-data movement, identity change, in-process execution, memory-only credential access, persistence, cleanup, or recurrence occurs without observable content, task, tool, approval, SaaS, identity, endpoint, network, cloud, or SIEM evidence.

S30 — Intelligence Maturity Assessment

Maturity Assessment Summary

The intelligence maturity level for this report is high for behavior-led detection strategy and moderate for direct trust-injection and compromise confirmation.

The detection model is mature because it focuses on durable behavioral relationships: untrusted-content exposure, material task-plan change, unexpected tool selection, unauthorized high-impact action, sensitive-data access and transfer, alternate-path execution, identity and permission expansion, endpoint execution, persistent agent changes, abnormal network communication, cleanup, and recurrence.

Direct compromise confirmation remains limited because enterprise telemetry may not expose complete prompt context, retrieved content, internal planning, exact tool-selection influence, content-to-action provenance, final executed parameters, cross-connector data lineage, browser and computer-use actions, memory-only credential access, or the original manipulation path directly.

Behavioral Intelligence Maturity

Behavioral maturity is high.

The report identifies repeatable behavior that can be detected across AI gateways, enterprise-agent runtimes, orchestration, retrieval, tool-call, approval, policy, identity, SaaS, data-security, endpoint, EDR, file, process, network, NDR, cloud, SIEM, SOAR, and incident-response telemetry.

The behaviors are durable across model providers, models, agent frameworks, prompt wording, languages, encodings, content types, source objects, tools, connectors, SaaS platforms, cloud providers, identities, process names, file paths, destinations, ports, protocols, campaign names, actor names, and action methods.

Strong Behavioral Anchors

·        Externally controlled or user-editable content containing agent-directed instructions

·        Material task-plan, goal, recipient, destination, data-scope, tool, or connector change after content processing

·        Transition from a read-oriented task to a high-impact action

·        Tool arguments derived from untrusted content rather than user intent or approved configuration

·        High-impact action without valid approval

·        Material difference between reviewed and executed parameters

·        Sensitive-data access followed by external or unapproved transfer

·        Cross-connector movement of sensitive data

·        Denied activity followed by successful alternate execution

·        Unauthorized creation or modification of identities, roles, permissions, credentials, consent, federation, or persistent access

·        Unexpected agent-associated command or automation execution

·        Sensitive-resource access followed by staging, archive creation, encoding, compression, or outbound activity

·        New, rare, prohibited, unmanaged, direct-IP, suspicious, or role-inconsistent agent-workload communication

·        Persistent changes to instructions, behavior-changing memory, workflows, policies, connectors, templates, automations, or approval controls

·        Propagation of contaminated context to another agent or workflow

·        Cleanup, audit impairment, misleading completion, or evidence removal

·        Recurrence after restart, session reset, connector revocation, identity disablement, configuration restoration, or remediation

·        Supporting AWS, Azure, and GCP identity, data-access, and transfer behavior

Telemetry Maturity

Telemetry maturity is moderate to high.

Agent, tool, approval, SaaS, identity, endpoint, network, cloud, data-security, and SIEM telemetry provide strong coverage where agent, task, trace, connector, identity, resource, process-tree, SaaS object, destination, approval, and timestamp fields are available and normalized.

Telemetry maturity decreases when prompt or retrieved-content logs are unavailable, task plans cannot be reconstructed, tool arguments are redacted, final approval parameters are not preserved, SaaS reads are not logged, agent and human actions share an identity, process ancestry is incomplete, or cloud data-access logging is disabled.

Prompt and Retrieved-Content Maturity

Prompt and retrieved-content maturity is moderate.

Maturity increases when system, developer, user, retrieved-content, tool-result, memory, policy, and output contexts can be distinguished and when content source, owner, tenant, trust classification, content object, and retrieval path are preserved.

Maturity decreases because privacy, legal, contractual, platform, and data-minimization requirements may limit retention and because hidden, visual, encoded, multilingual, fragmented, or multimodal instructions may not be accurately preserved.

Task-Plan and Tool-Selection Maturity

Task-plan and tool-selection maturity is moderate.

Agent-runtime and orchestration telemetry can identify plan changes, goal changes, tool selections, connector sequences, retries, exceptions, and completion states.

Maturity decreases when platforms record only executed tool calls, omit planning, retain only the final plan, or fail to preserve the relationship between retrieved content and tool parameters.

Approval and Policy Maturity

Approval and policy maturity is moderate to high where complete parameter binding exists.

Approval, policy, authorization, denial, modification, cancellation, and execution telemetry can identify missing approval, parameter drift, alternate execution, and partial completion.

Maturity decreases when approval records do not preserve the exact action, parameters, recipient, destination, resource, data scope, identity, and resulting execution.

SaaS and Autonomous-Action Maturity

SaaS and autonomous-action maturity is moderate to high.

SaaS audit logs can identify sends, shares, downloads, exports, modifications, deletions, permission changes, identity changes, workflow execution, deployments, financial actions, and administrative operations.

Maturity decreases when platforms omit reads, searches, previews, returned data, object identifiers, recipient details, or resulting state or when agent actions are indistinguishable from direct human actions.

Sensitive-Data and Transfer Maturity

Sensitive-data and transfer maturity is moderate to high.

Data classification, DLP, information protection, CASB, insider-risk, data-security posture, SaaS audit, and network telemetry can identify sensitive access and external or unapproved transfer.

Maturity decreases when content is transformed inside the agent context, data lineage is lost, transfer occurs between approved cloud services, or accessed and transferred content cannot be compared.

Identity and Permission Maturity

Identity and permission maturity is moderate to high.

Identity-provider, OAuth, application, cloud audit, role, permission, consent, token, federation, and service-account telemetry can identify agent-associated privilege expansion and durable access.

Maturity decreases when shared identities, nested groups, inherited roles, workload identities, service agents, deployment pipelines, and managed services obscure the effective authority or responsible agent.

Process and Execution Maturity

Process and execution maturity is moderate to high.

Endpoint platforms can identify suspicious child processes, command lines, process ancestry, process trees, users, paths, hashes, file activity, sensitive-resource access, and process-to-network relationships involving agent runtimes and automation components.

Maturity decreases when activity remains inside an existing browser or runtime, execution occurs only in a cloud-hosted service, process telemetry is absent, or approved interpreters and automation tools are abused.

File, Staging, and Credential-Resource Maturity

File and staging maturity is moderate.

File and process telemetry can identify credential or sensitive-resource access followed by archive creation, encoding, compression, collection, scripting, or transfer preparation.

Maturity decreases when secrets are inherited through environment variables, accessed in memory, obtained through workload identity, or transferred without local staging.

Network Maturity

Network maturity is high for abnormal agent-workload communication and moderate for compromise confirmation.

NDR, DNS, proxy, firewall, flow, endpoint-network, API-gateway, webhook, and TLS telemetry provide durable evidence for new, rare, direct-IP, prohibited, unmanaged, suspicious, long-lived, interactive, tunneling-like, payload-retrieval-like, destination-rotating, or role-inconsistent communication.

Network telemetry does not independently prove trust injection, task-plan manipulation, approval bypass, exact data disclosure, SaaS state change, or identity compromise.

Persistence Maturity

Persistence maturity is moderate.

Agent-administration, memory, knowledge, workflow, automation, repository, SaaS, identity, file, and configuration telemetry can identify persistent changes that affect later agent behavior.

Maturity decreases when persistence uses unaudited memory, vector stores, shared documents, tickets, downstream SaaS objects, external workflows, or delayed activation.

Multi-Agent Propagation Maturity

Multi-agent propagation maturity is moderate.

Orchestration, workflow, messaging, collaboration, ticket, repository, and knowledge-system telemetry can identify content or objectives passed between agents.

Maturity decreases when source-agent, destination-agent, transferred-context, and resulting-action provenance is not preserved.

Cleanup and Anti-Forensic Maturity

Cleanup maturity is moderate.

History deletion, tool-call deletion, message deletion, file deletion, audit impairment, log-forwarding interruption, memory alteration, and misleading completion can be detected when telemetry is protected and forwarded before evidence is lost.

Maturity decreases when logs remain local, forwarding is delayed, retention removes evidence, or legitimate privacy and maintenance activity is not baselined.

Restart and Recurrence Maturity

Restart and recurrence maturity is moderate to strong.

Repeated tool, SaaS, identity, transfer, process, network, persistent-change, or destination behavior after restart, session reset, connector revocation, workload replacement, or remediation provides durable evidence of continued compromise.

Maturity decreases when task, session, process, workload, object, or identity continuity is lost and the SIEM cannot reconstruct the sequence through durable identifiers.

Cloud Maturity

Cloud maturity is moderate.

AWS provides useful supporting identity and data-transfer behavior through CloudTrail, IAM, STS, S3, data events, and network telemetry.

Azure provides useful supporting identity, SaaS, data-transfer, denial, policy, and resulting-action behavior through Microsoft Entra ID, Azure Activity, Microsoft SaaS audit, DLP, and Sentinel.

GCP provides useful supporting IAM, service-account, data-access, storage, Sensitive Data Protection, application, and network behavior through Cloud Audit Logs and related telemetry.

Cloud platforms do not independently prove trust injection, exact content transfer, malicious intent, or agent compromise from one cloud event.

Adversary-Resilience Maturity

Adversary-resilience maturity is high for behavior-led detection and moderate for high-confidence trust-injection confirmation.

The detection model is resilient because it avoids brittle indicators and focuses on relationships an adversary may create when converting manipulated context into tool use, unauthorized SaaS action, data transfer, identity expansion, endpoint execution, persistence, cleanup, or downstream impact.

The model is less resilient when adversaries use low-noise instructions, approved tools, expected connectors, shared identities, approved destinations, existing sessions, in-process execution, memory-only activity, transformed data, delayed persistence, or telemetry-suppressed techniques.

Operationalization Maturity

Operationalization maturity is moderate.

The S25 rules are implementation-ready detection patterns, but production deployment requires local validation of schemas, indexes, sourcetypes, DSM fields, custom properties, ECS mappings, SentinelOne fields, agent inventories, identities, task and trace fields, tool-call arguments, approval parameters, SaaS objects, data classifications, process-tree identifiers, cloud principals, cloud resources, exception lists, false-positive baselines, query performance, triage logic, and alert routing.

Operational maturity increases when detection owners validate telemetry quality, maintain authoritative agent inventories, preserve content and task provenance, bind approvals to final parameters, map identities and connectors, normalize SaaS actions, classify sensitive data, map agent processes, baseline approved destinations and data flows, document approved workflows, and test realistic benign and suspicious sequences.

Attribution Maturity

Attribution maturity is low to moderate.

The rule set supports detection of behavior consistent with trust manipulation, task-plan influence, unauthorized tool use, sensitive-data transfer, alternate execution, identity expansion, endpoint execution, persistent agent change, cleanup, and recurrence.

It should not be used by itself to attribute activity to a specific adversary, campaign, exploit developer, infrastructure provider, malware family, model provider, agent framework, connector, application, or named threat group without external evidence and incident-specific validation.

Attribution requires corroborating evidence such as content reconstruction, prompt analysis, plan and trace analysis, tool-argument review, SaaS object analysis, identity history, process history, file analysis, memory analysis, network content, victimology, tradecraft, infrastructure, and external intelligence reporting.

Maturity Limitations

Primary Maturity Limitations

·        Limited retention of complete prompts and retrieved content

·        Limited distinction between system, developer, user, retrieved-content, tool-result, memory, policy, and output contexts

·        Variable content-source provenance and trust classification

·        Limited visibility into hidden, visual, encoded, fragmented, multilingual, or multimodal instructions

·        Limited task-plan and goal-change telemetry

·        Platforms that log only executed tool calls

·        Redacted or truncated tool-call arguments

·        Limited ability to compare reviewed and executed parameters

·        Variable SaaS read, search, preview, export, and resulting-state telemetry

·        Shared users, applications, connectors, service principals, and delegated identities

·        Variable sensitive-data classification and DLP coverage

·        Limited cross-connector data provenance

·        Data transformation inside the agent context

·        Variable OAuth, consent, token, role, permission, and federation telemetry

·        Limited attribution between cloud identity changes and agent tasks

·        Limited browser-automation and computer-use telemetry

·        Limited visibility into in-process or cloud-only execution

·        Variable process ancestry and agent process-tree identification

·        Variable sensitive-resource, environment, browser-session, and secret-store visibility

·        Limited network attribution through NAT, shared egress, proxies, service meshes, and managed connectors

·        Limited visibility into local, loopback, same-host, cloud-internal, and SaaS-to-SaaS communication

·        Variable auditing of memory, vector stores, knowledge bases, workflows, policies, templates, and connector settings

·        Limited multi-agent provenance

·        Variable cleanup and log-forwarding retention

·        Workload and process continuity loss across restart or replacement

·        Variable AWS, Azure, and GCP management and data-access logging

·        Variable cloud-principal and resource mappings

·        Variable approved-workflow, approved-recipient, approved-destination, approved-data-flow, and approved-fallback baselines

·        High false-positive potential when detections are deployed without local tuning

·        Limited direct evidence for actor, campaign, malware, exploit, model, framework, connector, or application attribution

Maturity Improvement Priorities

Priority Improvements

·        Maintain authoritative enterprise AI-agent and owner inventories

·        Record model providers, models, versions, runtimes, frameworks, instruction versions, policy versions, and deployment environments

·        Map users, applications, service principals, managed identities, service accounts, workload identities, connectors, tools, and downstream SaaS platforms

·        Define approved task types, content sources, tool sequences, connector combinations, recipients, destinations, data scopes, and action classes

·        Preserve prompt and retrieved-content provenance where legally permissible

·        Distinguish system, developer, user, retrieved-content, tool-result, memory, policy, and output contexts

·        Preserve task, session, trace, plan, step, goal-change, retry, exception, and completion-state telemetry

·        Preserve complete normalized tool-call arguments, target resources, recipients, destinations, results, and errors

·        Record proposed, blocked, approved, modified, partially completed, and executed actions separately

·        Bind approvals to the exact final action, parameters, recipient, destination, resource, data scope, identity, and expiration time

·        Preserve SaaS object identifiers and resulting state

·        Improve agent-versus-human action attribution

·        Enable SaaS read, search, preview, download, export, send, share, modify, delete, permission, configuration, workflow, identity, financial, and administrative telemetry

·        Improve sensitive-data classification and data-lineage visibility

·        Build approved source-to-destination and connector-to-connector data-flow inventories

·        Improve DLP, information-protection, CASB, insider-risk, and data-security telemetry

·        Improve OAuth, application, service-principal, consent, token, role, permission, federation, and credential telemetry

·        Map enterprise AI-agent processes, browsers, automation workers, code interpreters, orchestration components, containers, and workloads

·        Enable complete process ancestry, command-line, sensitive-resource, file, and process-to-network telemetry

·        Normalize agent process-tree identifiers

·        Build approved child-process, script, tool, path, and automation baselines

·        Improve NDR, DNS, proxy, firewall, flow, API-gateway, webhook, and TLS normalization

·        Build approved external-destination and internal-dependency inventories

·        Version and audit persistent instructions, behavior-changing memory, knowledge bases, vector stores, workflows, templates, policies, automations, and connector configurations

·        Preserve multi-agent source, destination, transferred-context, and resulting-action relationships

·        Forward agent, SaaS, identity, endpoint, network, cloud, policy, and approval logs to protected remote storage

·        Preserve restart, session reset, connector revocation, token revocation, workload replacement, restoration, and remediation events

·        Improve AWS CloudTrail management and data-event, IAM, STS, S3, principal, and resource mappings

·        Improve Microsoft Entra ID, Azure Activity, Microsoft SaaS audit, DLP, Sentinel, application, identity, and resource mappings

·        Improve Google Cloud Audit Logs, Data Access, IAM, service-account, storage, Sensitive Data Protection, principal, and resource mappings

·        Build approved-workflow baselines for deployment, administration, synchronization, migration, testing, evaluation, red teaming, maintenance, and incident response

·        Test detections against realistic benign and suspicious content-to-action sequences before alert promotion

Final Intelligence Maturity Assessment

The report’s intelligence maturity is strong for behavior-led detection engineering, strong for executive risk framing, moderate to strong for telemetry-driven operational detection, moderate to strong for agent, tool, approval, SaaS, identity, endpoint, process, network, data-security, cloud, and SIEM correlation, moderate for AWS, Azure, and GCP supporting identity and data-transfer detection, and low to moderate for direct trust-injection, exact content-to-action, exact data-disclosure, credential-theft, downstream-compromise, or attribution confirmation.

The S25 through S30 detection model is best used as an implementation-ready threat-to-detection framework that identifies suspicious content exposure, probable instruction influence, unexpected tool use, unauthorized high-impact action, sensitive-data movement, alternate-path execution, identity expansion, agent-associated endpoint behavior, persistent changes, cleanup, recurrence, and supporting cloud activity.

It should not be used as a standalone proof model for successful trust injection, exact instruction adherence, confirmed data theft, credential theft, persistent compromise, downstream compromise, destructive impact, or adversary attribution without corroborating telemetry, forensic evidence, and incident-specific validation.

S31 — Telemetry Dependencies

Enterprise AI Agent Trust Injection and Connected SaaS Autonomous Insider Risk requires telemetry capable of determining whether suspicious content exposure remained limited to ordinary agent processing, benign instruction-like language, approved automation, policy enforcement, malformed tool calls, excessive-agency failure, or unsuccessful manipulation, or progressed into material instruction influence, task-goal redirection, altered tool or connector use, authorization misuse, connected-SaaS access, unauthorized autonomous action, sensitive-data exposure, persistent influence, concealment, or downstream organizational impact.

The central dependency is the ability to correlate agent inventory, content provenance, instruction hierarchy, task planning, tool and connector activity, identity and OAuth use, approval, SaaS audit records, data movement, browser or runtime activity, persistent context, security-control changes, downstream effects, incident-response actions, and business impact into one content-to-agent-to-authorized-action investigation model.

Agent, Workflow, and Exposure Context

·        Asset telemetry must identify enterprise agents, copilots, autonomous workflows, browser agents, code agents, local agents, multi-agent systems, orchestration platforms, model gateways, retrieval systems, memory services, knowledge bases, automation workers, and supporting infrastructure.

·        Application telemetry must identify agent name, model, version, runtime, instructions, policies, owner, business purpose, criticality, users, identities, tools, connectors, data sources, approval requirements, and downstream platforms.

·        Exposure telemetry must identify which agents process externally controlled, public, shared, user-editable, partner-controlled, customer-submitted, compromised, or unverified content.

·        Required fields include agent identifier, workflow identifier, task identifier, session identifier, trace identifier, owner, environment, business criticality, regulated-data exposure, autonomy level, financial capability, identity-sensitive capability, security-sensitive capability, and administrative authority.

·        Historical agent, instruction, policy, connector, identity, permission, and workflow state must be retained because current configuration may not reflect conditions at the time of suspicious activity.

Content Provenance, Retrieval, and Instruction Telemetry

·        Retrieval telemetry must capture source object, source type, owner, tenant, URL or object identifier, trust classification, retrieval time, ranking, chunk lineage, citation, and relationship to the initiating task.

·        Content telemetry should identify direct instructions, false authority, policy impersonation, approval claims, hidden text, encoding, fragmentation, multilingual instructions, tool directives, recipient changes, destination changes, and machine-oriented content.

·        Agent telemetry must capture system, developer, user, retrieved-content, tool-result, policy, persistent-memory, and output context where legally and operationally permissible.

·        Required fields include instruction source, priority, version, policy version, content identifier, task, session, trace, timestamp, trust classification, and whether the content was treated as instruction or data.

·        This telemetry is required to determine whether suspicious content merely entered agent context or materially influenced behavior.

·        Suspicious language, classifier output, hidden text, or a low-trust source alone must not be used to prove successful instruction influence.

Task Planning and Agent-Decision Telemetry

·        Planning telemetry must capture the initial objective, generated plan, step sequence, revised plan, goal changes, tool selections, connector selections, retries, exceptions, cancellations, and completion state.

·        Required fields include task, session, trace, agent, model, plan version, step identifier, intended action, target system, data scope, recipient, destination, expected result, and timestamp.

·        Telemetry should identify transitions from read-oriented tasks into write-capable, externally communicative, destructive, financial, identity-sensitive, security-sensitive, or administrative operations.

·        Planning history should preserve rejected tools, blocked actions, alternate paths, parameter changes, and decomposition of one objective into smaller steps.

·        A revised plan is not inherently malicious because agents may legitimately adapt to new information.

Tool, Connector, and Execution Telemetry

·        Tool telemetry must capture tool, connector, function, normalized arguments, target resource, object identifier, recipient, destination, action, result, error, retry, policy decision, approval requirement, and timestamp.

·        Connector telemetry must identify owner, application identity, tenant, OAuth grant, scope, delegated permissions, service principal, service account, token, session, and downstream platform.

·        Telemetry should distinguish proposed, requested, denied, blocked, failed, partially completed, successful, rolled-back, and retried actions.

·        Cross-connector telemetry must preserve the relationship between information retrieved through one connector and data transmitted, modified, posted, uploaded, shared, summarized, or acted upon through another.

·        This telemetry is required to determine whether authorized tools were used in a manner inconsistent with the initiating task, user intent, policy, or approval.

·        A generated tool call does not prove execution or enterprise-state change.

Identity, OAuth, and Authorization Telemetry

·        Identity telemetry must capture users, service accounts, service principals, managed identities, OAuth applications, delegated sessions, connector identities, API keys, access tokens, refresh tokens, browser sessions, and shared automation accounts.

·        Required fields include identity, application, tenant, authentication method, device, session, token, grant type, scopes, privilege, source, target, result, timestamp, and approved workflow context.

·        OAuth telemetry should capture consent, scope request, scope expansion, token issuance, refresh, use, revocation, application creation, service-principal creation, and delegated-access changes.

·        Authorization telemetry must capture the action permitted, denied, modified, or escalated and the resource, data scope, recipient, destination, identity, and policy involved.

·        Telemetry should identify when human and agent activity share the same account, application, browser session, connector, or service identity.

·        Valid authentication or permitted API activity does not establish that the action was authorized for the task.

Approval and Policy-Enforcement Telemetry

·        Approval telemetry must capture the approving user, task, reviewed action, reviewed parameters, recipient, destination, resource, data scope, identity, expiration, decision, modification, cancellation, and resulting execution.

·        Required visibility includes the exact parameters shown to the approver and the exact parameters executed afterward.

·        Policy telemetry should capture allow, deny, modify, warn, require-approval, sanitize, redact, quarantine, or terminate decisions.

·        Reapproval must be recorded when material parameters change after review.

·        This telemetry is required to determine whether approval was attributable, informed, and bound to the final action.

·        A generic approval event must not validate materially different executed parameters.

Connected-SaaS, Data, and Resulting-State Telemetry

·        SaaS audit telemetry must capture search, preview, read, download, export, send, share, upload, create, modify, delete, permission, user, role, application, configuration, workflow, transaction, and administrative activity.

·        Required fields include user, agent, application, connector, tenant, object, old value, new value, recipient, destination, data classification, result, timestamp, and task linkage.

·        Data telemetry must identify source, object, classification, owner, tenant, sensitivity, operation, volume, returned data, transformation, destination, recipient, and business purpose where supported.

·        Data lineage should preserve relationships among retrieved information, generated output, tool-call parameters, and downstream destinations.

·        Historical state should be retained for high-value identities, permissions, SaaS objects, workflows, configurations, records, code, deployments, and transactions.

·        This telemetry is required to validate sensitive-data access, external communication, enterprise-state modification, identity change, financial activity, or security-control impairment.

·        Sensitive-data access alone must not be used to prove exposure without unauthorized transfer, sharing, modification, downstream use, or other consequential action.

Browser, Runtime, Endpoint, and Network Telemetry

·        Browser telemetry should capture profile, session, authenticated identity, URL, tenant, form submission, file upload, file download, clipboard use, navigation, and resulting user-interface state where supported.

·        Runtime telemetry must capture code interpretation, command execution, scripts, local tools, file operations, environment-variable access, credential access, browser-profile access, internal-service access, and cloud-metadata access.

·        Process and file telemetry must capture process lineage, command line, executable path, user, session, workload, file creation, modification, deletion, upload, download, permission change, and timestamp.

·        Network telemetry must capture source, destination, port, protocol, direction, bytes, duration, recurrence, domain, certificate, proxy chain, NAT context, firewall action, workload identity, application identity, and timestamp.

·        Required context includes the responsible agent, task, session, identity, connector, browser, process, workload, and resulting action.

·        This telemetry is required to investigate browser-mediated, local-execution, endpoint, cloud, internal-service, and network activity.

·        Absence of endpoint or network evidence must not be treated as proof that no unauthorized action occurred when the agent operated through cloud-hosted tools or SaaS connectors.

Persistent Context, Multi-Agent, and Workflow Telemetry

·        Telemetry must capture creation, modification, deletion, version, owner, source, approval, and use of saved instructions, behavior-changing memory, knowledge bases, vector stores, templates, rules, policies, workflows, shared documents, repositories, tickets, and connector settings.

·        Required fields include object identifier, old value, new value, actor, source content, originating agent, receiving agent, affected workflow, task, session, timestamp, approval, and recurrence.

·        Multi-agent systems should preserve provenance when instructions, data, summaries, tool results, and objectives pass between agents and workflows.

·        Telemetry should distinguish ordinary conversation retention from persistent content capable of altering later behavior.

·        This telemetry is required to determine whether influence survived session termination, content removal, agent restart, connector revocation, or remediation.

·        Memory or knowledge changes do not establish persistent compromise unless they create or support durable unauthorized influence or access.

Security-Control, Cleanup, and Evidence Telemetry

·        Security telemetry must capture changes to DLP, information-protection policies, conditional access, connector restrictions, approval requirements, logging, retention, SIEM forwarding, endpoint controls, cloud policies, repository protections, SaaS-security settings, allowlists, exclusions, and sensor health.

·        Cleanup telemetry must capture prompt deletion, message deletion, file deletion, record modification, session removal, history removal, log deletion, retention changes, audit disablement, connector removal, token revocation, object restoration, workload destruction, and timestamp alteration.

·        Required fields include object or control, old value, new value, actor, identity, application, agent, task, session, approval context, result, timestamp, and recovery state.

·        Incident-response records must capture evidence acquisition, agent suspension, connector isolation, token revocation, session termination, identity review, SaaS preservation, workflow rollback, persistent-context removal, downstream hunting, and closure rationale.

·        Response activity must be distinguishable from attacker-driven concealment or security-control impairment.

Change-Control and Business Context

·        Change-control telemetry must capture model changes, agent updates, instruction changes, policy changes, connector changes, OAuth changes, workflow changes, deployment, evaluation, red teaming, testing, migration, synchronization, maintenance, and incident-response actions.

·        Business context must identify agent owner, business-process owner, data owner, identity owner, connector owner, SaaS owner, criticality, regulated-data status, outage tolerance, recovery priority, customer dependency, workforce dependency, financial function, and downstream trust.

·        Approved workflows should identify expected users, agents, tasks, content sources, tools, connector sequences, identities, data types, recipients, destinations, actions, and approval requirements.

·        Remediation must not be considered complete until content provenance, planning, approval validity, identity use, connector activity, sensitive-data handling, SaaS state, persistent context, security controls, downstream activity, and post-remediation recurrence have been validated.

S32 — Detection Limitations

Detection of Enterprise AI Agent Trust Injection and Connected SaaS Autonomous Insider Risk is limited by whether the organization can reconstruct the relationship among adversarial-content exposure, instruction influence, task-goal redirection, tool and connector use, identity and authorization, approval, connected-SaaS access, sensitive-data handling, unauthorized autonomous action, persistent influence, concealment, and downstream impact.

Environments that rely only on prompt-injection classifiers, suspicious phrases, unusual model responses, isolated tool calls, SaaS anomalies, destination reputation, endpoint alerts, or analyst intuition will not have enough evidence for high-confidence trust-injection or impact determination.

Primary Limitations

·        Missing agent inventory may prevent identification of affected agents, models, workflows, owners, identities, tools, connectors, permissions, data sources, approvals, and downstream platforms.

·        Historical instructions, policies, models, scopes, identities, connectors, workflows, and persistent context may be unavailable.

·        Prompts and retrieved content may be redacted, sampled, truncated, unavailable, or retained only briefly.

·        Retrieval systems may not preserve exact source objects, chunk lineage, ranking, provenance, or trust classification.

·        Planning telemetry may omit goal changes, rejected actions, retries, alternate paths, or parameter changes.

·        Generated tool calls may be recorded without confirming execution.

·        Tool or connector logs may omit arguments, recipients, destinations, target objects, policy decisions, partial execution, rollback, or resulting state.

·        Human and agent actions may share identities, applications, connectors, browser sessions, or service accounts.

·        OAuth telemetry may not preserve task, content-source, approval, or agent context.

·        Approval systems may not preserve the exact parameters reviewed.

·        SaaS platforms may omit search, read, preview, returned-data, export, or historical-state details.

·        Data lineage may not connect source information to agent output or downstream transfer.

·        Cross-connector workflows may be legitimate and common.

·        Browser and computer-use agents may act without structured tool-call records.

·        Local agents may execute code or access credentials without complete process, file, or network telemetry.

·        Cloud-hosted agents may produce no organization-controlled endpoint evidence.

·        Shared egress, proxies, managed runtimes, and provider infrastructure may obscure attribution.

·        Persistent influence may exist entirely in memory, knowledge, workflows, tickets, repositories, shared documents, or SaaS objects.

·        Multi-agent systems may lose original provenance as context is summarized or transformed.

·        Downstream systems may not retain the originating agent, content, identity, task, connector, or session.

·        Cleanup may remove prompts, sessions, messages, logs, objects, tokens, browser state, or temporary artifacts.

·        Agent restart, connector revocation, workflow rollback, or content removal may eliminate evidence without reversing impact.

·        Short retention and poor timestamp synchronization may prevent sequence reconstruction.

·        Missing change-control, testing, deployment, maintenance, and incident-response records may prevent reliable false-positive control.

·        Organizations may over-rely on known injection phrases, classifier scores, model-safety findings, destination reputation, vendor reporting, or public demonstrations.

Detection Boundary

·        Processing externally controlled content is not proof of trust injection.

·        A classifier alert, hidden instruction, encoded text, authority claim, or unusual response is not proof that agent behavior changed.

·        A revised task plan is not automatically malicious.

·        A proposed or generated tool call is not proof of execution.

·        A denied final action does not prove earlier steps created no consequential state change.

·        A successful action is not automatically unauthorized when it aligns with explicit user intent and approved workflow.

·        Valid identity, OAuth, connector, API, or browser-session use is not proof that the action was authorized for the task.

·        A generic approval event is not proof that final parameters were reviewed.

·        Sensitive-data access is not proof of exposure without unauthorized transfer, sharing, modification, downstream use, or other consequential action.

·        Cross-connector activity is not automatically suspicious.

·        Repeated retries may result from schema mismatch, stale objects, expired tokens, rate limits, connector defects, service outages, or network failures.

·        Browser activity under a shared session is not automatically attributable to an agent.

·        Persistent memory or saved context is not automatically malicious.

·        Multi-agent communication is not proof of contaminated-context propagation.

·        Security-control changes, deletions, revocations, or restorations may occur during approved administration or incident response.

·        Unauthorized autonomous action may be confirmed even when the precise root cause cannot be distinguished among trust injection, malicious user direction, excessive agency, weak permissions, or workflow failure.

·        Compromise of one agent does not prove compromise of the model provider, framework, connector vendor, SaaS platform, or supply chain.

·        A zero-event result does not prove absence of compromise when telemetry was unavailable, sampled, filtered, delayed, redacted, overwritten, or deleted.

·        Detection logic must not depend on another CyberDax alert, DRI score, TCR score, or analyst conclusion.

·        High-confidence conclusions should require validated multi-signal correlation across content, planning, tools, identity, approval, SaaS state, data movement, persistent context, and downstream impact where applicable.

Operational Impact of Limitations

Detection coverage should be reduced, converted to hunt-only logic, or withheld when authoritative agent inventory, content provenance, planning history, normalized tool parameters, identity attribution, approval binding, SaaS audit records, resulting-state evidence, persistent-context history, downstream lineage, or bounded sequence correlation are unavailable or unreliable.

Suspicious activity may remain analytically important but unsuitable for high-confidence trust-injection, unauthorized-action, sensitive-data-exposure, persistent-compromise, or downstream-impact determination when the complete content-to-agent-to-authorized-action sequence cannot be validated.

S33 — Defensive Control & Hardening Improvements

Defensive improvement should focus on making agent authority, content provenance, instruction hierarchy, planning, tool and connector use, identity, approval, data movement, SaaS state, persistent context, and trust restoration measurable, governed, constrained, and recoverable.

The objective is not only to filter one prompt or block one tool call, but to prevent untrusted content from controlling authorized enterprise action, reduce available authority, preserve evidence, detect consequential state changes, limit downstream reach, and prove that affected agents and business processes can safely return to operation.

Agent Inventory and Risk Governance

·        Maintain complete inventory of agents, models, runtimes, workflows, owners, identities, tools, connectors, data sources, permissions, approval requirements, and downstream platforms.

·        Classify agents by autonomy, business criticality, data sensitivity, connector reach, financial capability, identity privilege, security capability, customer or workforce impact, and recovery complexity.

·        Assign accountable business and technical owners.

·        Identify which agents process externally controlled or unverified content.

·        Maintain periodic review, exception approval, remediation closure, and emergency-change documentation.

Instruction, Content, and Planning Hardening

·        Separate authoritative system and developer instructions from user requests, retrieved content, tool output, memory, and external data.

·        Treat retrieved content as untrusted unless a governed process explicitly elevates its authority.

·        Prevent retrieved content from directly changing role, tool policy, recipient restrictions, destination restrictions, confidentiality controls, or approval requirements.

·        Define permitted task types, tool sequences, data scopes, recipients, destinations, and completion criteria.

·        Detect and restrict task-goal changes that originate from untrusted content.

·        Preserve plan changes, rejected actions, retries, alternate paths, and completion state.

·        Test controls against false authority, hidden text, encoding, fragmentation, multilingual content, indirect goal manipulation, and multi-object instruction assembly.

Tool, Connector, Identity, and Approval Hardening

·        Maintain approved inventories of tools, connectors, APIs, browser capabilities, code environments, identities, OAuth applications, grants, scopes, tokens, and service accounts.

·        Classify functions as read-only, write-capable, externally communicative, destructive, financial, identity-sensitive, security-sensitive, privileged, or administrative.

·        Disable unused tools, connectors, applications, scopes, and capabilities.

·        Restrict tools and connectors by agent, task, tenant, resource, data classification, recipient, destination, and action.

·        Apply least privilege and use dedicated agent identities where feasible.

·        Avoid shared human and agent sessions, identities, connectors, and applications.

·        Bind approval to the exact final action, parameters, recipient, destination, resource, data scope, identity, and transaction context.

·        Require reapproval after material parameter changes.

·        Require independent policy enforcement for consequential actions.

·        Monitor parameter mutation, alternate-tool use, browser fallback, identity switching, and repeated retries after denial.

SaaS, Data, Browser, and Runtime Hardening

·        Restrict agents to required mailboxes, drives, repositories, customer platforms, financial systems, identity services, cloud resources, and security tools.

·        Separate read-only and write-capable access where feasible.

·        Apply DLP, data classification, recipient controls, destination controls, and cross-connector transfer restrictions.

·        Preserve lineage from retrieved data through transformation and downstream use.

·        Use isolated browser profiles and dedicated agent sessions.

·        Restrict browser agents to approved domains, tenants, functions, recipients, and destinations.

·        Isolate code execution and local agents in least-privileged environments with restricted filesystems, credentials, internal services, cloud metadata, and network access.

·        Require independent validation for identity changes, deployments, financial activity, security-control changes, and administrative operations.

Persistent Context and Multi-Agent Hardening

·        Treat saved instructions, behavior-changing memory, knowledge bases, vector stores, templates, workflows, rules, policies, repositories, tickets, and connector settings as governed production objects.

·        Version, approve, monitor, and protect behavior-changing persistent content.

·        Restrict who and what can modify persistent context.

·        Preserve provenance when agents delegate tasks or pass instructions, summaries, data, or tool results.

·        Reapply policy and approval at each consequential multi-agent boundary.

·        Maintain rollback and containment procedures for persistent context and multi-agent workflows.

Logging, Security-Control, and Evidence Hardening

·        Enable and validate agent, retrieval, planning, tool, connector, identity, approval, SaaS, browser, endpoint, network, and persistent-context telemetry.

·        Forward relevant logs to protected remote storage.

·        Preserve task, session, trace, content, retrieval, tool-call, approval, identity, connector, object, and resulting-state identifiers.

·        Protect logging, retention, DLP, approval controls, connector restrictions, SIEM forwarding, endpoint controls, and SaaS-security settings from agent modification.

·        Monitor audit interruption, history deletion, policy changes, evidence removal, and sensor-health degradation.

·        Preserve evidence before agent restart, connector revocation, workflow rollback, browser closure, workload replacement, or SaaS restoration.

Incident Response and Trust Restoration

·        Create response procedures for content exposure, suspected trust injection, probable instruction influence, attempted misuse, blocked action, partial completion, unauthorized action, sensitive-data exposure, persistent influence, concealment, and downstream impact.

·        Validate source content, agent, task, plan, tool, connector, identity, approval, SaaS object, browser activity, runtime activity, persistent context, and resulting state.

·        Prepare decision paths for agent suspension, connector isolation, token revocation, SaaS restoration, persistent-context rollback, downstream hunting, legal and compliance review, cyber-insurance coordination, communications planning, and executive reporting.

·        Treat confirmed activity as an agent, identity, data, SaaS, workflow, and enterprise-trust incident.

·        Require post-remediation validation that unauthorized identities, permissions, shares, records, workflows, code changes, transactions, persistent content, security-control changes, and downstream actions did not continue.

S34 — Defensive Control & Hardening Architecture

Figure 6

The defensive architecture should treat enterprise agents, content sources, instructions, task plans, tools, connectors, identities, approvals, SaaS platforms, data flows, browser and runtime capabilities, persistent context, downstream systems, and business dependencies as one governed enterprise-trust system rather than isolated prompt, model, tool-call, or SaaS events.

The architecture must connect inventory, content provenance, instruction governance, planning visibility, tool and identity control, approval enforcement, SaaS and data integrity, execution protection, persistent-context governance, detection correlation, incident containment, and executive trust restoration into one content-to-authorized-action assurance model.

Architecture Layer One — Agent Asset, Ownership, and Risk Governance

This layer establishes which agents, models, runtimes, workflows, tools, connectors, identities, data sources, approval controls, and downstream systems exist. It captures owner, purpose, autonomy, criticality, data sensitivity, financial capability, identity privilege, security capability, customer or workforce dependency, and recovery priority.

Architecture Layer Two — Content Provenance and Retrieval Governance

This layer determines which content sources may enter agent context and preserves source, owner, tenant, identifier, trust classification, retrieval path, ranking, chunk lineage, timestamp, and task relationship.

Architecture Layer Three — Instruction Hierarchy and Policy Enforcement

This layer separates authoritative instructions from untrusted data, prevents content-driven policy override, captures instruction and policy versions, and applies independent enforcement for consequential actions.

Architecture Layer Four — Task Planning and Behavioral Integrity

This layer determines whether objectives, plans, tool sequences, recipients, destinations, data scope, approval requirements, or completion criteria changed after content exposure. It captures initial and revised plans, rejected actions, retries, alternate paths, and completion state.

Architecture Layer Five — Tool, Connector, Identity, and Approval Governance

This layer governs which functions, connectors, identities, OAuth grants, scopes, tokens, and sessions may be used for each task. It captures normalized parameters, target resources, policy decisions, approval state, executed parameters, results, and errors.

Architecture Layer Six — Connected-SaaS and Enterprise-State Integrity

This layer determines whether messages, files, records, identities, permissions, applications, workflows, configurations, code, deployments, transactions, or security controls changed consistently with valid intent and approval.

Architecture Layer Seven — Data Access, Lineage, and Transfer Protection

This layer determines whether sensitive information was accessed within authorized scope and whether it was transformed, shared, transferred, or used downstream appropriately. It captures classification, source, volume, transformation, recipient, destination, policy decision, and business purpose.

Architecture Layer Eight — Browser, Runtime, Endpoint, and Network Integrity

This layer determines whether graphical interaction, code execution, file access, credential access, internal-service use, cloud-metadata access, or network communication occurred. It captures browser session, form actions, process lineage, files, commands, workloads, destinations, and resulting state.

Architecture Layer Nine — Persistent Context and Multi-Agent Provenance

This layer governs saved instructions, memory, knowledge sources, workflows, templates, policies, repositories, tickets, and connector settings and preserves provenance when information or objectives move between agents and workflows.

Architecture Layer Ten — Security-Control and Evidence Integrity

This layer determines whether approval controls, DLP, connector restrictions, logging, retention, SIEM forwarding, endpoint controls, cloud policies, SaaS-security settings, or audit records were impaired or removed.

Architecture Layer Eleven — SOC Correlation and False-Positive Control

This layer joins content, planning, tools, identity, approval, SaaS activity, data movement, execution, persistent context, downstream effects, change control, and incident response. It distinguishes adversarial influence from approved automation, direct human action, excessive agency, workflow failure, testing, deployment, maintenance, and response activity.

Architecture Layer Twelve — Incident Response and Executive Trust Workflow

This layer connects technical evidence to containment and business decisions. It captures incident classification, affected agents, identities, data, SaaS objects, business processes, containment, restoration, legal and compliance review, customer or workforce impact, executive reporting, and return-to-service approval.

Architecture Outcome

The architecture should enable the organization to answer seven questions:

·        Which content source, agent, task, plan, tool, connector, identity, approval, data set, SaaS object, persistent object, downstream system, owner, or remediation action was affected?

·        Did the activity align with explicit human intent, approved automation, administration, testing, deployment, maintenance, or incident response?

·        Did untrusted content materially alter agent planning, tool selection, authorization context, recipients, destinations, data scope, or completion criteria?

·        Did resulting activity create an unauthorized communication, state change, identity change, permission change, deployment, transaction, or security-control change?

·        Did sensitive-data exposure, persistent influence, concealment, multi-agent propagation, or downstream expansion occur?

·        Can the organization preserve evidence, suspend agents, isolate connectors, revoke authority, restore state, remove persistent influence, investigate downstream systems, and prevent recurrence?

·        Can leadership make defensible decisions about agent trust, identity integrity, SaaS integrity, data exposure, financial loss, customer or workforce impact, legal obligations, operational disruption, and return to service?

S35 — Defensive Control Mapping Matrix

Preventive Controls

·        Maintain authoritative inventories of agents, models, workflows, owners, identities, tools, connectors, permissions, data sources, approvals, persistent context, and downstream systems.

·        Separate authoritative instructions from retrieved content, tool output, external data, and memory.

·        Apply independent policy enforcement outside the model.

·        Restrict tools, connectors, identities, scopes, recipients, destinations, data categories, tenants, and actions.

·        Apply least privilege and dedicated agent identities where feasible.

·        Bind approval to final execution parameters and require reapproval after changes.

·        Restrict sensitive-data access and cross-connector transfer.

·        Isolate browser, code-execution, local-agent, and automation-worker environments.

·        Version and protect behavior-changing persistent context.

·        Preserve provenance across agent delegation and workflow chaining.

·        Protect logs, policies, approval controls, and SaaS-security settings.

·        Maintain tested emergency agent suspension, connector isolation, token revocation, egress restriction, workflow rollback, and hunting procedures.

Detective Controls

·        Monitor low-trust content entering agent context.

·        Detect false authority, policy impersonation, hidden instructions, encoding, fragmentation, and machine-targeted directives.

·        Detect material changes to goals, plans, tools, connectors, identities, recipients, destinations, data scope, or approval behavior.

·        Detect transitions from read-oriented tasks into consequential actions.

·        Detect tool parameters derived from untrusted content.

·        Detect unexpected tools, connectors, identities, tenants, recipients, destinations, and data sources.

·        Detect broader OAuth scopes, application consent, tokens, or delegated authority.

·        Detect sensitive-data access outside approved scope and cross-connector transfer.

·        Detect discrepancies between approved and executed parameters.

·        Detect unauthorized communication, modification, deletion, identity change, permission change, deployment, transaction, workflow action, and security-control change.

·        Detect partial completion before later denial.

·        Detect retries, alternate-tool use, browser fallback, code execution, identity switching, or task decomposition after denial.

·        Detect discrepancies between user-visible responses and actual activity.

·        Detect persistent-context changes and multi-agent propagation.

·        Detect security-control impairment, audit interruption, history deletion, and evidence removal.

·        Require multi-signal correlation before high-confidence trust-injection or impact determination.

Responsive Controls

·        Preserve content, plans, tool calls, approvals, identities, SaaS objects, browser evidence, endpoint evidence, network sessions, and persistent context.

·        Restrict or suspend affected agents and workflows when consequential impact cannot be ruled out.

·        Isolate connectors, applications, identities, browser sessions, runtimes, and automation workers.

·        Revoke or rotate tokens, sessions, API keys, OAuth grants, service accounts, and delegated permissions.

·        Remove or quarantine adversarial content and contaminated persistent context after preservation.

·        Restore altered messages, files, records, permissions, identities, workflows, code, deployments, transactions, policies, and security controls.

·        Hunt for related content, tasks, connectors, identities, recipients, destinations, SaaS changes, persistence, and downstream activity.

·        Investigate agents and workflows that received contaminated output.

·        Perform legal, privacy, compliance, cyber-insurance, communications, customer, workforce, executive, and board review where required.

·        Confirm that agent behavior, enterprise state, identity trust, data integrity, persistent context, security controls, and downstream systems support closure.

Governance Controls

·        Maintain approved inventories and ownership for agents, models, instructions, policies, tools, connectors, identities, OAuth grants, persistent context, workflows, and control owners.

·        Maintain approved workflows for content processing, communication, record modification, finance, identity administration, deployment, security operations, testing, and incident response.

·        Require change control for instructions, policies, connectors, scopes, identities, approval logic, persistent memory, workflows, browser capabilities, code execution, transfer rules, and logging.

·        Require periodic validation of inventory, authority, connector scope, approval binding, recipient restrictions, destination restrictions, persistent context, and recovery capability.

·        Maintain escalation criteria for exposure, suspected trust injection, probable influence, attempted misuse, blocked action, partial completion, unauthorized action, sensitive-data exposure, persistence, concealment, and downstream expansion.

·        Track unresolved inventory, provenance, planning, identity, approval, SaaS-audit, data-lineage, execution, persistence, retention, response, and recovery gaps in the risk register.

Control Mapping Summary

The strongest posture combines separation of trusted instructions from untrusted content, least-privileged agent authority, independent policy enforcement, approval bound to final parameters, detection of content-to-plan-to-tool-to-state sequences, sensitive-data protection, persistent-context governance, and response workflows that restore agent, identity, SaaS, data, workflow, and downstream trust.

S36 — CyberDax Intelligence Maturity Assessment

Current Intelligence Maturity

Moderate to High

Maturity Rationale

Enterprise AI Agent Trust Injection and Connected SaaS Autonomous Insider Risk forms a mature behavior-led intelligence model because it is not dependent on one prompt phrase, model, agent framework, tool, connector, platform, campaign, actor, recipient, destination, proof of concept, or indicator.

Organization-specific maturity varies because reliable implementation depends on authoritative agent inventory, content provenance, planning visibility, tool and connector attribution, identity and OAuth telemetry, approval binding, SaaS audit depth, data lineage, execution visibility, persistent-context history, downstream provenance, and resulting-state validation.

Strengths

·        The behavior remains durable across changing content sources, wording, languages, encodings, models, tools, identities, connectors, platforms, recipients, and execution methods.

·        The core sequence is clear: adversarial-content exposure, probable instruction influence, altered tool or authorization use, connected-SaaS activity, unauthorized autonomous action, and possible persistence or downstream impact.

·        Detection opportunities are strong where content, planning, tool, identity, approval, SaaS, data, execution, persistent-context, and downstream evidence can be correlated.

·        The outcome model distinguishes adversarial-content exposure, suspected trust injection, probable instruction influence, attempted tool misuse, blocked autonomous action, partially completed unauthorized action, unauthorized autonomous action, sensitive-data exposure, persistent compromise, and confirmed downstream organizational impact.

·        S25 provides behavior-led coverage across the required detection platforms according to implementation viability.

·        Defensive controls map directly to content provenance, instruction governance, agent authority, connector control, identity protection, approval binding, SaaS integrity, data security, execution isolation, persistent-context governance, and trust restoration.

Maturity Gaps

·        Agent inventories, ownership, permissions, tools, connectors, and downstream dependencies may be incomplete.

·        Historical instructions, models, policies, scopes, identities, workflows, and persistent context may be unavailable.

·        Content provenance, exact retrieved objects, chunk lineage, and ranking may not be preserved.

·        Planning history and tool parameters may be incomplete.

·        Agent and human activity may share identities, applications, sessions, or connectors.

·        Approval systems may not preserve final reviewed parameters.

·        SaaS platforms may omit read, preview, export, returned-data, or historical-state telemetry.

·        Data lineage may not connect source information to downstream use.

·        Browser and computer-use agents may lack structured execution records.

·        Cloud-hosted agents may provide limited endpoint or network evidence.

·        Persistent influence may exist in unmonitored memory, knowledge, workflows, repositories, tickets, or SaaS objects.

·        Multi-agent provenance may be lost as context is summarized or transformed.

·        Cleanup, short retention, and poor timestamp synchronization may prevent reconstruction.

·        Approved-workflow and change-control baselines may be insufficient.

·        Organizations may over-rely on classifiers, known phrases, isolated anomalies, vendor findings, or public demonstrations.

Maturity Improvement Priorities

·        Maintain authoritative inventories and historical configuration for agents, identities, connectors, instructions, policies, approvals, persistent context, and dependencies.

·        Preserve content provenance, task planning, normalized tool parameters, approval parameters, and resulting state.

·        Improve OAuth, identity, connector, SaaS, data-lineage, browser, runtime, and downstream attribution.

·        Bind approval to final execution.

·        Version and monitor persistent context.

·        Preserve provenance across multi-agent workflows.

·        Improve audit-integrity and evidence-removal monitoring.

·        Build approved-workflow baselines.

·        Test detection and response logic against benign, excessive-agency, malicious-user-directed, and trust-injection sequences.

Maturity Outlook

Maturity can improve quickly when the organization prioritizes authoritative inventory, content provenance, planning visibility, tool and identity attribution, approval binding, SaaS audit depth, data lineage, persistent-context governance, multi-agent provenance, and post-remediation validation.

The highest-value improvements are those that prove whether untrusted content altered behavior, whether enterprise authority was misused, whether consequential state changed, whether influence persisted or propagated, and whether trusted operation can be restored without relying on filtering, connector revocation, session termination, or agent restart alone.

S37 — Strategic Defensive Improvements

Strategic improvement should focus on reducing the probability that adversary-controlled content can influence authorized enterprise action and reducing the data, authority, and downstream access exposed if an agent is manipulated.

The organization should treat this threat as a cross-functional resilience problem spanning AI governance, enterprise architecture, identity, SaaS security, application security, cloud security, data protection, security operations, incident response, software development, finance, human resources, legal, privacy, compliance, cyber insurance, communications, business continuity, and executive governance.

Priority One — Establish Agent Risk-Tier and Ownership Governance

·        Classify agents by autonomy, content exposure, data sensitivity, connector reach, identity privilege, financial capability, security capability, customer or workforce impact, and recovery complexity.

·        Apply stronger controls to elevated-risk agents.

·        Require explicit ownership, authority boundaries, and trust-restoration criteria.

·        Reduce centralized management, connector, identity, and knowledge-source concentration that could affect broad agent populations.

Priority Two — Make Content Provenance and Instruction Separation Authoritative

·        Preserve source, owner, tenant, trust classification, retrieval path, timestamp, and task linkage.

·        Separate authoritative instructions from user-controlled, retrieved, shared, public, and external content.

·        Prevent low-trust content from changing role, policy, approval, confidentiality, recipients, destinations, or tool authority.

·        Test controls against false authority, hidden text, encoding, fragmentation, multilingual content, and indirect goal manipulation.

Priority Three — Reduce Agent Authority and Connector Reach

·        Limit each agent to required data sources, tools, actions, tenants, recipients, destinations, and business processes.

·        Separate read-only and write-capable functions.

·        Remove broad OAuth scopes, shared service identities, and unused connectors.

·        Use dedicated identities and rapid revocation capability for consequential workflows.

Priority Four — Bind Policy and Approval to Final Execution

·        Apply independent policy enforcement outside the model.

·        Bind approval to the exact final action, parameters, recipient, destination, resource, data scope, identity, and transaction context.

·        Require reapproval after material changes.

·        Prevent generic approval from authorizing alternate tools, identities, recipients, destinations, or data scope.

Priority Five — Build Content-to-Action Detection and Partial-Completion Visibility

·        Detect the durable sequence from adversarial content through plan change, altered tool or identity use, SaaS access, state change, persistence, and downstream impact.

·        Preserve content, task, plan, tool, connector, identity, approval, object, data, and resulting-state context.

·        Record each consequential step within multi-stage workflows.

·        Do not classify a workflow as fully blocked when earlier steps succeeded.

·        Maintain distinct outcomes for adversarial-content exposure, suspected trust injection, probable instruction influence, attempted tool misuse, blocked autonomous action, partially completed unauthorized action, unauthorized autonomous action, sensitive-data exposure, persistent compromise, and confirmed downstream organizational impact.

Priority Six — Control Cross-Connector Data Movement

·        Identify workflows where one connector retrieves sensitive information and another can transfer or act on it.

·        Apply classification, DLP, recipient, destination, tenant, webhook, repository, API, and storage controls.

·        Preserve lineage through summarization, transformation, encoding, translation, and fragmentation.

·        Require approval for unplanned sensitive-data movement.

Priority Seven — Constrain Browser, Computer-Use, and Code-Execution Capability

·        Prefer structured connectors with enforceable policy for consequential actions.

·        Restrict domains, tenants, uploads, downloads, clipboard use, local files, credentials, cloud metadata, internal services, and administrative interfaces.

·        Isolate code execution and local agents in least-privileged environments.

·        Require documented exceptions for privileged browser or runtime capability.

Priority Eight — Govern Persistent Context and Multi-Agent Provenance

·        Treat saved instructions, memory, knowledge sources, workflows, templates, rules, policies, repositories, tickets, and connector settings as governed production objects.

·        Version, approve, audit, and protect changes.

·        Preserve provenance when agents delegate tasks or exchange instructions, data, summaries, and tool results.

·        Reapply policy and approval at each consequential boundary.

·        Maintain rollback and containment procedures.

Priority Nine — Make Evidence Readiness Routine

·        Define when prompts, retrieved content, approvals, SaaS objects, browser evidence, endpoint data, tokens, and persistent-context exports must be preserved.

·        Preserve evidence before session deletion, connector revocation, agent restart, workflow rollback, browser closure, workload replacement, or SaaS restoration.

·        Track visibility gaps that could prevent influence or impact confirmation.

·        Maintain cross-platform identifiers and synchronized time.

Priority Ten — Make Suspension, Recovery, and Trust Restoration Routine

·        Predefine when agents, connectors, identities, workflows, browser sessions, runtimes, or business processes must be restricted or suspended.

·        Maintain tested procedures for evidence preservation, isolation, revocation, restoration, rollback, enterprise hunting, downstream investigation, and return to service.

·        Do not treat filtering, content removal, connector revocation, token rotation, session termination, or agent restart as sufficient restoration.

·        Validate agent behavior, identity state, SaaS objects, data integrity, approvals, persistent context, security controls, downstream systems, and recurrence.

Priority Eleven — Integrate Executive and Business Decisioning

·        Define escalation thresholds for regulated data, financial activity, identity administration, source code, deployment, security controls, customer communication, workforce processes, legal operations, cloud administration, and critical business services.

·        Maintain decision paths for agent suspension, connector isolation, identity revocation, SaaS restoration, manual operation, enterprise hunting, customer or workforce impact, legal review, privacy review, compliance review, cyber-insurance coordination, communications planning, and board reporting.

·        Track unresolved governance, visibility, authority, approval, persistence, response, and recovery gaps in the enterprise risk register.

·        Require leadership assurance before consequential autonomous operation resumes.

Strategic Outcome

The target state is an environment in which untrusted content is less likely to influence enterprise-agent behavior, authoritative instructions remain separated from data, agent authority is constrained, consequential actions require independently enforced policy and attributable approval, cross-connector data movement is governed, persistent context is controlled, multi-agent provenance is preserved, execution capabilities are restricted, unauthorized state changes are visible, evidence can be preserved, affected agents can be suspended rapidly, and leadership can make defensible decisions about agent trust, identity integrity, data exposure, SaaS integrity, financial risk, customer or workforce impact, legal obligations, operational disruption, and return to trusted autonomous operation.

S38 — Attack Economics & Organizational Impact Model

Figure 7

Enterprise AI Agent Trust Injection and Connected SaaS Autonomous Insider Risk changes intrusion economics by allowing an adversary to convert one content interaction into consequential activity performed through authorized enterprise identities, connectors, SaaS platforms, data stores, browser sessions, execution environments, persistent context, and downstream business processes.

The attacker may gain disproportionate value from one manipulated agent because the agent already possesses legitimate access, approved applications, valid OAuth grants, trusted identities, sanctioned connectors, existing sessions, sensitive data, and established relationships with connected systems. The adversary may therefore misuse the organization’s existing automation and delegated authority rather than separately compromising every platform involved.

When adversarial-content exposure, material instruction influence, task-goal redirection, altered tool or connector use, approval mismatch, sensitive-data access, unauthorized autonomous action, persistent influence, concealment, or downstream propagation align within one investigation window, organizational cost expands beyond the initiating content or affected agent.

Responders must determine what influenced the agent, how the task changed, which identities and permissions were used, what actions were executed, what data and enterprise objects were affected, whether influence persisted or propagated, and whether agent, identity, SaaS, data, workflow, and downstream trust can be restored safely.

Adversary Economic Advantage

·        One adversarial email, document, webpage, ticket, chat message, repository entry, API response, tool result, shared file, or knowledge object may influence an agent with access to multiple enterprise platforms.

·        The adversary may not need to exploit a software vulnerability, compromise the initiating user’s endpoint, obtain separate credentials, or deploy malware before influencing enterprise action.

·        Legitimate user identities, service accounts, service principals, managed identities, OAuth applications, connectors, APIs, and browser sessions may be used to perform the resulting activity.

·        Existing authorization may provide access to sensitive mailboxes, drives, repositories, customer platforms, financial systems, identity services, cloud resources, security tools, and administrative functions.

·        A low-risk task such as summarization, research, classification, document review, or customer support may be redirected into a higher-impact action.

·        Adversarial content may influence tool selection, recipients, destinations, data scope, action parameters, approval interpretation, or completion criteria without creating an obvious exploit event.

·        Cross-connector workflows may allow information retrieved from one trusted system to be transmitted, posted, uploaded, shared, modified, or acted upon through another.

·        Shared identities, pooled connectors, and valid applications may cause unauthorized behavior to appear technically compliant and may weaken attribution.

·        Browser, computer-use, code-execution, and local-agent capabilities may extend the agent’s reach into administrative interfaces, authenticated sessions, files, credentials, internal services, cloud metadata, and operating-system functions.

·        Broad OAuth scopes, delegated permissions, read-and-write capability, financial authority, identity-sensitive functions, source-control access, deployment capability, and security administration may concentrate multiple attack objectives within one agent.

·        Persistent memory, saved instructions, knowledge sources, workflows, templates, rules, tickets, repositories, and connector settings may allow one successful influence event to affect future sessions.

·        Multi-agent and connected-workflow environments may expand reach when contaminated instructions, data, summaries, objectives, or tool results pass to additional agents.

·        Repeated attempts after denial may use modified parameters, alternate tools, different connectors, browser automation, code execution, another identity, or smaller workflow steps.

·        Multi-step workflows may create consequential state before a later action is blocked.

·        Misleading completion reporting, continued workflow functionality, legitimate SaaS traffic, common cloud infrastructure, encryption, shared egress, and low-volume activity may reduce defender suspicion.

·        Security-control changes, audit impairment, history deletion, retention changes, and removal of initiating content may increase uncertainty while prior actions or downstream effects remain.

·        Agent restart, connector revocation, token rotation, workflow rollback, or content removal may create false confidence if copied data, altered identities, persistent context, or downstream changes remain.

·        One manipulated agent may provide data access, enterprise-state modification, identity abuse, financial capability, code or deployment access, security-control impairment, persistent influence, and downstream reach without separate compromise of every connected system.

·        The adversary benefits when defenders cannot rapidly distinguish trust injection from malicious user direction, excessive agency, ordinary workflow failure, approved automation, testing, deployment, maintenance, or incident response.

Defender Cost Expansion

·        The organization must investigate both the suspicious content and the reliability of the evidence needed to reconstruct the complete content-to-agent-to-authorized-action chain.

·        Response teams may need to review the initiating request, retrieved content, instruction sources, planning changes, tool selection, connector sequence, identity use, policy decisions, approvals, executed parameters, SaaS activity, and resulting enterprise state.

·        Investigators must determine whether suspicious content materially influenced behavior or merely produced a classifier alert, unusual response, denied action, malformed tool request, or non-impacting plan change.

·        Content and planning analysis may require comparison of source objects, initial and revised objectives, step sequences, tool choices, recipients, destinations, data scope, retries, alternate paths, and completion state.

·        Tool, connector, identity, and approval analysis may require validation of normalized parameters, target resources, results, policy decisions, OAuth grants, permissions, session use, reviewed parameters, executed parameters, and action outcomes.

·        SaaS and data analysis may require identification of searches, reads, exports, sends, shares, uploads, modifications, deletions, permission changes, identity changes, workflows, transactions, code changes, deployments, and security-control changes.

·        The organization may need to determine which customer, workforce, financial, legal, source-code, credential, secret, security, executive, operational, or regulated information was accessed or used.

·        Data tracing may be required across summarization, transformation, encoding, translation, compression, embedding, cross-connector transfer, and downstream use.

·        Browser, runtime, endpoint, and cloud analysis may be required when consequential activity occurred outside structured tool or connector telemetry.

·        Persistent-context and multi-agent analysis may be required when instructions, memory, knowledge, workflows, tickets, repositories, shared documents, summaries, objectives, or tool results influenced later sessions or additional agents.

·        Security teams may need to determine whether approval controls, DLP, connector restrictions, logging, retention, SIEM forwarding, endpoint controls, cloud policies, SaaS-security settings, or audit records were altered or impaired.

·        Cleanup analysis may require review of prompt deletion, message deletion, file deletion, record modification, session removal, history removal, log deletion, token revocation, connector removal, object restoration, and timestamp alteration.

·        Investigation cost increases when provenance, planning history, tool arguments, approval parameters, SaaS read events, data lineage, browser evidence, persistent-context versions, or downstream attribution are incomplete.

·        Scope expands when the affected agent supports finance, payroll, procurement, legal, human resources, customer operations, identity administration, security operations, source control, deployment, cloud administration, regulated data, or executive workflows.

·        Identity response may require suspension or rotation of OAuth grants, tokens, sessions, API keys, service accounts, service principals, managed identities, application credentials, browser sessions, certificates, and delegated permissions.

·        Operational disruption increases when agents, connectors, workflows, identities, browser sessions, code environments, or dependent business processes must be restricted or suspended.

·        Enterprise hunting may be required across related content, plans, tool calls, identities, recipients, destinations, SaaS actions, persistent modifications, and downstream systems.

·        Other agents and workflows may require review when they consumed output, context, instructions, data, or knowledge derived from the affected agent.

·        Restoration may require rollback of altered messages, shares, files, records, permissions, identities, applications, workflows, configurations, transactions, code, deployments, and security settings.

·        Restoration becomes more complex when legitimate and unauthorized activity occurred within the same workflow or time window.

·        Financial, source-control, deployment, identity, customer, workforce, legal, and security reviews may be required according to the affected business function.

·        Security teams may need to reassess prior SaaS, identity, cloud, endpoint, network, DLP, or insider-risk alerts when the affected agent operated through a trusted identity or application.

·        Business interruption may extend beyond the affected agent when critical workflows must be performed manually or suspended during investigation.

·        Evidence-preservation requirements may delay containment because agent restart, connector revocation, workflow rollback, browser closure, session deletion, workload replacement, or SaaS restoration can destroy critical evidence.

·        Legal, privacy, compliance, contractual, cyber-insurance, communications, customer, workforce, executive, and board-level costs increase when sensitive-data exposure, unauthorized financial activity, identity changes, persistent influence, security-control impairment, or downstream expansion cannot be ruled out.

·        Notification and regulatory analysis may be required even when impact remains uncertain because incomplete telemetry may prevent a definitive conclusion.

·        Post-remediation monitoring may need to continue across multiple agent, identity, connector, SaaS, workflow, and business-process lifecycles to confirm that unauthorized behavior does not recur.

Organizational Impact Model

Enterprise Agent, Workflow, and Content-Integrity Impact

The organization must determine which agents, models, runtimes, orchestration platforms, workflows, users, content sources, instruction sources, approval controls, business processes, owners, and downstream systems were exposed, influenced, modified, restricted, suspended, or included in remediation.

The organization must also determine whether suspicious activity remained limited to content exposure, classifier alerts, unusual responses, policy conflicts, denied actions, or ordinary planning changes, or progressed into material instruction influence, task-goal redirection, altered recipients, changed destinations, expanded data scope, unauthorized tool selection, or modified execution parameters.

Tool, Connector, Identity, Authorization, and Approval Impact

The organization must determine which tools, connectors, APIs, browser capabilities, code environments, users, service accounts, service principals, managed identities, applications, OAuth grants, scopes, tokens, sessions, API keys, permissions, and delegated-access relationships were used, requested, modified, blocked, revoked, or rendered unreliable.

The organization must determine whether consequential actions were explicitly requested, whether approval was attributable, whether the approver reviewed the final action and parameters, and whether execution matched the approved business purpose.

Connected-SaaS, Enterprise-State, Code, and Deployment Impact

The organization must determine which mailboxes, drives, collaboration systems, customer platforms, financial applications, human-resources systems, legal platforms, identity services, cloud resources, security tools, records, messages, files, users, groups, roles, applications, workflows, configurations, transactions, repositories, branches, commits, pipelines, packages, deployments, infrastructure, or customer-facing objects were accessed, created, modified, shared, deleted, published, or rendered unreliable.

Sensitive-Data and Data-Lineage Impact

The organization must determine which customer, workforce, financial, legal, source-code, credential, secret, security, executive, operational, or regulated information was searched, read, previewed, downloaded, exported, summarized, transformed, transmitted, uploaded, shared, modified, deleted, or used in downstream actions or decisions.

Browser, Runtime, Endpoint, and Cloud Impact

The organization must determine whether the agent used browser sessions, graphical interfaces, code interpreters, local runtimes, processes, filesystems, credentials, environment variables, internal services, cloud metadata, containers, workloads, or cloud APIs to perform or extend unauthorized activity beyond structured tools and connectors.

Persistent Context and Multi-Agent Impact

The organization must determine whether saved instructions, behavior-changing memory, knowledge bases, vector stores, workflows, templates, policies, rules, repositories, tickets, shared documents, connector settings, summaries, objectives, or tool results created durable influence or propagated into additional agents, users, workflows, tenants, or business units.

Financial and Transactional Impact

The organization must determine whether purchases, payments, refunds, invoices, payroll actions, procurement events, account changes, beneficiaries, transaction values, approvals, or financial records were initiated, altered, cancelled, completed, reversed, or rendered unreliable.

Security-Control and Evidence-Reliability Impact

The organization must determine whether DLP, information-protection policies, connector restrictions, approval controls, conditional access, logging, retention, SIEM forwarding, endpoint controls, cloud policies, repository protections, SaaS-security settings, audit records, prompts, sessions, messages, workflow histories, or incident-response evidence were altered, deleted, delayed, sampled, redacted, overwritten, or rendered unreliable.

Downstream Organizational Impact

The organization must determine whether affected identities, permissions, connectors, applications, workflows, data, code, transactions, persistent content, or security-control changes influenced additional systems, business units, tenants, customers, employees, partners, managed-service relationships, or regulated processes.

Operational Availability and Business-Continuity Impact

The organization must determine whether agent suspension, connector isolation, token revocation, workflow shutdown, browser restriction, code-execution restriction, SaaS restoration, transaction reversal, deployment freeze, manual processing, enterprise hunting, or prolonged monitoring disrupted finance, customer operations, legal work, human resources, software delivery, security operations, cloud administration, executive support, or other critical functions.

Customer, Workforce, Partner, and External-Service Impact

The organization must determine whether customer records, employee information, partner integrations, communications, hosted environments, managed services, financial relationships, support systems, external APIs, contractual functions, or downstream decisions were accessed, modified, transmitted, interrupted, or rendered unreliable.

Legal, Privacy, Compliance, and Insurance Impact

The organization must determine whether unauthorized access, sensitive-data exposure, unapproved automated decisions, financial activity, identity modification, customer or workforce impact, record alteration, incomplete evidence, prolonged disruption, or downstream expansion triggered legal review, privacy assessment, regulatory reporting, contractual notification, employment review, cyber-insurance coordination, litigation risk, communications response, or board escalation.

Containment, Recovery, and Trust-Restoration Impact

The organization must determine which agents, identities, connectors, sessions, SaaS objects, workflows, records, permissions, transactions, code, deployments, persistent objects, security controls, and downstream systems must be preserved, isolated, revoked, restored, rolled back, rebuilt, monitored, or independently validated before normal operation resumes.

Governance Impact

Leadership may need to treat confirmed or strongly suspected enterprise AI agent trust injection as an executive-level agent, identity, data, SaaS, workflow, financial, security-control, and downstream trust incident because one affected agent may possess authority across multiple critical business systems and may operate through identities and applications already trusted by the organization.

Economic Impact Summary

The organization’s financial exposure grows when it cannot quickly determine whether adversarial content materially influenced agent behavior, whether enterprise authority was misused, which data and enterprise objects were affected, whether unauthorized activity persisted or propagated, whether security controls and evidence remained reliable, and whether affected business operations can return to a known-trusted condition without continued uncertainty.

Cost is driven by the breadth of affected agents, identities, connectors, SaaS platforms, data, workflows, transactions, code, deployments, persistent context, downstream systems, and business processes, and by the organization’s ability to preserve evidence, establish impact, contain activity, restore altered state, and validate that unauthorized behavior has not recurred.

S39 — Economic Impact & Organizational Exposure

Enterprise AI Agent Trust Injection and Connected SaaS Autonomous Insider Risk expands organizational exposure by creating uncertainty over whether adversary-controlled email, documents, webpages, calendar entries, repositories, tool results, API responses, shared content, persistent memory, or connected-platform data materially changed an agent’s task; whether the agent altered its plan, tool selection, identity context, recipients, destinations, data scope, approval interpretation, or completion criteria; whether authorized enterprise identities and connectors performed unauthorized actions; and whether sensitive-data exposure, persistent influence, security-control impairment, concealment, or downstream organizational impact followed.

The governing risk is not limited to one model, agent framework, browser, coding assistant, connector, MCP server, SaaS platform, prompt phrase, injection string, vulnerability, proof of concept, campaign, or actor. The material question is whether untrusted content or attacker-controlled context was converted into unauthorized enterprise action through identities, tools, connectors, browser sessions, code-execution environments, persistent context, or workflows already trusted by the organization.

Economic exposure increases when affected agents support customer communication, finance, procurement, payroll, human resources, legal operations, identity administration, security operations, source control, software deployment, cloud administration, regulated information, customer environments, executive workflows, or broadly connected enterprise applications. Exposure is highest when defenders cannot join the initiating content to the agent task, planning change, tool call, connector activity, identity use, approval decision, SaaS object, data movement, browser action, process execution, persistent-context change, or downstream event.

Gemini CLI / CVE-2026-12537 expands this exposure model to developer and CI/CD agent workflows where attacker-controlled repository or workspace content can influence trusted agent execution. In affected headless or automated workflows, malicious .gemini configuration or environment-file content can cross the workspace-trust boundary and influence command or container-launch behavior before effective isolation controls apply. The governing business risk remains whether untrusted repository content was converted into unauthorized process execution, secret or credential access, source or configuration modification, deployment impact, or downstream enterprise action through a trusted coding-agent or CI runtime.

Atlassian Rovo / Jira / Confluence indirect prompt-injection and connected-SaaS data-access or exfiltration activity expands this exposure model to enterprise AI assistants operating inside sanctioned collaboration and knowledge-management workflows. Attacker-controlled or externally influenced content processed by Rovo may alter agent behavior while the agent operates with a legitimate user’s access to Jira, Confluence, and connected enterprise applications. The governing business risk is whether untrusted content caused Rovo to retrieve sensitive enterprise information, invoke URL-retrieval or other connected capabilities, transfer data to an unauthorized destination, or perform another consequential action through trusted SaaS identities and permissions.

MindsDB / CVE-2026-73678 expands this exposure model to network-accessible AI-agent runtime functionality where an unauthenticated request can reach agent-response processing and the Anton scratchpad execution path. In affected Minds Platform deployments, attacker-controlled requests can be converted into Python execution and resulting operating-system command execution with the privileges of the running application. The governing business risk remains whether network-accessible agent functionality was converted into unauthorized runtime execution, credential or secret access, file or configuration modification, persistence, network activity, or downstream enterprise action through a trusted AI-agent host.

MLflow / CVE-2026-64849 expands this exposure model to network-accessible AI engineering and model-management infrastructure where an unauthenticated request can cause a trusted MLflow Tracking Server to cross its intended network boundary. A 302 redirect can convert the webhook test path into full-read server-side request forgery against internal, loopback, link-local, or cloud-metadata services and return the upstream response to the attacker. Method-preserving 307 or 308 redirects can instead retain the original POST method and attacker-influenced body, creating a blind server-side request or write path against private-network services that accept consequential POST operations. DNS re-resolution without connection-time address pinning provides an additional path around the original destination validation. The governing business risk is whether an attacker converted the trusted MLflow server into an unauthorized internal requester capable of disclosing protected information, exposing cloud or service credentials, interacting with internal management services, changing internal state, or enabling consequential downstream activity. CISA added CVE-2026-64849 to the Known Exploited Vulnerabilities Catalog on August 19, 2026 based on evidence of active exploitation.

Estimated Economic Exposure

Estimated exposure should be treated as scenario-based rather than fixed. The most defensible enterprise estimate depends on whether activity remains limited to suspicious-content exposure, blocked tool use, unsuccessful manipulation, denied actions, or focused investigation; progresses into unauthorized connected-SaaS activity, sensitive-data access, partial workflow completion, identity or permission changes, code execution, persistent influence, or constrained downstream reach; or results in broad data exposure, financial activity, privileged access, source-code or deployment compromise, security-control impairment, customer or workforce harm, destructive activity, regulatory exposure, or prolonged operational disruption.

Economic exposure grows when the organization cannot determine whether untrusted content materially influenced agent behavior, whether the final action matched explicit user intent, whether approval covered the executed parameters, which identities or connectors were used, what data was accessed or transferred, which enterprise objects changed, whether influence persisted or propagated, and whether agent, identity, SaaS, data, workflow, and downstream trust can be restored.

Low Impact Scenario

Estimated $500K–$3M

This scenario applies when rapid investigation confirms suspicious-content exposure, a blocked or malformed tool request, unsuccessful instruction influence, prevented external transfer, denied execution, or another limited condition without evidence of consequential enterprise-state change, material sensitive-data exposure, persistent compromise, security-control impairment, customer or workforce impact, or downstream organizational expansion.

Available evidence supports a failed, prevented, contained, approved, or non-impacting event. Response remains limited to content and task review, prompt and retrieval analysis, connector and approval validation, focused identity and SaaS review, agent suspension or restriction where necessary, control tuning, evidence preservation, short-term monitoring, and executive assurance that broader agent, data, identity, workflow, and downstream integrity were not materially affected.

Moderate Impact Scenario

Estimated $5M–$35M

This scenario applies when confirmed or strongly suspected activity affects one or more enterprise agents, identities, connectors, SaaS platforms, browser sessions, code environments, workflows, persistent objects, or dependent business processes and produces unauthorized data access, external sharing, communication, record modification, permission change, account creation, connector expansion, code execution, deployment activity, financial action, persistent influence, security-control change, concealment, or constrained downstream access.

Evidence may include untrusted content followed by task-goal redirection, altered tool selection, changed recipients or destinations, approval-to-execution mismatch, sensitive-data access followed by cross-connector transfer, unauthorized high-impact action, denied activity followed by alternate execution, unexpected child-process creation, credential or secret access, persistent memory or workflow modification, browser-mediated action, or recurrence after agent restart, connector revocation, workflow rollback, or content removal.

For Gemini CLI, moderate impact may include attacker-controlled repository or workspace content causing unauthorized command or container-launch execution in a developer workstation or CI runner, exposure of environment variables or credentials available to the agent process, modification of source or configuration files, use of repository or deployment credentials, or constrained downstream CI/CD activity without evidence of broad organizational compromise.

For Atlassian Rovo, moderate impact may include attacker-controlled content causing unauthorized Jira or Confluence retrieval, access to connected third-party SaaS information, disclosure of sensitive ticket, page, document, or knowledge-base content, or transmission of retrieved information to an unauthorized external destination while activity remains constrained to a limited set of users, spaces, projects, connectors, or downstream systems.

For MindsDB, moderate impact may include successful unauthorized command execution within an affected agent-runtime host, access to environment variables, credentials, SSH material, local files, application configuration, or other resources available to the Minds Platform process, or constrained downstream activity without evidence of broad organizational compromise.

Response may require agent and workflow suspension, connector isolation, OAuth and token revocation, identity review, SaaS-object reconstruction, data-lineage analysis, browser and endpoint collection, code and deployment review, persistent-context rollback, enterprise hunting, downstream-system review, legal or compliance assessment, cyber-insurance coordination, executive reporting, and extended post-remediation monitoring.

High Impact Scenario

Estimated $40M–$200M+

This scenario applies when confirmed or strongly suspected agent manipulation becomes an enterprise-impact event involving broad sensitive-data exposure, fraudulent or unauthorized financial activity, privileged identity creation, widespread SaaS or enterprise-state modification, source-code or deployment compromise, customer or workforce harm, security-control degradation, durable persistent influence, multi-agent propagation, destructive activity, regulatory exposure, or prolonged operational disruption.

The organization may need to treat affected agents, models, runtimes, instructions, workflows, identities, OAuth grants, tokens, connectors, browser sessions, SaaS objects, data stores, repositories, build systems, deployments, financial records, persistent memory, knowledge sources, security controls, customer environments, partner integrations, and dependent business processes as exposed or unreliable until evidence proves otherwise.

For Gemini CLI, the high-impact case applies where workspace- or configuration-influenced host or CI-runner execution results in theft or use of repository, cloud, package-registry, deployment, signing, service-account, or other privileged credentials; unauthorized source modification; build or deployment compromise; secret exposure; software-supply-chain impact; or downstream enterprise-state change.

For Atlassian Rovo, the high-impact case applies where indirect prompt injection or attacker-influenced content results in broad retrieval or disclosure of Jira, Confluence, or connected-SaaS information; cross-application or cross-business-unit data exposure; access to credentials, customer information, legal material, source information, regulated data, or executive records; repeated or scalable exfiltration through sanctioned Rovo capabilities; or consequential downstream activity performed through trusted enterprise identities or connectors.

For MindsDB, the high-impact case applies where unauthenticated agent-runtime execution results in theft or use of privileged credentials, SSH keys, service-account material, cloud credentials, secrets, source or deployment credentials, persistence on the affected host, lateral movement, destructive activity, compromise of connected enterprise systems, or broader downstream organizational impact.

Response may require emergency agent suspension, enterprise connector restrictions, broad identity and session invalidation, data-access freezes, SaaS and workflow rollback, source-code and deployment review, financial reconciliation, customer or workforce impact analysis, enterprise-wide hunting, legal and regulatory escalation, cyber-insurance engagement, communications planning, executive and board reporting, and formal restoration of agent, identity, SaaS, data, workflow, and downstream trust.

Annualized Risk Exposure

Estimated annualized exposure of $6M–$45M+ for materially exposed enterprise environments where autonomous or semi-autonomous agents process untrusted content and possess access to sensitive data, multiple connectors, write-capable applications, privileged identities, financial functions, customer or workforce systems, source control, deployment pipelines, security platforms, cloud administration, or persistent enterprise context.

A realized severe event may reach $40M–$200M+ when manipulation results in broad sensitive-data exposure, fraudulent financial activity, privileged identity creation, widespread enterprise-system modification, source-code or deployment compromise, customer or workforce harm, security-control degradation, destructive activity, prolonged operational disruption, regulatory reporting, customer notification, litigation, cyber-insurance review, communications response, or board-level intervention.

Operational Dependency

Operational dependency is high where enterprise agents support customer service, sales, finance, procurement, payroll, human resources, legal work, software development, cloud administration, security operations, identity management, data processing, executive support, or other business-critical workflows.

One affected agent, application identity, shared connector, OAuth grant, browser session, workflow template, persistent memory source, knowledge base, orchestration platform, service account, CI runner, developer workstation, coding-agent workflow, Rovo agent, Jira project, Confluence space, connected-SaaS integration, Minds Platform runtime, or agent-execution host can create broad investigation and recovery requirements when multiple business units, users, customers, tenants, agents, repositories, deployment systems, or downstream systems depend on the same control path.

Dependency increases when the affected workflow cannot be suspended, restricted, returned to manual operation, disconnected from sensitive data, or separated from identity, financial, customer, cloud, security, source-control, deployment, or administrative platforms without disrupting essential business functions.

Control Trust

Control trust is reduced when the organization cannot prove that instruction hierarchy, task planning, tool selection, connector use, identity and OAuth activity, approval enforcement, SaaS state, data movement, browser activity, runtime execution, persistent context, workspace trust, repository input handling, environment-file processing, agent-response processing, scratchpad execution, logging, and downstream-system activity remained reliable during the exposure window.

Trust is further reduced when unauthorized activity occurs through an expected agent, valid identity, sanctioned application, approved connector, normal browser session, authorized API, documented workflow, trusted SaaS platform, developer workstation, CI runner, agent-runtime host, or common cloud destination, or when unexplained activity cannot be reconciled with approved automation, direct human action, testing, deployment, synchronization, administration, maintenance, or incident response.

For Gemini CLI, trust is reduced when defenders cannot establish whether the repository or workspace was explicitly trusted, which .gemini configuration or .env files were loaded, whether those files originated from trusted or attacker-controlled project content, which command or container-launch behavior was subsequently constructed or executed, what user or service identity owned the run, and whether resulting process behavior matched the intended developer or CI workflow.

For Atlassian Rovo, trust is reduced when defenders cannot establish which Jira issue, Confluence page, uploaded document, external content, or connected-SaaS object supplied the influencing instructions; which Rovo task or session consumed that content; which user identity and permissions governed the activity; what Jira, Confluence, or connected data Rovo retrieved; which tools or connectors were invoked; whether a URL or destination was constructed dynamically from retrieved data; and whether resulting access or transfer matched the user’s explicit intent.

For MindsDB, trust is reduced when defenders cannot establish whether an unauthenticated request reached the agent-response interface, which request or prompt initiated the activity, whether the Anton scratchpad was invoked, what Python or command behavior was generated and executed, which operating-system identity owned the runtime, what files, credentials, secrets, or network destinations were subsequently accessed, and whether resulting host activity matched an approved Minds Platform workflow.

Prompt filtering, agent restart, connector revocation, token rotation, content deletion, workflow rollback, browser closure, repository cleanup, workspace-trust correction, runtime isolation, credential rotation, or policy changes reduce future exposure but do not independently prove that pre-remediation data access, enterprise-state modification, partial execution, persistent influence, credential exposure, concealment, or downstream activity did not occur.

Visibility Confidence

Visibility confidence is highest when content provenance, retrieved objects, repository and project provenance, workspace-trust state, .gemini configuration, environment-file lineage, instruction sources, task and plan history, tool calls, command- or container-launch construction lineage, agent-response requests, scratchpad invocation, runtime process ancestry, connector activity, identity and OAuth events, approval records, SaaS audit logs, data classifications, browser actions, process and file telemetry, network sessions, persistent-context versions, security-control changes, downstream activity, change control, and incident-response evidence can be correlated through stable agent, task, trace, workflow, session, identity, connector, object, resource, repository, runner, runtime, destination, and timestamp mappings.

For Atlassian Rovo, visibility confidence is highest when defenders can preserve and join Rovo task and session context, originating Jira, Confluence, uploaded, external, or connected-SaaS content, user identity and effective permissions, Jira and Confluence object access, connected-app retrieval, tool and connector invocation, URL-retrieval activity, constructed destinations, accessed data, resulting outbound requests or SaaS actions, and downstream state through stable user, task, content-object, connector, destination, and timestamp mappings.

For MindsDB, visibility confidence is highest when defenders can preserve and join inbound agent-response requests, source and session context, agent and runtime identity, scratchpad invocation, generated or executed Python, process ancestry, command-line activity, file access, credential or secret access, network activity, child-process creation, resulting host state, and downstream activity through stable request, process, runtime, user, host, destination, and timestamp mappings.

Visibility confidence is reduced when prompts or retrieved content are redacted, source-object lineage is missing, repository provenance is unknown, planning history is unavailable, tool parameters are incomplete, .gemini configuration or environment-file provenance is not retained, command or container-launch construction cannot be reconstructed, MindsDB agent-response request history or scratchpad activity is unavailable, process ancestry is incomplete, identities are shared, approval records do not preserve reviewed parameters, SaaS platforms omit read or preview activity, Rovo content-to-task lineage is unavailable, URL-retrieval parameters or destinations are not retained, connected-SaaS access cannot be attributed to the initiating Rovo interaction, browser actions lack attribution, code executes in memory, cloud-hosted activity produces no endpoint evidence, data is transformed before transfer, persistent context lacks version history, or downstream systems do not preserve originating agent or workflow context.

S25 provides independent coverage for abnormal agent-workload network activity, unexpected command or automation execution, credential or sensitive-resource access followed by staging or outbound activity, high-impact action without valid approval, sensitive-data access followed by cross-connector or external transfer, denied activity followed by alternate-path or partial execution, and unauthorized identity, permission, connector, workflow, or persistent-configuration change. NDR, SentinelOne, Splunk, Elastic, QRadar, SIGMA, AWS, Azure, and GCP provide coverage according to platform-specific telemetry and implementation viability. YARA has no surviving rule because the governing behavior does not depend on a stable malicious file or reusable malware signature.

Change-Control Confidence

Change-control confidence is high when agent versions, model versions, system and developer instructions, tool inventories, connector scopes, OAuth grants, service identities, approval logic, workflows, persistent memory, knowledge sources, browser capabilities, code-execution permissions, Gemini CLI versions, run-gemini-cli action versions, workspace-trust configuration, .gemini configuration, environment-file handling, Minds Platform versions, agent-runtime exposure, agent-response interface configuration, runtime execution permissions, Rovo configuration, Jira and Confluence access, connected-SaaS integrations, URL-retrieval capabilities, SaaS configurations, deployment changes, testing, red teaming, emergency actions, and incident-response activity are recorded with validated actors, approvals, timestamps, expected objects, and post-change verification.

Confidence is reduced when agents are created outside governance, connectors or OAuth scopes are undocumented, shared service identities are used, persistent memory is not versioned, browser or computer-use capability is enabled without review, coding agents execute against untrusted repositories without explicit workspace-trust controls, network-accessible agent runtimes expose consequential execution functionality without effective authentication or isolation, Rovo processes untrusted or externally influenced Jira, Confluence, uploaded, or connected-SaaS content without sufficient provenance and action controls, CI workflows process attacker-controlled project content with broad execution permissions, workflow changes are automatic or opaque, approvals are generic, emergency changes are poorly documented, or business owners cannot distinguish authorized automation from attacker-driven task redirection, tool misuse, runtime execution, or persistent influence.

Downstream Dependency

Downstream dependency is high when affected agents or workflows have approved access to identity platforms, cloud control planes, customer environments, financial systems, human-resources systems, legal platforms, repositories, CI/CD pipelines, secret stores, package registries, deployment credentials, security tools, administrative interfaces, Jira, Confluence, connected Rovo data sources, partner services, or additional agents and automated workflows.

The organization must distinguish suspicious authentication, SaaS activity, cross-tenant access, external communication, source-control changes, deployment actions, financial transactions, internal-service access, policy changes, security-control changes, host-level process activity, or persistent-context updates from confirmed downstream compromise. Such activity becomes materially relevant when evidence ties it to an affected agent, task, identity, connector, browser session, workflow, repository, CI runner, runtime host, object, source, destination, or bounded investigation window.

Customer, Workforce, Partner, and Regulatory Exposure

Customer, partner, workforce, and regulatory exposure increases when agent manipulation affects customer records, employee information, financial data, legal material, source code, credentials, communications, identity decisions, customer support, procurement, payroll, employment actions, hosted environments, partner integrations, regulated information, software supply chains, or automated decisions subject to notification, contractual, privacy, audit, litigation, employment, or sector-specific obligations.

Exposure also increases when telemetry gaps prevent timely confirmation of whether private information was accessed or transferred, messages or records were modified, identities or permissions were created, financial activity occurred, source code or CI/CD behavior changed, credentials or secrets were exposed, unauthorized host execution occurred, persistent influence remained, downstream systems were affected, security controls were impaired, or containment was complete.

Notification and reporting decisions must be based on validated local evidence and applicable obligations rather than AI-agent presence, Gemini CLI presence, Rovo presence, Jira or Confluence presence, MindsDB presence, connector presence, vulnerable-version presence, public demonstrations, proof-of-concept availability, classifier alerts, prompt phrases, repository contents, source addresses, actor speculation, or static indicators alone.

Residual Economic Risk

Residual economic risk remains after patching, prompt filtering, model updates, connector restriction, token rotation, agent restart, workflow rollback, persistent-content removal, browser closure, Gemini CLI upgrade, CI-action upgrade, workspace-trust correction, repository cleanup, Minds Platform remediation, runtime isolation, credential rotation, Rovo configuration change, initiating-content removal, connected-SaaS restriction, endpoint remediation, SaaS restoration, or incident-response closure when the pre-remediation activity window cannot be reconstructed.

Removing the initiating content, upgrading Gemini CLI, correcting workspace-trust behavior, disabling the affected agent, remediating or isolating an affected Minds Platform runtime, restricting Rovo, or removing a Jira, Confluence, uploaded, or connected-SaaS content source does not prove that sensitive data was not accessed or transferred, unauthorized commands or container launches were not executed, environment variables or credentials were not exposed, files or source code were not modified, persistence was not established, deployments were not affected, persistent context was not contaminated, security controls were not weakened, or downstream systems were not affected before remediation.

Residual risk should remain elevated until historical content, task, planning, repository, workspace-trust, .gemini, environment-file, command or container-launch, MindsDB request and runtime, scratchpad execution, Rovo, Jira, Confluence, connector, identity, approval, SaaS, data, URL-retrieval, destination, browser, endpoint, network, persistent-context, downstream-system, change-control, incident-response, and remediation evidence has been assessed and the organization can demonstrate that agent, identity, SaaS, data, workflow, developer, CI/CD, runtime, and downstream trust have been restored.

CVE / KEV Behavioral Coverage Assessment

The expanded OSINT-to-S25 assessment identified public agent-security behaviors involving prompt-influenced operating-system command execution, prompt-to-host remote code execution, unauthenticated agent-response-to-scratchpad runtime execution, arbitrary file write, approval or allowlist bypass, sensitive agent-configuration modification, calendar-based indirect prompt injection followed by private-data disclosure, Atlassian Rovo indirect prompt injection followed by Jira, Confluence, or connected-SaaS data access and exfiltration, malicious-page-to-local-agent execution, agent-output script execution, browser-session hijacking, MCP tool poisoning, persistent-memory poisoning, MCP transport-session isolation failure, cross-user credential reuse, session-identifier authorization bypass, backend-endpoint manipulation, authorization-bearing server-side request forgery, unauthenticated full-read and method-preserving server-side request forgery from AI engineering infrastructure into internal or cloud-metadata services, Strands shell-tool consent-gate bypass through model-controlled tool parameters, AgentCore harness tool dispatch without model mediation, and Gemini CLI headless-workspace configuration and environment-file processing capable of converting attacker-controlled project content into host-level command or container-launch execution.

Direct Coverage applies where the documented behavior produces command execution, file creation or modification, credential or secret access, external transfer, unauthorized high-impact action, approval mismatch, alternate execution after denial, identity or permission expansion, persistent configuration change, or resulting enterprise-state activity already represented by an existing S25 rule without substantive modification.

Coverage With Adaptation applies where S25 may identify downstream effects but reliable detection of the material initiating behavior requires new agent-output rendering, browser DOM, WebSocket control-plane, tool-description integrity, tool-response provenance, persistent-memory integrity, MCP transport-session ownership, request-to-credential binding, cached-credential attribution, backend-endpoint integrity, authorization-bearing outbound-request correlation, MLflow webhook, redirect-status, redirect-target, request-method, request-body, destination-resolution, and server-side request correlation, Strands tool-schema and consent-state telemetry, AgentCore InvokeHarness request validation and tool-use lineage, Gemini CLI asset and workflow identification, project or repository input provenance, workspace-trust state, .gemini configuration and environment-file provenance, command- or container-launch construction lineage, MindsDB agent-response request attribution, Anton scratchpad invocation visibility, request-to-runtime execution lineage, Atlassian Rovo content provenance, Jira and Confluence object lineage, connected-SaaS retrieval lineage, Rovo task and user context, tool or connector invocation, URL-retrieval parameters and destination visibility, data-access-to-egress correlation, workspace- or configuration-influenced execution, user/session/task context, or specialized agent-runtime telemetry.

Public vulnerability disclosure, proof-of-concept availability, academic demonstration, vendor mitigation, KEV designation, and public reporting remain urgency, governance, and remediation signals. They do not independently establish local compromise or complete local detection coverage.

Detection Engineering Coverage Interpretation

The S25 detection content provides direct behavioral coverage when activity produces one or more of these implemented outcomes:

·        Abnormal external or internal network activity from a mapped enterprise AI-agent workload, browser-automation environment, connector host, code-execution environment, container, pod, CI runner, developer workstation, or supporting service

·        Sensitive enterprise data access followed by external, cross-tenant, public, personal, unmanaged, or unapproved transfer

·        Unexpected command, script, browser-automation, code-execution, deployment, package-management, downloader, source-control, credential-tool, remote-access, or administrative execution from an agent-associated process or workload

·        Credential, token, secret, browser-session, environment, source-control, cloud, deployment, or service-account access followed by staging, archive creation, script creation, transformation, or outbound activity

·        High-impact external sharing, deletion, permission change, identity change, financial action, source-control change, deployment, security-control change, workflow modification, or administrative action without valid approval

·        Executed parameters that materially differ from the action, recipient, destination, resource, identity, data scope, or transaction context approved by the user

·        Denied, blocked, rejected, or failed agent activity followed by successful alternate execution through another connector, application, browser path, API, identity, tenant, tool, or execution method

·        Consequential partial completion before a later workflow step fails or is blocked

·        Unauthorized creation or modification of identities, service principals, OAuth grants, tokens, credentials, roles, permissions, connectors, workflows, policies, instructions, memory stores, scheduled automation, or persistent agent configuration

·        Conditional cloud and downstream activity where task, trace, workflow, identity, application, connector, repository, CI runner, resource, destination, or incident lineage ties the event to the affected agent chain

The S25 rules intentionally avoid dependence on one prompt phrase, model, agent framework, vulnerability, tool name, connector, SaaS platform, browser, process name, command string, destination, proof of concept, or campaign. Product names, versions, affected functions, advisory identifiers, repository paths, workspace-trust state, runtime interfaces, and known attack paths may improve asset identification, investigation, and prioritization without changing the governing detection behavior.

Gemini CLI / CVE-2026-12537 does not require a new generic S25 rule. Existing S25 rules already cover resulting unauthorized command or container-launch execution, credential or secret access, file or configuration modification, staging, outbound activity, source-control or deployment changes, approval mismatch, and downstream enterprise action. Reliable initiating-behavior detection requires Gemini-specific source, field, schema, workflow, and lineage adaptation.

Atlassian Rovo / Jira / Confluence indirect prompt-injection and connected-SaaS data-access or exfiltration activity does not require a new generic S25 rule. Existing S25 rules already cover sensitive-data access followed by external or cross-connector transfer, unauthorized high-impact SaaS activity, approval mismatch, abnormal outbound activity where visible, and resulting downstream enterprise-state change. Reliable initiating-behavior detection requires Rovo-specific content provenance, task and session lineage, Jira and Confluence object access, connected-SaaS retrieval, user identity and permission context, tool or connector invocation, URL-retrieval parameters and destinations, and data-access-to-egress correlation.

MindsDB / CVE-2026-73678 does not require a new generic S25 rule. Existing S25 rules already cover resulting unexpected operating-system command or script execution from an agent-associated runtime, credential or secret access followed by staging or outbound activity, abnormal network activity, file or configuration modification where visible, and resulting downstream enterprise action. Reliable initiating-behavior detection requires MindsDB-specific visibility into the unauthenticated agent-response request, target runtime, Anton scratchpad invocation, generated or submitted execution content, request-to-process lineage, runtime identity, resulting child-process or command activity, and downstream host or enterprise-state correlation.

MLflow / CVE-2026-64849 does not require a new generic S25 rule. Existing S25 rules already cover abnormal internal or external network activity from an agent-associated or supporting workload, credential or sensitive-resource access followed by outbound activity, and resulting cloud or downstream enterprise effects. Reliable initiating-behavior detection requires MLflow asset and affected-version identification; webhook and webhook-test request visibility; source attribution; original webhook destination; redirect status; redirect target; hostname-resolution and final-destination visibility where available; preservation of whether the redirected request used GET or retained POST; request-body context where retained; MLflow workload attribution; request-to-server-side-network lineage; internal, loopback, link-local, cloud-metadata, or other prohibited destination identification; returned-response context for the full-read path; internal state-change or management-endpoint evidence for the method-preserving path; and resulting credential, secret, internal-service, cloud, or downstream enterprise-state correlation.

Direct Coverage

Direct Coverage applies where documented behavior produces material execution, file, credential, data-transfer, approval, identity, permission, configuration, SaaS, browser, process, or network activity already detected by current S25 rules without substantive changes to rule logic.

·        CVE-2026-61447 — PraisonAI CodeAgent execution of prompt-influenced LLM-generated Python without effective validation or sandbox enforcement, enabling environment-secret exposure and arbitrary host code execution

·        AutoJack — attacker-controlled webpage content reaching an unauthenticated local MCP WebSocket and causing AutoGen Studio to spawn attacker-selected operating-system commands

·        CVE-2026-26030 — Microsoft Semantic Kernel InMemoryVectorStore remote code execution capable of converting prompt-influenced agent processing into host-level code execution

·        CVE-2026-25592 — Microsoft Semantic Kernel SessionsPythonPlugin arbitrary file write through attacker-influenced file-operation parameters

·        CVE-2026-2256 — ModelScope ms-agent command injection through crafted prompt-derived input, permitting arbitrary operating-system command execution

·        CVE-2026-22708 — Cursor Agent Auto-Run allowlist bypass through shell built-ins, enabling environment-variable poisoning and subsequent trusted-command manipulation without expected approval

·        CVE-2025-61593 — Cursor CLI Agent sensitive-configuration modification through prompt injection, enabling remote code execution through altered agent files

·        Google Gemini Calendar indirect prompt injection — attacker-controlled calendar content causing Gemini to summarize private meetings, create a new event containing sensitive information, conceal the action behind a benign response, and expose the resulting event through connected-calendar permissions

CVE-2026-61447, CVE-2026-26030, CVE-2026-2256, CVE-2026-22708, CVE-2025-61593, and AutoJack directly align with S25 rules for unexpected command or automation execution, credential or secret access followed by outbound activity, denied or bypassed controls followed by alternate execution, and unauthorized persistent configuration changes.

CVE-2026-25592 directly aligns with endpoint and workload visibility into agent-associated file creation or modification, sensitive-path access, subsequent execution, staging, or outbound behavior.

The Google Gemini Calendar behavior directly aligns with S25 rules for sensitive-data access followed by transfer through another connected action or destination, unauthorized high-impact SaaS activity, approval mismatch, and misleading completion reporting.

Coverage With Adaptation

Coverage With Adaptation applies where current S25 rules contain relevant downstream coverage but detection of the material initiating or control-plane behavior requires substantive expansion of telemetry, integrity monitoring, source mapping, or correlation.

·        CVE-2026-64849 — MLflow Tracking Server unauthenticated server-side request forgery through webhook delivery and the webhook test path. A remotely reachable attacker can supply a public HTTPS webhook destination that passes initial validation and then exploit unvalidated redirects or DNS re-resolution to make the MLflow server reach internal, loopback, link-local, cloud-metadata, or other prohibited destinations. A 302 redirect changes the redirected request to GET and, through the webhook test endpoint, can return the upstream response status and body to the attacker, creating full-read SSRF. A 307 or 308 redirect preserves the original POST method and body, creating a blind server-side request or write path against private-network services that accept consequential POST operations. Current S25 rules can identify abnormal internal or external network activity from the MLflow workload, credential or sensitive-resource access followed by outbound activity, and resulting cloud or downstream enterprise effects, but reliable initiating-behavior detection requires MLflow asset and affected-version identification, webhook and webhook-test request visibility, source attribution, original URL, redirect status and target, hostname-resolution and final-destination visibility where available, redirected request method, request-body context where retained, request-to-server-side-network lineage, workload identity, returned-response context for full-read activity, internal state-change evidence for method-preserving activity, and resulting credential, secret, internal-service, cloud, or downstream-action correlation. CISA added CVE-2026-64849 to the Known Exploited Vulnerabilities Catalog on August 19, 2026 based on evidence of active exploitation. This remains MLflow-specific coverage qualification and does not require a new generic S25 rule.

·        CVE-2026-73678 — MindsDB Minds Platform unauthenticated remote code execution through the network-accessible agent-response path. An unauthenticated caller can reach agent-response processing that invokes the Anton agent scratchpad, where attacker-influenced Python can execute inside the server process and result in arbitrary operating-system command execution. Current S25 rules can identify resulting unexpected command or script execution, credential or secret access, file or configuration activity, abnormal network behavior, staging, outbound activity, or downstream enterprise effects, but reliable initiating-behavior detection requires MindsDB asset and version identification, agent-response request visibility, source and session attribution, Anton scratchpad invocation, execution-content visibility where available, request-to-runtime and process lineage, runtime operating-system identity, child-process or command execution, and resulting host or downstream-action correlation. This remains MindsDB-specific coverage qualification and does not require a new generic S25 rule.

·        CVE-2026-40289 — PraisonAI browser-bridge WebSocket exposure permitting unauthenticated remote session hijacking, sensitive page-context leakage, and misuse of connected browser automation; reliable detection requires WebSocket authentication, origin validation, bridge-session ownership, browser-action, and remote-controller attribution

·        CVE-2026-40112 — PraisonAI rendering of attacker-influenced agent output as unsanitized HTML, permitting JavaScript execution in the reviewing user’s browser; reliable detection requires agent-output rendering, HTML-sanitization, browser DOM, script-execution, and output-to-session correlation

·        CVE-2026-18830 — Amazon Bedrock AgentCore harness insufficient input validation in the InvokeHarness API before July 31, 2026. An authenticated caller could place a tool-use content block in the most recent request message, allowing the agent event loop to dispatch a configured tool directly without model mediation and associated security controls. Potential execution remained limited to tools configured on the affected harness. Current S25 rules can identify resulting tool execution, sensitive-data access, credential use, external transfer, approval mismatch, cloud or SaaS activity, or downstream enterprise-state change, but reliable initiating-behavior detection requires InvokeHarness caller identity, harness identity, final-message content type, caller-supplied tool-use block, configured-tool inventory, selected tool, tool arguments, request/task/session lineage, tool dispatch, tool result, and resulting-action correlation. This remains AgentCore-specific coverage qualification and does not require a new generic S25 rule.

·        CVE-2026-18733 — Strands Agents Tools shell-tool consent-gate bypass in versions before 0.8.0. The shell tool exposed the non_interactive parameter in its input schema to model control, allowing crafted prompt content to set the parameter to true, bypass human consent, and execute operating-system commands without operator approval. Current S25 rules can identify resulting command execution, credential or secret access, staging, outbound activity, approval mismatch, or downstream enterprise effects, but reliable initiating-behavior detection requires Strands tool identity, shell-tool schema, non_interactive value and provenance, consent-required state, consent prompt and decision state, model-supplied tool arguments, executed command parameters, agent/task lineage, and resulting process or enterprise-state correlation. This remains product-specific coverage qualification and does not require a new generic S25 rule.

·        CVE-2026-16498 — HashiCorp Terraform MCP Server cross-user credential reuse in Streamable HTTP stateless mode may cause one user’s cached Terraform token to execute tool calls for later users; current S25 rules can identify resulting cross-user or cross-tenant activity, unexpected Terraform or cloud actions, identity-to-task mismatch, token-associated downstream activity, abnormal infrastructure changes, and unauthorized administrative outcomes, but reliable initiating-behavior detection requires MCP request identity, client, server instance, cached-token owner, Terraform token, tool-call, target tenant, and resulting-action correlation

·        CVE-2026-16496 — HashiCorp Terraform MCP Server authorization bypass in Streamable HTTP stateful mode may allow a user possessing another user’s MCP session identifier to execute tool calls with that user’s cached Terraform credentials; current S25 rules can identify resulting credential use, cross-user or cross-tenant activity, unauthorized infrastructure actions, identity-to-task attribution mismatch, and downstream cloud or administrative effects, but reliable initiating-behavior detection requires MCP session ownership, session-identifier issuance and use, authenticated-client identity, cached-credential owner, Terraform token, tool-call, target tenant, and resulting-action correlation

·        CVE-2026-14869 — HashiCorp Terraform MCP Server server-side request forgery in Streamable HTTP mode may allow an unauthenticated client to redirect Terraform API requests and the server-side authorization token to an attacker-controlled endpoint; current S25 rules can identify abnormal outbound communication from an MCP or agent-associated workload, authorization-token exposure followed by outbound activity, unexpected destinations, and resulting unauthorized Terraform or cloud activity, but reliable initiating-behavior detection requires client-supplied backend-address visibility, resolved Terraform API endpoint, redirect behavior, outbound authorization-header handling, destination approval, request lineage, and server-to-tool-call correlation

·        CVE-2026-12537 — Google Gemini CLI and run-gemini-cli headless-workflow trust weakness affecting Gemini CLI before 0.39.1 and run-gemini-cli before 0.1.22. In affected headless CI or automated workflows, attacker-controlled repository or workspace content may influence local .gemini configuration or environment-file processing before effective workspace-trust enforcement, creating a path to pre-sandbox host-level command or container-launch execution. Current S25 rules can identify resulting process execution, environment-secret or credential access, file or source modification, staging, outbound activity, source-control changes, deployment effects, approval mismatch, or downstream enterprise-state activity, but reliable initiating-behavior detection requires Gemini CLI and run-gemini-cli asset identification, version state, headless execution context, repository and workspace provenance, workspace-trust state, .gemini configuration provenance, .env or other environment-file provenance, identification of loaded configuration or environment values, command- or container-launch construction lineage, workspace- or configuration-influenced command or container-launch execution, user or service identity, session/task/run lineage, resulting process execution, credential or secret access, source or configuration changes, and downstream-action correlation. This remains Gemini-specific coverage qualification and does not require a new generic S25 rule.

·        Atlassian Rovo / Jira / Confluence Indirect Prompt Injection and Connected-SaaS Data Access / Exfiltration — attacker-controlled or externally influenced content processed by Rovo can redirect agent behavior while Rovo operates with an authorized user’s access to Jira, Confluence, and connected enterprise applications. Documented activity includes indirect prompt injection causing Rovo to retrieve Jira tickets and Confluence content and use URL-retrieval functionality to transmit sensitive information to an attacker-controlled destination, with externally influenced Atlassian content and third-party connector data representing additional content-entry paths. Current S25 rules can identify sensitive-data access followed by external or cross-connector transfer, unauthorized high-impact SaaS activity, approval mismatch, abnormal outbound activity where visible, and downstream enterprise-state change, but reliable initiating-behavior detection requires Rovo task and session context, originating content provenance, Jira and Confluence object lineage, connected-SaaS retrieval lineage, user identity and effective permissions, tool and connector invocation, URL-retrieval parameters and destination, accessed-data scope, resulting outbound request or SaaS action, and content-to-task-to-data-access-to-egress correlation. This is a named platform and procedure-set Coverage With Adaptation entry, has no associated CVE in this amendment, and does not require a new generic S25 rule.

·        MCP Tool Poisoning — malicious or compromised MCP tool responses injecting hidden instructions that influence later tool selection, restricted-tool invocation, data access, or external transfer; reliable initiating-behavior detection requires tool-response provenance, trust classification, runtime integrity checks, and cross-tool lineage

·        Persistent Agent Memory Poisoning — attacker-controlled or compromised content modifying saved goals, user context, permissions, knowledge entries, or behavior-changing memory across sessions; reliable detection requires memory-object versioning, integrity baselines, protected-key monitoring, source provenance, write attribution, and rollback validation

These entries remain under adaptation because current S25 rules can identify resulting browser actions, script or process execution, credential or token use, sensitive-data transfer, identity use, cross-user or cross-tenant activity, unexpected outbound communication, unauthorized SaaS or infrastructure changes, persistent configuration modification, source-control or deployment changes, or downstream activity but do not directly detect every MLflow webhook-test request, redirect status, redirect target, redirected request method or body, DNS re-resolution condition, internal or cloud-metadata destination, full-read response disclosure, blind internal POST or state-changing condition, MindsDB unauthenticated agent-response request, Anton scratchpad invocation, request-to-runtime execution condition, AgentCore InvokeHarness input-validation or direct-tool-dispatch condition, Strands tool-schema or consent-state condition, Gemini CLI workspace-trust, .gemini configuration, environment-file provenance, command- or container-launch construction condition, Atlassian Rovo content-to-task influence, Jira or Confluence source-object lineage, connected-SaaS retrieval lineage, Rovo tool or URL-retrieval invocation, data-access-to-egress correlation, output-rendering, WebSocket-session-hijack, MCP session-isolation, cached-credential ownership, session-identifier authorization, backend-endpoint manipulation, authorization-header forwarding, poisoned tool-response, or memory-integrity condition without additional telemetry or correlation.

Non-Coverage Conditions

Non-Coverage applies where activity does not produce observable content-to-action correlation, planning change, tool or connector activity, identity use, approval mismatch, SaaS state change, sensitive-data movement, process execution, file activity, browser action, persistent-context modification, network deviation, security-control change, downstream activity, or post-remediation recurrence.

Non-Coverage applies when activity remains limited to:

·        AI-agent, model, connector, MCP server, browser, coding assistant, Gemini CLI installation, run-gemini-cli action, Rovo availability, Jira or Confluence presence, MindsDB installation, MLflow installation, workflow, vulnerable-version, or proof-of-concept presence without aligned local behavioral evidence

·        Prompt phrases, injection strings, hidden text, encoded instructions, tool descriptions, content classifications, advisory identifiers, filenames, hashes, domains, IP addresses, user agents, repository paths, .gemini file presence, environment-file presence, Jira or Confluence content presence, MindsDB process presence, MLflow process presence, or static indicators without evidence that agent, runtime, or server-side network behavior changed

·        Suspicious repository, workspace, Jira, Confluence, uploaded, external, connected-SaaS, agent-response, webhook, or webhook-test content that was not consumed by the affected component, was sanitized, blocked, rejected, or processed without material task, tool, connector, data, command, container-launch, identity, source-control, deployment, runtime, network, credential, internal-state, or persistent-state effects

·        Classifier alerts or unusual model responses that cannot be tied to planning changes, tool invocation, connector activity, executed actions, or resulting state

·        Generated commands, scripts, Python, or container-launch requests that were never executed

·        Denied, rejected, malformed, or failed actions that created no consequential partial state

·        Valid identity, connector, OAuth, SaaS, API, browser, Strands tool, AgentCore harness, Gemini CLI, Rovo, Jira, Confluence, MindsDB runtime, MLflow Tracking Server, CI runner, developer workstation, or repository use without evidence that the action fell outside explicit user intent, approved workflow, valid policy, attributable approval, or configured scope

·        Vulnerable Gemini CLI or run-gemini-cli version without evidence that attacker-controlled repository or workspace content influenced .gemini configuration, environment loading, command or container-launch construction, process execution, credential access, source change, deployment behavior, or another consequential action

·        Vulnerable Minds Platform presence without evidence that an unauthorized request reached consequential agent-response or runtime functionality, invoked scratchpad execution, produced operating-system execution, accessed credentials or sensitive resources, modified files or configuration, generated abnormal network activity, or caused another consequential action

·        Vulnerable MLflow presence without evidence that an unauthorized request caused the Tracking Server to reach an unexpected internal, loopback, link-local, cloud-metadata, or otherwise prohibited destination; return an internal response; preserve and relay an unauthorized POST to a private-network endpoint; expose credentials or secrets; interact consequentially with an internal service; change internal state; or cause another consequential downstream action

·        Rovo interaction with Jira, Confluence, uploaded, external, or connected-SaaS content without evidence that attacker-controlled instructions changed the task, caused unauthorized data retrieval, invoked a consequential tool or connector action, produced an unauthorized external destination, transferred sensitive data, or created another consequential enterprise-state change

·        Sensitive-data access without evidence of unauthorized transfer, sharing, modification, external use, or another consequential action

·        Cross-connector activity that cannot be distinguished from approved reporting, synchronization, support, migration, backup, legal, security, data-processing, or incident-response workflows

·        Browser activity that cannot be attributed reliably between the agent and a human sharing the same session

·        Process, file, command, container-launch, network, Gemini CLI, Rovo, MindsDB runtime, MLflow server, Strands tool-call, or AgentCore InvokeHarness activity that cannot be tied to an agent-associated runtime, workload, identity, task, session, trace, repository, CI run, connector, source object, request, destination, or bounded investigation window

·        Persistent memory, knowledge, workflow, instruction, or configuration changes that cannot be distinguished from approved personalization, deployment, administration, onboarding, testing, or maintenance

·        Multi-agent communication without evidence that contaminated content, unauthorized objectives, or harmful state propagated

·        Credential theft, lateral movement, data exposure, software-supply-chain compromise, ransomware, destructive activity, actor attribution, campaign attribution, or malware attribution inferred solely from generic behavior covered by S25

·        Environments where required agent inventory, content provenance, repository provenance, workspace-trust state, .gemini configuration and environment-file history, command- or container-launch construction lineage, Gemini CLI or run-gemini-cli version state, MindsDB asset and version state, MLflow asset and version state, MLflow webhook and webhook-test request visibility, redirect-status and redirect-target visibility, redirected request-method and body context where available, destination-resolution visibility, request-to-network lineage, agent-response request visibility, scratchpad invocation records, request-to-runtime and process lineage, Rovo task and session context, Jira and Confluence object-access history, connected-SaaS retrieval lineage, Rovo tool and connector activity, URL-retrieval parameters and destinations, task and trace identifiers, tool-call records, Strands tool-schema and consent records, AgentCore InvokeHarness request and tool-dispatch records, identity attribution, approval parameters, SaaS auditing, data classification, browser visibility, process and file telemetry, persistent-context history, network attribution, timestamp alignment, retention, resulting-state evidence, or approved-workflow context is unavailable

Current Coverage Count

Direct Coverage Entries

8

Coverage With Adaptation Entries

13

Current Coverage Register Count

21

CVE Entries

16

Named Behavioral Entries

5

The current register includes eight Direct Coverage entries and thirteen entries covered with adaptation. Sixteen entries are identified by CVE. Five are named public behavioral, platform, or research cases: AutoJack, Google Gemini Calendar indirect prompt injection, Atlassian Rovo / Jira / Confluence indirect prompt injection and connected-SaaS data access / exfiltration, MCP Tool Poisoning, and Persistent Agent Memory Poisoning.

The count represents the public behaviors individually assessed against the current S25 rules and retained as direct or adaptable coverage. It is a validated behavior-class review population, not an assertion that only 21 historical or future agent-security events can produce behavior detectable through S25.

Current KEV Count

1

CVE-2026-64849 is represented in the current coverage register as a CISA Known Exploited Vulnerability based on its August 19, 2026 addition to the Known Exploited Vulnerabilities Catalog with evidence of active exploitation. KEV designation increases remediation and investigative urgency but does not independently establish exploitation or compromise of a local MLflow deployment.

Coverage Qualification

Coverage is strongest where adversarial-content exposure can be joined with task or plan change, unexpected tool selection, identity or connector use, invalid or mismatched approval, sensitive-data access, external transfer, enterprise-state modification, local execution, persistent-context change, security-control impairment, abnormal server-side network activity, internal-service access, unauthorized internal state change, or downstream activity.

For CVE-2026-64849, reliable coverage requires MLflow asset and affected-version identification; visibility into webhook creation and webhook-test requests; source and request attribution where available; identification of the original validated webhook destination; redirect status and target; hostname resolution and final network destination where telemetry permits; whether the redirected request changed to GET or preserved POST; request-body context where retained; MLflow workload or service identity; request-to-server-side-network correlation; internal, loopback, link-local, cloud-metadata, or other prohibited destination identification; returned-response status or body context for the full-read path; evidence of internal POST handling or resulting state change for the method-preserving path; subsequent credential, secret, token, internal-service, cloud, administrative, or destructive activity; and resulting downstream enterprise-state correlation. The critical correlation is whether an unauthorized request caused the trusted MLflow Tracking Server to cross its expected network boundary and either retrieve protected internal information or deliver an attacker-influenced POST into a private-network service outside an approved workflow. Existing S25 abnormal-network, credential-access, sensitive-resource, outbound-activity, cloud, high-impact-action, and downstream-state rules remain the governing detections; no new generic S25 rule is required.

For CVE-2026-73678, reliable coverage requires MindsDB asset and affected-version identification; visibility into requests reaching the agent-response interface; source, session, and request attribution where available; identification of the target agent and runtime; Anton scratchpad invocation visibility; submitted or generated execution content where available; request-to-runtime, process, and child-process lineage; operating-system user context; command execution; credential, secret, file, configuration, and network activity; and resulting downstream enterprise-state correlation. The critical correlation is whether an unauthenticated request crossed the MindsDB agent-response boundary, reached scratchpad execution, and produced operating-system activity outside an approved local workflow. Existing S25 command-execution, credential-access, sensitive-resource, abnormal-network, staging, outbound-activity, and downstream-state rules remain the governing detections; no new generic S25 rule is required.

For CVE-2026-12537, reliable coverage requires Gemini CLI or run-gemini-cli asset identification and version state; confirmation that the workflow operated in a headless or automated execution context; project, repository, and workspace provenance; workspace-trust state and decision; .gemini configuration provenance; .env or other environment-file provenance; identification of which configuration or environment values were loaded; task, session, GitHub Actions run, user, and service-account lineage; command- or container-launch construction lineage; workspace- or configuration-influenced command or container-launch execution; resulting host process execution; credential, token, environment-secret, source-control, or deployment access; file or configuration modification; network activity; and downstream enterprise-state correlation.

The critical correlation is whether attacker-controlled project or repository content crossed the Gemini CLI workspace-trust or configuration-loading boundary and influenced command or container-launch execution that produced a consequential action outside explicit user or workflow intent. Existing S25 execution, credential-access, approval-mismatch, denied-or-bypassed-control, sensitive-data-transfer, source-control, deployment, and downstream-state rules remain the governing detections; no new generic S25 rule is required.

For CVE-2026-18830, reliable coverage requires Amazon Bedrock AgentCore visibility that joins the authenticated InvokeHarness caller to the target harness, the most recent request message, the presence of a caller-supplied tool-use content block, the tool configured on the harness, the selected tool and submitted arguments, direct tool dispatch by the event loop, resulting tool output, and downstream action state. The critical correlation is whether caller-controlled tool-use content caused a configured tool to execute without model mediation. Existing S25 tool-execution, approval-mismatch, sensitive-data-transfer, credential-use, high-impact-action, and downstream-correlation rules remain the governing detections; no new generic S25 rule is required.

For CVE-2026-18733, reliable coverage requires Strands-specific visibility into the shell-tool input schema, the non_interactive parameter and whether its value originated from model-controlled tool input, whether human consent was required, whether a consent interaction occurred, the command and arguments ultimately executed, the associated task or trace, and resulting process, credential, data-transfer, or enterprise-state activity. The critical correlation is whether a shell command executed with non_interactive=true despite the workflow expecting operator consent. Existing S25 execution, approval-mismatch, denied-or-bypassed-control, credential-access, data-transfer, and downstream-state rules remain the governing detections; no new generic S25 rule is required.

For Atlassian Rovo / Jira / Confluence indirect prompt-injection and connected-SaaS data-access or exfiltration activity, reliable coverage requires identification of the affected Rovo interaction and user; provenance of the Jira issue, Confluence page, uploaded document, external content, or connected-SaaS object processed by the agent; task and session lineage; Jira, Confluence, and connected-application retrieval activity; effective user permissions; tool and connector invocation; URL-retrieval parameters and dynamically constructed destinations where available; sensitive-data scope; resulting outbound request or SaaS action; and downstream state. The critical correlation is whether attacker-controlled content crossed the trusted content-to-agent boundary, altered Rovo behavior, caused access to enterprise information through the user’s legitimate permissions, and converted that access into an unauthorized external transfer or other consequential action. Existing S25 sensitive-data-transfer, high-impact-action, approval-mismatch, abnormal-network where applicable, cross-connector, and downstream-state rules remain the governing detections; no new generic S25 rule is required.

Coverage is weaker for hidden or obfuscated content without execution evidence, output manipulation without a consequential action, MLflow webhook activity without preserved request-to-network lineage, server-side requests without redirect-status or final-destination visibility, internal or cloud-metadata access without reliable MLflow workload attribution, returned-response disclosure without request context, method-preserving internal POST activity without request-method, body, destination, or resulting-state visibility, unauthenticated MindsDB requests without preserved request-to-runtime lineage, scratchpad activity without execution visibility, agent-runtime execution without reliable host or process attribution, attacker-controlled repository content that never crossed the workspace-trust or configuration-loading boundary, .gemini configuration or environment-file presence without evidence that it was loaded or influenced execution, Rovo-processed content without preserved source provenance, Jira or Confluence access without task lineage, connected-SaaS retrieval without initiating-content attribution, URL-retrieval activity without parameter or destination visibility, in-process behavior, browser actions without agent attribution, same-cloud transfer, approved-destination misuse, shared identities, missing approval parameters, unavailable SaaS read events, unversioned persistent memory, tool poisoning without response history, memory poisoning without integrity baselines, WebSocket activity without session ownership, MCP activity without request-to-session and request-to-credential ownership, backend-endpoint changes without request lineage, authorization-bearing outbound requests without header visibility, AgentCore harness activity without request-to-tool-dispatch lineage, Strands shell-tool activity without tool-schema and consent-state visibility, Gemini CLI activity without repository, workspace, configuration, environment-file, command or container-launch, and process lineage, short-lived execution, transformed data, incomplete lineage, and short retention.

The report does not claim universal prompt-injection detection, universal agent-manipulation detection, universal browser-agent detection, universal MCP detection, universal AgentCore harness detection, universal Strands detection, universal Gemini CLI detection, universal Atlassian Rovo detection, universal MindsDB detection, universal MLflow detection, universal CI-agent detection, universal sensitive-data-transfer detection, universal code-execution detection, universal SaaS detection, universal memory-poisoning detection, complete visibility across every model, framework, connector, application, SaaS platform, browser, developer workstation, CI environment, cloud provider, AI engineering platform, or agent runtime, or standalone CVE, actor, campaign, malware, or impact attribution.

Detection confidence depends on telemetry completeness, asset validation, agent and workflow inventories, content provenance, repository and workspace provenance, workspace-trust records, .gemini configuration and environment-file visibility, task and trace retention, tool-call normalization, command- or container-launch construction lineage, MLflow asset and version visibility, webhook request retention, redirect-status and redirect-target visibility, request-method and body context where available, destination-resolution visibility, request-to-network attribution, MindsDB asset and version visibility, agent-response request retention, Anton scratchpad and runtime-execution visibility, request-to-process attribution, identity and connector mapping, approval binding, AgentCore InvokeHarness request and tool-dispatch visibility, Strands tool-schema and consent-state visibility, Gemini CLI and run-gemini-cli version and configuration visibility, Rovo task and session visibility, Jira and Confluence object-access auditing, connected-SaaS retrieval lineage, URL-retrieval and destination visibility, SaaS audit coverage, data classification, browser and endpoint visibility, persistent-context versioning, process-to-network attribution, approved-workflow mapping, timestamp alignment, retention, query validation, performance testing, false-positive testing, and SOC triage readiness.

Executive Exposure Statement

The organization’s economic exposure is highest when enterprise-agent activity creates uncertainty over whether instructions, task goals, tool selection, delegated authority, sensitive data, connected-SaaS state, browser sessions, runtime execution, developer and CI environments, persistent context, security controls, downstream systems, and business-critical workflows remained intact.

Gemini CLI / CVE-2026-12537 reinforces this risk because trusted coding-agent and CI/CD workflows may process attacker-controlled repository or workspace content while holding access to environment variables, source code, repository credentials, deployment credentials, cloud identities, package registries, build systems, and downstream automation. The risk becomes material when defenders cannot prove whether workspace content remained passive data or crossed the workspace-trust and configuration-loading boundary into unauthorized command or container-launch execution and resulting enterprise action.

Atlassian Rovo / Jira / Confluence indirect prompt-injection and connected-SaaS data-access or exfiltration activity reinforces the same trust problem inside enterprise SaaS. Rovo may process attacker-controlled or externally influenced content while operating through legitimate user permissions and sanctioned access to Jira, Confluence, and connected enterprise applications. The risk becomes material when defenders cannot prove whether that content remained passive information or changed agent behavior, caused sensitive enterprise data to be retrieved, and converted trusted SaaS access into unauthorized external transfer or another consequential action.

MindsDB / CVE-2026-73678 reinforces the same trust problem at the agent-runtime boundary because network-accessible agent-response functionality may convert an unauthenticated request into code and operating-system execution within a trusted AI-agent host. The risk becomes material when defenders cannot prove whether the request remained non-consequential or reached scratchpad execution, accessed local credentials or secrets, modified host state, established persistence, generated downstream network activity, or otherwise converted the trusted agent runtime into an unauthorized execution path.

MLflow / CVE-2026-64849 reinforces the same trust problem at the AI engineering infrastructure boundary because a network-accessible Tracking Server may convert an unauthenticated webhook request into server-originated interaction with internal, loopback, link-local, or cloud-metadata resources. The 302 path may expose internal response content and cloud or service credentials, while method-preserving 307 or 308 redirects may relay attacker-influenced POST requests into private-network management services and create consequential internal state changes without returning the internal response to the attacker. The risk becomes material when defenders cannot prove whether the request remained confined to an approved public destination or crossed the network trust boundary, disclosed protected information, exposed credentials, interacted with private services, changed internal state, or enabled downstream cloud or enterprise activity. CISA KEV designation materially increases remediation and retrospective-investigation urgency because active exploitation has been established at the ecosystem level.

The strategic risk is not only that one prompt injection, framework vulnerability, connector weakness, malicious repository, exposed runtime interface, server-side request-forgery path, poisoned configuration file, malicious tool, or memory object exists. The material risk is that an adversary may convert one content interaction or network-accessible request into unauthorized activity performed through trusted identities, approved connectors, valid applications, developer tooling, CI runners, agent runtimes, AI engineering services, existing browser sessions, persistent enterprise context, and sanctioned business workflows before containment.

S40 — References

The following references support the public behavior descriptions, coverage classifications, KEV assessment, and detection-engineering interpretation in this report.

Vulnerability Records

NVD — CVE-2026-64849

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-64849

NVD — CVE-2026-73678

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-73678

NVD — CVE-2026-61447

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-61447

NVD — CVE-2026-40289

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-40289

NVD — CVE-2026-40112

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-40112

NVD — CVE-2026-26030

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-26030

NVD — CVE-2026-25592

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-25592

NVD — CVE-2026-22708

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-22708

NVD — CVE-2026-2256

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-2256

NVD — CVE-2026-18830

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-18830

NVD — CVE-2026-18733

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-18733

NVD — CVE-2026-16498

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-16498

NVD — CVE-2026-16496

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-16496

NVD — CVE-2026-14869

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-14869

NVD — CVE-2026-12537

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-12537

NVD — CVE-2025-61593

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2025-61593

Known Exploited Vulnerabilities

CISA — Known Exploited Vulnerabilities Catalog

hxxps://www[.]cisa[.]gov/known-exploited-vulnerabilities-catalog

Security Vendor Analysis

MLflow Security Advisory — GHSA-7gwp-5pfp-969j — Unauthenticated Full-Read SSRF in MLflow Webhook Delivery

hxxps://github[.]com/mlflow/mlflow/security/advisories/GHSA-7gwp-5pfp-969j

MindsDB Security Advisory — GHSA-jcxw-h8ph-pxpv — Unauthenticated Remote Code Execution via Agent Scratchpad exec() in POST /api/v1/responses/

hxxps://github[.]com/mindsdb/mindshub/security/advisories/GHSA-jcxw-h8ph-pxpv

PromptArmor — Atlassian Rovo Exfiltrates Data, Bypassing Controls

hxxps://www[.]promptarmor[.]com/resources/atlassian-rovo-exfiltrates-data

Varonis Threat Labs — RovoBlast: How One Click Triggered Atlassian’s AI Assistant to Leak Data

hxxps://www[.]varonis[.]com/blog/rovoblast

Google / GitHub Security Advisory — GHSA-wpqr-6v78-jr5g — Update to Gemini CLI and run-gemini-cli Trust Model

hxxps://github[.]com/google-github-actions/run-gemini-cli/security/advisories/GHSA-wpqr-6v78-jr5g

AWS Security Bulletin — 2026-073-AWS — CVE-2026-18830 — Issue with Amazon Bedrock AgentCore harness – Insufficient Input Validation

hxxps://aws[.]amazon[.]com/security/security-bulletins/2026-073-aws/

AWS Security Bulletin — 2026-072-AWS — CVE-2026-18733 — Prompt injection bypasses shell tool consent gate in Strands Agents Tools

hxxps://aws[.]amazon[.]com/security/security-bulletins/2026-072-aws/

HashiCorp — HCSEC-2026-23: Multiple vulnerabilities impacting HashiCorp Terraform MCP Server

hxxps://discuss[.]hashicorp[.]com/t/hcsec-2026-23-multiple-vulnerabilities-impacting-hashicorp-terraform-mcp-server/77606

Microsoft Security — AutoJack: How a single page can RCE the host running your AI agent

hxxps://www[.]microsoft[.]com/en-us/security/blog/2026/06/18/autojack-single-page-rce-host-running-ai-agent/

Microsoft Security — When prompts become shells: RCE vulnerabilities in AI agent frameworks

hxxps://www[.]microsoft[.]com/en-us/security/blog/2026/05/07/prompts-become-shells-rce-vulnerabilities-ai-agent-frameworks/

Miggo Security — Weaponizing Calendar Invites: A Semantic Attack on Google Gemini

hxxps://www[.]miggo[.]io/post/weaponizing-calendar-invites-a-semantic-attack-on-google-gemini

Google Security Blog — AI threats in the wild: The current state of prompt injections on the web

hxxps://blog[.]google/security/prompt-injections-web/

OWASP — MCP Tool Poisoning

hxxps://owasp[.]org/www-community/attacks/MCP_Tool_Poisoning

OWASP — Agent Memory Guard

hxxps://owasp[.]org/www-project-agent-memory-guard/

Threat Tradecraft and Intrusion Patterns

MITRE ATT&CK Framework — Enterprise Matrix

hxxps://attack[.]mitre[.]org/