OWASP Top 10 for Agentic Applications Guide: Each Risk and Its Controls

AI agents plan, call tools, hold credentials and remember things, so the failures that matter are no longer bad answers but bad actions. The OWASP GenAI Security Project published the OWASP Top 10 for Agentic Applications on 9 December 2025 to give builders and defenders a shared list of the ten risks that are specific to autonomous, tool-using systems. This guide walks through each entry, ASI01 to ASI10, with the controls that actually reduce it, how the list relates to the OWASP Top 10 for LLM Applications 2025 and the OWASP Non-Human Identities Top 10, and how to turn it into a review and testing programme. It is written for security architects, AppSec and IAM teams, and platform owners who have agents in production or about to be. For the wider control stack, see the Agentic AI Security Guide.

Key takeaways

• The list is about actions, not outputs. All ten entries describe how an agent's goals, tools, identity, memory or peers can be turned against the organisation, which is why the controls sit in identity, authorisation, sandboxing and monitoring rather than only in prompts.
• Least agency is the organising principle. OWASP extends least privilege into "least agency": do not give an agent autonomy, tools or reach it does not need, because unnecessary autonomy widens the attack surface without adding value.
• Identity runs through the whole list. ASI03 Identity and Privilege Abuse is explicit, but per-agent identities, short-lived task-scoped credentials and rapid revocation are also the main mitigations for tool misuse, inter-agent spoofing, cascading failures and rogue agents.
• It builds on, not replaces, the LLM Top 10. OWASP's own mapping ties every ASI entry to one or more LLM Top 10 2025 entries, most often LLM01 Prompt Injection and LLM06 Excessive Agency.
• Observability is non-negotiable. OWASP pairs least agency with strong observability: you need to see what an agent did, why, and with which tool and credential, or none of the ten risks can be detected or investigated.

What the list is and where it came from

The Top 10 for Agentic Applications was produced by the OWASP Agentic Security Initiative (ASI), part of the OWASP GenAI Security Project, and released on 9 December 2025 under the title "OWASP Top 10 for Agentic Applications for 2026". It distils the earlier OWASP Agentic AI Threats and Mitigations taxonomy (published 17 February 2025), which catalogued agent threats as T-codes from T1 Memory Poisoning to T17 Supply Chain Compromise, into ten prioritised, practitioner-facing entries with the prefix ASI.

The list went through public drafts. In the first public draft held in the OWASP GitHub repository, ASI01 was called "Agent Behaviour Hijack"; the final name is "Agent Goal Hijack". If you find older material quoting draft names, map it to the final IDs below.

• Agentic application: a system where a model plans, decides and acts across multi-step workflows, typically by calling tools, APIs, other agents or code interpreters, rather than only answering a prompt.
• Least agency: OWASP's advice to avoid unnecessary autonomy, extending least privilege and the LLM06 Excessive Agency concept.
• Strong observability: visibility into what agents do, why, and which tools they invoke, which OWASP describes as non-negotiable.
• Appendices: Appendix A maps each ASI entry to LLM Top 10 IDs, Threats and Mitigations T-codes and OWASP AIVSS core risks; Appendix B covers CycloneDX and AI bills of materials; Appendix C maps the OWASP NHI Top 10; Appendix D points to the Agentic Exploits and Incidents tracker.

The ten risks at a glance

LLM IDs: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Supply Chain, LLM04 Data and Model Poisoning, LLM05 Improper Output Handling, LLM06 Excessive Agency, LLM08 Vector and Embedding Weaknesses, LLM09 Misinformation. See the OWASP Top 10 for LLM Applications Guide.

ASI01 to ASI03: goals, tools and identity

ASI01 Agent Goal Hijack

An attacker plants instructions in content the agent reads, such as an email, a web page, a document or a calendar invite, and the agent adopts them as its goal. OWASP's example scenarios include the EchoLeak zero-click injection and prompt injection against browsing agents through web content. See the AI Agent Goal Hijacking Guide.

• Treat all natural-language input as untrusted: retrieved documents, tool outputs and email bodies get the same handling as user input, with clear separation from system instructions.
• Lock and gate goal changes: keep system prompts under change control and require human approval for any action that changes the agent's objective or scope.
• Validate intent at runtime: pause the run when the plan or tool sequence diverges from the declared task, and monitor goal state and tool-use patterns against a behavioural baseline.

ASI02 Tool Misuse and Exploitation

The tool is legitimate and the agent is allowed to call it, but it is used for something harmful: deleting data, sending bulk email, exfiltrating through an approved network tool. OWASP lists tool poisoning, tool name impersonation (typosquatting), over-privileged APIs and data exfiltration through an approved ping tool via DNS among its scenarios. See the AI Agent Tool and Plugin Security Guide.

• Per-tool least-privilege profiles: scopes, rate limits and egress allowlists defined per tool, not per agent.
• Policy checkpoint before execution: an enforcement point outside the model evaluates each call (tool, target, parameters) and requires human confirmation for destructive actions.
• Budgets and full invocation logs: usage budgets cap damage, and logging every call enables drift detection. See the AI Agent Action Approvals and Spending Limits Guide.

ASI03 Identity and Privilege Abuse

Agents act for users, for themselves, and for other agents, and each hop is a chance to inherit more than the task needs. OWASP's scenarios cover delegated privilege abuse, memory-based escalation (privileged data cached in context reused later), cross-agent confused deputy, workflow authorisation drift and forged agent personas. This is the entry where the OWASP NHI Top 10 overlaps most: Appendix C maps NHI5:2025 Overprivileged NHI to ASI02 and ASI03.

• Per-agent identities with short-lived, task-scoped credentials: no shared service accounts, no long-lived API keys in configuration.
• Session and memory isolation: wipe state between tasks so privileges and data do not carry over.
• Re-verify each privileged step: a central policy engine checks every privileged action, tokens are bound to the signed intent of the task, and escalation needs human approval.

See the AI Agent Authorisation Guide and the Top 10 Agentic AI Identity Issues.

ASI04 to ASI06: supply chain, code and memory

ASI04 Agentic Supply Chain Vulnerabilities

Agents assemble capabilities at runtime from MCP servers, tool registries, prompt hubs, agent cards and packages, so the supply chain is live rather than fixed at build. OWASP's scenarios include the Amazon Q supply chain compromise, MCP tool descriptor poisoning, a malicious MCP server impersonating Postmark, and agent-in-the-middle attacks through agent cards. The postmark-mcp malicious MCP server case shows how a single changed line in a trusted package silently copied email to an attacker.

• Sign and attest: manifests, prompts and tool definitions are signed, and SBOMs and AI bills of materials are kept for agent components. See the AI Supply Chain and AI-BOM Guide.
• Allowlist and pin by content hash: approved MCP servers and tools only, pinned versions, scanning for typosquats, and re-review when a tool description changes.
• Kill switch: the ability to disable a compromised tool or prompt across all agents quickly.

ASI05 Unexpected Code Execution (RCE)

Coding agents, data agents and anything with a code interpreter turn model output into execution. OWASP cites the Replit "vibe coding" runaway execution, direct shell injection, hallucinated code with a backdoor, unsafe object deserialisation and memory systems that call eval(). The OWASP incidents tracker maps several 2025 IDE and agent framework CVEs to ASI05.

• Apply LLM05 output handling: validate and encode generated code before it reaches an interpreter, shell or query.
• No eval in production agents: use safe interpreters and restricted languages where possible.
• Sandbox every run: containers or microVMs, never as root, with restricted file system and network access, and human approval for elevated runs. See the AI Agent Sandboxing and Code Execution Guide.

ASI06 Memory and Context Poisoning

Poisoned memory persists: one malicious write can bias every later session. OWASP's scenarios include travel booking memory poisoning, shared memory poisoning with fake refund policies and cross-tenant vector bleed.

• Scan writes and record provenance: every memory entry carries its source and trust level.
• Segment memory: per user, per session and per tenant, with no shared writable memory across trust boundaries.
• Expire, snapshot and roll back: unverified memory expires, snapshots allow rollback and quarantine, and agents do not automatically re-ingest their own outputs as trusted memory. See the AI Agent Memory Poisoning Guide.

ASI07 to ASI10: multi-agent systems, people and rogue behaviour

ASI07 Insecure Inter-Agent Communication

Multi-agent systems exchange instructions, context and results. OWASP's scenarios include semantic injection over unencrypted channels, message tampering, replay, protocol downgrade and A2A registration spoofing.

• Mutual authentication and per-agent credentials: encrypted channels, for example mutual TLS, with each agent authenticated as itself.
• Signed messages with replay protection: nonces and timestamps, typed and validated message schemas.
• Pin protocol versions: disable legacy protocols and require signed, attested agent cards. See the Agent-to-Agent Authentication Guide.

ASI08 Cascading Failures

A hallucination, poisoned input or faulty tool in one agent becomes another agent's trusted input, and errors amplify. OWASP's examples include a financial trading cascade, an auto-remediation feedback loop and a cyber defence agent shutting systems down on false alerts.

• Separate planning from execution: an independent policy engine approves what the planner proposes.
• Circuit breakers and blast-radius quotas: rate limits, just-in-time credentials and caps on how many records, systems or transactions one run can touch.
• Human gates before propagation: high-impact outputs are checked before downstream agents consume them, and logs are tamper-evident.

ASI09 Human-Agent Trust Exploitation

The human in the loop is a control only if the human can see what they are approving. OWASP's scenarios include invoice copilot fraud, credential harvesting through contextual deception and fabricated explanations.

• Explicit confirmation for sensitive actions: show the real action, target and parameters, not the agent's summary of them.
• Previews without side effects: preview steps must not execute anything.
• Flag uncertainty and divergence: mark unverified recommendations and detect when a plan diverges from the approved workflow. See the Human-in-the-Loop for AI Agents Guide.

ASI10 Rogue Agents

An agent that drifts from its function, whether through compromise, reward hacking or emergent behaviour, keeps its credentials and keeps acting. OWASP's scenarios include autonomous exfiltration after indirect injection, self-replication through provisioning APIs and reward hacking that leads to data loss.

• Immutable, signed audit logs: actions, tool calls and inter-agent messages.
• Trust zones and least-privilege API scopes: sandboxed agents that cannot provision new identities or infrastructure without approval.
• Watchdogs and kill switches: monitoring agents and a tested path to stop the agent and revoke its credentials quickly, with human approval before it is reintegrated. See the AI Agent Kill Switch and Containment Guide and the Rogue and Runaway AI Agent Detection Guide.

Controls that cover several risks at once

The control mapping in this table is NHI Mgmt Group's own; OWASP's appendices map to LLM IDs, T-codes and AIVSS, not to NIST controls.

Mapping to other frameworks

For a workshop method that uses these mappings, see the AI Agent Threat Modelling Guide.

Putting the list to work

1. Inventory agents first. List every agent with its owner, tools, MCP servers, data sources, credentials and autonomy level. You cannot apply ASI03 or ASI04 to agents you do not know about. See the Shadow AI Discovery Guide.
2. Triage by agency, not by model. Rank agents by what they can do: write access to production, money movement, external communication, code execution. Start with the highest.
3. Threat model each high-risk agent against all ten entries. Record for each ASI ID whether it applies, the current control and the gap. The Agentic AI Risk Assessment Template gives a scoring format.
4. Fix identity and tool scope before anything else. Replace shared or long-lived credentials with per-agent short-lived ones, and cut tool permissions to the task. These reduce five or more entries at once.
5. Introduce enforcement in monitor mode. Put the policy gateway in front of tools in log-only mode for a pilot group, review what it would have blocked, tune, then enforce. Keep the previous configuration so you can roll back by switching the gateway back to monitor mode.
6. Test. Run indirect prompt injection, tool misuse, memory poisoning and privilege escalation cases before release and after every change to model, prompt, tools or autonomy. See the AI Agent Security Testing Checklist.
7. Prove the kill switch. Stop an agent and revoke its credentials in a drill, and time it.

Small teams and large organisations

• Small teams with one or two agents: use the platform's built-in approval and scoping features, keep a short approved list of tools and MCP servers, and concentrate on ASI01, ASI02, ASI03 and ASI05, which cover most single-agent risk.
• Large organisations with many agents: centralise identity issuance, a tool and MCP registry, and a policy gateway, and add ASI07, ASI08 and ASI10 controls because multi-agent chains create propagation risk a single agent does not.

Detection and measurement

• Log per action: agent identity, principal, tool or API, parameters, credential identifier, policy decision, approval and outcome.
• Alert on: first use of a new tool or MCP server, tool description changes, spikes in volume or cost, repeated authorisation failures, destructive operations, writes to shared memory from untrusted sources, and agents creating identities or infrastructure.

Common failure patterns

• Relying on the system prompt as a security control. Instructions such as "never delete data" are inputs the model weighs, not enforcement. The Replit AI agent database deletion happened during a declared code freeze.
• Handing agents broad, long-lived tokens. The PocketOS database deletion involved a coding agent using an over-privileged Railway token to wipe production, a combined ASI02 and ASI03 failure.
• Trusting tools and packages because they were trusted yesterday. The Amazon Q Developer extension compromise shipped a wiper prompt through an over-scoped GitHub token, the ASI04 pattern OWASP itself cites.
• Treating retrieved content as data rather than instructions. EchoLeak showed a zero-click email could steer Microsoft 365 Copilot to leak data, the ASI01 example in the OWASP document.
• Approval prompts that show summaries, not parameters. Reviewers approve what the agent says it will do, which is exactly what ASI09 exploits.
• No tested way to stop an agent. Without a rehearsed kill switch and revocation path, a rogue or hijacked agent keeps acting while teams find its credentials.

Practitioner checklist

• Map every production agent to the ASI01 to ASI10 entries and record controls and gaps.
• Give each agent its own identity and short-lived, task-scoped credentials; remove shared and static keys.
• Define per-tool scopes, rate limits and egress allowlists, and remove tools the agent does not need.
• Enforce authorisation and approvals outside the model through a gateway or policy engine.
• Keep an approved, pinned list of tools, MCP servers and agent components, with signing and re-review on change.
• Run all generated code in a sandbox without root, host credentials or open egress.
• Segment and expire agent memory, and record provenance for every write.
• Authenticate and sign inter-agent messages, with replay protection.
• Log every agent action with identity, principal, tool, credential and decision, in tamper-evident storage.
• Drill the kill switch and credential revocation for every high-risk agent at least annually.

Standards and references

• OWASP GenAI Security Project: OWASP Top 10 for Agentic Applications for 2026
• OWASP GenAI Security Project: Agentic AI Threats and Mitigations
• OWASP: Top 10 for LLM Applications 2025
• OWASP: Non-Human Identities Top 10 2025
• OWASP: AI Vulnerability Scoring System (AIVSS)
• OWASP Agentic Security Initiative: repository and Exploits and Incidents tracker
• MITRE ATLAS: AI Agent Tool Invocation
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Agentic AI Security Guide · Top 10 Agentic AI Identity Issues · AI Agent Threat Modelling Guide · MCP Security Guide · Multi-Agent and A2A Security Guide