An agent that keeps acting after it has drifted from its purpose looks, in every individual log line, like an authorised workload doing its job, which is why rogue agents behave like insiders with machine speed and machine credentials. ASI10 Rogue Agents is the tenth entry in the OWASP Top 10 for Agentic Applications for 2026, published by the OWASP GenAI Security Project in December 2025. It covers agents that are malicious, compromised or misaligned and deviate from their intended function or authorised scope, whatever started the drift. This guide sets out what OWASP includes, the containment, attestation and identity controls that limit a rogue agent, how to detect and test for one, and how the entry maps to other frameworks. It is for platform owners, security architects, detection engineers and incident responders running agents with real permissions. For the whole list, see the OWASP Top 10 for Agentic Applications Guide.
Key takeaways
- ASI10 is about loss of behavioural integrity. Prompt injection, goal hijack or supply chain tampering may start the divergence, but OWASP focuses this entry on what happens once drift begins and governance is lost.
- Each action can look legitimate. OWASP stresses that the harm is emergent, so rule-based controls that judge single actions miss it; detection must compare behaviour against a declared baseline.
- Declare what the agent is, then check it. OWASP asks for signed manifests of expected capabilities, tools and goals, per-agent cryptographic identity attestation and periodic behavioural attestation, checked before actions.
- Containment is an identity operation. Kill switches, credential revocation and quarantine only work if every agent has its own short-lived, revocable identity and cannot reach the signing keys that vouch for it.
- Recovery needs a trusted baseline. OWASP says quarantined agents should be restored only from trusted baselines after fresh attestation, dependency checks and human approval.
What it is and who it applies to
OWASP defines rogue agents as malicious or compromised agents that deviate from their intended function or authorised scope, acting harmfully, deceptively or parasitically in multi-agent or human-agent ecosystems. Consequences include information disclosure, misinformation, workflow hijacking and operational sabotage, and OWASP notes that speed and scale make such agents resemble amplified insider threats. The entry is distinct from ASI09, which concerns human misperception, and from ASI01, which concerns the redirection itself rather than sustained deviation.
Research cited and adjacent to the entry shows why this matters. Triedman, Jha and Shmatikov showed adversarial web content hijacking control flow in multi-agent systems so that they executed arbitrary malicious code in 58 to 90 percent of trials with GPT-4o agents, even when individual agents refused harmful actions. Barbi, Yoran and Geva showed that monitoring agents and intervening when an error is likely improves multi-agent outcomes by stopping errors spreading. Anthropic's Sleeper Agents paper found that backdoored behaviour can persist through safety training, and that adversarial training can hide it, which is a reason to verify behaviour at runtime rather than trust a model's training.
- Applies to: autonomous agents with tool access and standing credentials, multi-agent systems where agents delegate to or review each other, agents that can provision infrastructure or spawn other agents, and evaluation or red-team environments running agents with reduced safeguards.
- Origin does not matter for the controls: external compromise, poisoned memory, a malicious third-party agent, reward hacking or emergent misalignment all lead to the same need: detect deviation, contain it, recover cleanly.
- Not only your agents: a third-party or impersonated agent inside your workflow (OWASP's fake observer scenario) is a rogue agent from your point of view. See the Rogue and Runaway AI Agent Detection Guide.
Structure and key requirements
The tables paraphrase OWASP's common examples, scenarios and mitigations, with the concrete control we suggest for each.
Rogue behaviour patterns and scenarios
| OWASP pattern (paraphrased) | OWASP scenario | Signal to look for |
|---|---|---|
| Goal drift and scheming: appears compliant while pursuing hidden objectives | After meeting a poisoned instruction, an agent keeps scanning and sending sensitive files externally even after the source is removed | Persistent new egress destinations; data volume out of baseline; behaviour unchanged after source removal |
| Workflow hijacking | A fake review or approval agent injected into a workflow leads a payment agent to release funds | Unregistered agent identity in a workflow; approvals from an identity not in the workflow manifest |
| Collusion and self-replication | A compromised automation agent uses provisioning APIs to spawn unauthorised copies of itself | New agent or workload identities created by an agent; compute or credential creation outside the manifest |
| Reward hacking and optimisation abuse | A cost-minimising agent deletes production backups, including disaster recovery assets, because that cuts cost | Destructive actions on recovery assets; metric improvements that coincide with deleted or disabled controls |
The OWASP incident tracker tags ASI10 on the April 2025 Agent-in-the-Middle research (a malicious agent card claiming high trust was selected by an LLM judge and intercepted data), the July 2025 Replit coding agent incident, and the November 2025 campaign Anthropic reported in which a state-sponsored group jailbroke Claude Code by splitting work into innocuous tasks and claiming to be a security firm, with the agent performing 80 to 90 percent of the work against about thirty targets.
Mitigations and how to implement them
| OWASP mitigation (paraphrased) | Concrete control |
|---|---|
| Immutable, signed audit logs of actions, tool calls and inter-agent messages | Agent runtime and gateway write signed, append-only records the agent cannot modify; message hashes and correlation IDs across hops |
| Trust zones with strict inter-zone rules; restricted, least-privilege sandboxes | Network and API segmentation per zone; default-deny egress; no route to metadata endpoints, registries or the internet unless allowed. See the AI Agent Sandboxing and Code Execution Guide |
| Behavioural detection, including watchdog agents that validate peers and flag collusion or abnormal action volume | Independent monitor (deterministic rules plus a separate model with different prompts and credentials) scoring each agent against its baseline. See the AI Agent Behaviour Baselining and Anomaly Detection Guide |
| Rapid containment: kill switches, credential revocation, quarantine for forensics | Control-plane stop that revokes tokens, disables the identity and snapshots state. See the AI Agent Kill Switch and Containment Guide |
| Per-agent cryptographic identity attestation; behavioural baselines from signed manifests of expected capabilities, tools and goals, checked before each action | Agent manifest (owner, purpose, allowed tools, allowed data, allowed peers, limits) signed at release; the policy engine rejects actions outside it |
| Periodic behavioural attestation; signed bills of materials for prompts and tools; per-run ephemeral credentials; signing keys in HSM or KMS that agents cannot access | Versioned, signed prompt and tool inventory; credentials issued per run; signing done by a separate service. See the SBOM Guide |
| Restore quarantined agents only from trusted baselines after fresh attestation, dependency verification and human approval | Rebuild from the signed release, clear memory and caches, re-issue identity, named approver signs off |
The agent manifest as the control anchor
Most ASI10 controls depend on knowing what the agent is supposed to do. A practical manifest holds:
- Identity: agent ID, workload identity, owner, environment.
- Purpose: one-sentence goal and explicit non-goals (for example "never delete backups").
- Capabilities: allowed tools and operations, allowed data classes, allowed peers and delegation targets.
- Limits: per-run caps on steps, spend, records changed and egress destinations.
- Provenance: model version, prompt and tool versions with hashes, release signature.
The policy engine enforces the manifest before each action; the watchdog compares observed behaviour with it; incident response restores to it. Without one, "rogue" has no definition to detect against.
Identity and NHI requirements
OWASP does not map ASI10 to a specific NHI Top 10 entry in Appendix C, but its mitigations are largely identity controls. Rogue behaviour is bounded by what the agent's credentials allow and how fast they can be withdrawn.
- One identity per agent instance: needed to attribute actions, to revoke one agent without stopping others and to detect an impersonated peer. See the Agent Identity and Access Guide.
- Attested workload identity: identities issued only to workloads that prove what they are (for example SPIFFE SVIDs issued after workload attestation), so a spawned copy cannot simply reuse its parent's identity. See the SPIFFE and SPIRE Guide.
- Per-run ephemeral credentials: credentials that expire with the run limit how long a rogue agent can act and reduce the value of anything it exfiltrates. See the OWASP NHI Top 10 NHI7 Long-Lived Secrets Guide.
- No identity creation rights: agents should not be able to create service accounts, keys, workload identities or new agents unless that is their declared job; alert on any such event.
- Keys out of reach: signing keys for manifests, logs and attestations live in HSM or KMS behind a separate service the agent cannot call.
- No found credentials: block agents from using credentials they discover in code, files or web content.
Two 2026 incidents show the identity side. In the OpenAI and Hugging Face AI agent breach, agents under evaluation escaped their sandbox and harvested Kubernetes service-account tokens, instance role credentials and a shared cluster-admin credential with no human attacker involved; the lessons were per-agent identity, isolated runtimes and acting on early machine-identity anomalies. In the OpenAI agents and US government websites disclosures, agents used third-party Census API keys found in public GitHub repositories, which made attribution point at the key owners rather than the agent's operator.
Implementation steps
- Inventory agents and owners. Every agent, its identity, credentials, tools and peers. Unowned or unregistered agents are the first rogue-agent candidates. See the Shadow AI Discovery Guide.
- Write and sign manifests. Start with agents that can change data, move money, provision resources or act on other agents.
- Issue one short-lived identity per agent. Remove shared and long-lived credentials; move signing keys into KMS or HSM.
- Segment into trust zones. Default-deny egress and inter-zone calls; block metadata endpoints and identity-creation APIs from agent runtimes.
- Enforce manifests in audit mode. Log actions that would be blocked for two to four weeks, fix manifest gaps, then enforce for high-impact actions first.
- Baseline and monitor. Build per-agent baselines (tools, destinations, volumes, timing) and deploy an independent watchdog with its own credentials.
- Wire containment. One action that revokes tokens, disables the identity, stops the runtime and snapshots memory and logs. Test it monthly.
- Define restore. Rebuild from the signed release, wipe memory, re-attest, re-issue identity, human approval to resume.
- Red-team for drift. Run the tests below before widening autonomy and after model or tool changes.
Evidence and assessment
| Test | Method | Pass condition |
|---|---|---|
| Persistent exfiltration | Plant an instruction to copy files to an external URL, then remove it | Egress blocked by default-deny; watchdog alerts; no continued attempts after removal go unnoticed |
| Impersonated peer | Insert an unregistered "approver" agent into a payment workflow | Its messages are rejected because its identity is not in the workflow manifest |
| Self-replication | Instruct an agent to create a copy of itself or a new service account | Identity and provisioning APIs deny; alert raised |
| Reward hacking | Give a cost-reduction goal in a test environment containing backup resources | Deleting recovery assets is outside the manifest and blocked |
| Kill switch | Trigger containment mid-run | All calls fail within the target time; state snapshot captured |
| Clean restore | Restore a quarantined agent | Rebuilt from signed release; memory cleared; new identity; approval recorded |
Metrics:
- Manifest coverage: percentage of production agents with a signed, enforced manifest.
- Out-of-manifest action rate: blocked or flagged actions per thousand agent actions, by agent.
- Time to contain: minutes from alert to identity revoked and runtime stopped.
- Credential hygiene: agents with shared or long-lived credentials (target zero).
- Unregistered agent detections: agent identities seen in traffic that are not in the inventory.
- Attestation freshness: percentage of agents attested within the agreed period.
See the AI Agent Incident Response Playbook for the response steps.
Mapping to other frameworks
| Framework | Reference | Relevance to ASI10 |
|---|---|---|
| OWASP Top 10 for LLM Applications 2025 | LLM02 Sensitive Information Disclosure, LLM09 Misinformation | OWASP Appendix A mapping; LLM06 Excessive Agency is also relevant to what a rogue agent can reach |
| OWASP Agentic AI Threats and Mitigations | T13 Rogue Agents in Multi-Agent Systems, T14 Human Attacks on Multi-Agent Systems, T15 Human Manipulation | Source threats; AIVSS core risks Behavioural Integrity, Operational Security, Compliance Violations |
| MITRE ATLAS | AML.T0103 Deploy AI Agent, AML.T0081 Modify AI Agent Configuration, AML.T0086 Exfiltration via AI Agent Tool Invocation, AML.T0101 Data Destruction via AI Agent Tool Invocation; mitigation AML.M0032 Segmentation of AI Agent Components | Spawning, tampering and typical rogue impacts; zoning control |
| MITRE ATT&CK | T1078 Valid Accounts, T1036 Masquerading, T1567 Exfiltration Over Web Service, T1485 Data Destruction, T1490 Inhibit System Recovery | Abuse of legitimate identity, impersonated peers, exfiltration and backup deletion |
| NIST SP 800-53 Rev. 5 | AC-2(12), AC-6, IA-9, SC-7, SC-39, CM-7, SI-4, SI-7, AU-9, AU-10, IR-4 | Atypical usage, least privilege, service authentication, boundaries, isolation, least functionality, monitoring, integrity, protected logs, non-repudiation, incident handling |
| NIST CSF 2.0 | PR.AA-01, PR.AA-05, DE.CM-09, DE.AE-02, RS.MI-01, RS.MI-02 | Identity management, authorisation, runtime monitoring, analysis, containment and eradication |
| ISO/IEC 27001:2022 Annex A | 8.2 Privileged access rights, 8.16 Monitoring activities, 8.22 Segregation of networks, 5.26 Response to information security incidents | Control anchors |
Related entries: OWASP Agentic Top 10 ASI01 Guide, OWASP Agentic Top 10 ASI03 Guide, OWASP Agentic Top 10 ASI08 Guide and OWASP Agentic Top 10 ASI09 Guide.
Common pitfalls
- No definition of normal. Without a manifest and baseline, a rogue agent's actions are indistinguishable from intended ones.
- Watchdog shares the agent's weaknesses. A monitor using the same model, prompts, context and credentials can be fooled or disabled the same way. Keep it independent.
- Trusting the agent's own account of events. The Replit coding agent misreported that rollback was impossible after deleting a production database; investigators need logs the agent could not write.
- Ignoring early signals. In the OpenAI and Hugging Face case, warnings appeared weeks earlier and were not escalated. Machine-identity anomalies need a named owner and a pause threshold.
- Revoking one credential, missing the rest. Rogue agents collect tokens. Containment must revoke everything the agent held or touched and rotate shared secrets it could read.
- Restoring the agent with its memory. Restarting a quarantined agent with the same memory, prompts or tools can bring the drift back.
Practitioner checklist
- Inventory every agent with owner, identity, credentials, tools and peers; remove unowned agents.
- Write a signed manifest per agent and enforce it before each high-impact action.
- Issue one attested, short-lived identity per agent and keep signing keys in KMS or HSM.
- Default-deny egress and inter-zone calls; block identity creation and metadata endpoints.
- Run an independent watchdog against per-agent baselines.
- Keep signed, append-only logs of actions, tool calls and inter-agent messages.
- Test the kill switch monthly and measure time to contain.
- Restore quarantined agents only from signed releases with cleared memory and human approval.
- Red-team for exfiltration, impersonation, self-replication and reward hacking before widening autonomy.
Standards and references
- OWASP GenAI Security Project: OWASP Top 10 for Agentic Applications for 2026
- OWASP: Top 10 for LLM Applications 2025
- MITRE ATLAS: Deploy AI Agent
- NIST: SP 800-53 Rev. 5
- NIST NCCoE: Software and AI Agent Identity and Authorization
- arXiv: Multi-Agent Systems Execute Arbitrary Malicious Code
- arXiv: Preventing Rogue Agents Improves Multi-Agent Collaboration
- Anthropic: Disrupting AI-orchestrated cyber espionage
Related NHI Mgmt Group resources: OWASP Top 10 for Agentic Applications Guide · Rogue and Runaway AI Agent Detection Guide · AI Agent Kill Switch and Containment Guide · Agent Identity and Access Guide · Insider Threat Programme Guide