OWASP Top 10 for Agentic Applications: A Practical Guide for Teams Building Agents

The OWASP Top 10 for Agentic Applications, published in December 2025, lists the ten most important security risks for AI agents that plan, remember, call tools and act on someone's behalf: ASI01 Agent Goal Hijack, ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse, ASI04 Agentic Supply Chain Vulnerabilities, ASI05 Unexpected Code Execution, ASI06 Memory and Context Poisoning, ASI07 Insecure Inter-Agent Communication, ASI08 Cascading Failures, ASI09 Human-Agent Trust Exploitation and ASI10 Rogue Agents. Most share one root cause: an agent with more access than it needs, reading content it should not trust. Least privilege, untrusted-input handling, sandboxing, human approval and full audit logs address the majority.

A chatbot that gives a wrong answer produces a bad paragraph. An agent that is manipulated can send the email, issue the refund, run the command or change the record. The OWASP GenAI Security Project built the agentic list from incidents and research in 2025, with input from more than a hundred practitioners, to capture what changes when models are given autonomy and tools.

Use it as a threat-modelling checklist: for each risk, ask whether your agent could be affected, what the worst outcome would be, and which control limits it. The sections below explain each risk, give an example and list the first controls to put in place. Deeper guides on specific controls are linked throughout.

What it is: an attacker changes the agent's objective, usually through instructions hidden in something the agent reads: a web page, PDF, email, support ticket, code comment or tool output. The agent then pursues the attacker's goal while appearing to do its job.

Example: a support agent summarizes incoming emails. One email contains hidden text telling it to forward the last ten customer conversations to an outside address.

First controls: keep untrusted content clearly separated from instructions; never let retrieved content expand the agent's permissions; require approval for any action not implied by the user's request; filter outbound channels such as email and URLs. See indirect prompt injection and prompt injection prevention.

What it is: the agent uses tools it is allowed to use, but in harmful ways: deleting instead of archiving, querying far more data than needed, calling an expensive API in a loop, or chaining safe tools into an unsafe outcome.

Example: an operations agent with a general "run SQL" tool is asked to clean up test data and deletes production rows.

First controls: replace broad tools with narrow ones ("archive order" rather than "run SQL"), validate parameters server-side, cap quantities and rates, and mark destructive tools for confirmation. Our guides to AI tool security and AI agent tool design cover this in depth.

What it is: agents run with credentials that are too broad, shared between agents, long-lived, or borrowed from a powerful user, so any compromise or mistake inherits all of that access.

Example: a reporting agent uses an administrator's API key because it was quicker to set up; a goal hijack lets it change billing settings.

First controls: give each agent its own identity, act on behalf of the user with delegated, scoped tokens where possible, keep credentials short-lived and out of the model's context, and enforce authorization in your systems, not in the prompt. See AI agent access control.

What it is: the agent depends on components you did not build (models, MCP servers, plugins, tool descriptions, prompt templates, packages) and one of them is malicious, compromised or changes behaviour after you trusted it.

Example: a community MCP server update adds a tool description instructing the agent to send file contents to an external endpoint.

First controls: maintain an inventory of agent components, pin versions, review tool descriptions and permissions on update, prefer official servers, and run third-party components with minimal access. See MCP security and AI supply chain security.

What it is: the agent writes or receives code and runs it (scripts, shell commands, notebooks, generated queries) with access to real systems, turning a manipulation into remote code execution.

Example: a coding agent reads a repository file containing injected instructions and runs a command that exfiltrates environment variables.

First controls: run code in sandboxes with no production credentials and restricted network egress, allowlist commands where possible, and require approval for anything outside the sandbox. Coding agents need particular care; see securing AI coding agents.

What it is: malicious or false information is written into the agent's long-term memory, a shared knowledge base or a RAG index, and quietly influences future runs, sometimes for other users.

Example: a user convinces an assistant to "remember" that refunds over a limit no longer need approval; later sessions follow that rule.

First controls: decide explicitly what may be stored, keep memory scoped per user or tenant, record the source of each memory, review or expire memories that change behaviour, and protect retrieval indexes like any data store. See AI agent memory.

What it is: in multi-agent systems, messages between agents can be spoofed, replayed, tampered with or used to smuggle instructions from a compromised agent to others.

Example: a compromised research agent tells the purchasing agent that a supplier has been pre-approved.

First controls: authenticate agents to each other, validate message structure, treat other agents' outputs as untrusted input, and keep authority with the system of record rather than with what another agent says. See agent-to-agent communication.

What it is: a small error (a hallucinated fact, a failed tool call, a bad plan) propagates through steps or agents and multiplies: retries that loop, downstream agents acting on wrong data, costs that spiral.

Example: an inventory agent misreads a feed and marks hundreds of products out of stock; a pricing agent responds by changing prices across the catalogue.

First controls: set budgets for steps, tokens, spend and affected records; add circuit breakers and anomaly checks; checkpoint long workflows; and require human review when the blast radius exceeds a threshold. See AI agent orchestration.

What it is: the human in the loop becomes a rubber stamp. Agents present confident summaries, approvals arrive in volume, and people approve what they do not actually check, or attackers use the agent's credibility to persuade users.

Example: a finance approver receives fifty agent-prepared payment approvals a day and approves a manipulated one because the summary looked routine.

First controls: make approvals meaningful: show exactly what will happen, highlight changes from normal, reduce volume by auto-handling only truly low-risk cases, and sample approved actions for review. See human-in-the-loop AI.

What it is: an agent operates outside its intended behaviour or oversight, whether through compromise, misconfiguration, emergent behaviour in long-running autonomy, or simply being forgotten while still holding credentials.

Example: a pilot agent from last year still runs nightly with access to the CRM, though nobody monitors its output.

First controls: keep an inventory of every agent, its owner, permissions and purpose; monitor behaviour against expectations; have a tested kill switch that revokes credentials; and decommission agents properly. See AI agent observability and AI governance.

Run a short workshop per agent. List its tools, data access, memory, other agents it talks to and the people who approve its actions. Walk through ASI01 to ASI10 and mark each risk as not applicable, mitigated or open. Prioritize open risks by impact. Then turn the result into tests: injection attempts in documents, out-of-scope tool calls, expired credentials, poisoned memory entries. Repeat whenever tools or permissions change.

The OWASP agentic list gives teams a shared vocabulary for risks that did not exist when software only did what it was explicitly coded to do. You do not need ten separate programmes: scope tools and identities tightly, treat everything the agent reads as untrusted, sandbox execution, make human approvals real and watch what agents actually do. Those five habits cover most of the list.