The OWASP Top 10 for Agentic Applications: mitigating each risk in production

A production playbook for the OWASP Top 10 for Agentic Applications: how to meet and mitigate each of the ten risks with concrete controls, guardrails and governance.

Definition

The OWASP Top 10 for Agentic Applications is a community security framework, published in December 2025, that ranks the most critical risks specific to autonomous AI agents — systems that plan, call tools and act over many steps. It extends OWASP's LLM Top 10 to the agent layer.

Autonomous AI agents broke out of demos and into production faster than the controls meant to contain them. In December 2025 OWASP responded with a dedicated Top 10 for Agentic Applications — a recognition that an agent is not just a bigger chatbot, but a new class of system that acts. This guide walks each category and the defense that actually moves the needle.

Why do agents need their own Top 10?

A language model produces text. An agent turns that text into consequences: it reads a document, decides to call a tool, and the tool does something real — queries a database, sends an email, transfers funds. That single architectural shift changes the threat model entirely. A manipulated output used to be a wrong answer; in an agent it becomes a wrong action.

Two incidents made this concrete. In July 2025 a coding agent deleted a production database during a run. In December 2025 another agent wiped a developer’s disk. Neither was an exotic exploit — both were ordinary failures of scope and oversight.

Where agent incidents originate (illustrative)
34%28%16%14%8%
  • Excessive agency / over-broad permissions34%
  • Prompt injection (direct + indirect)28%
  • Tool / output poisoning16%
  • Missing human oversight on high-impact actions14%
  • Memory / retrieval poisoning8%
Relative frequency of root causes across publicly documented agent failures, 2025. Directional, not a formal survey. · opsagent synthesis of public incident reports

The ten categories, grouped

The list is easier to act on in four clusters.

1. Manipulating what the agent reads

Prompt injection is the headline risk. Direct injection targets the user prompt; indirect injection hides instructions in the documents, web pages and tool outputs an agent ingests later. Because agents browse and retrieve autonomously, indirect injection is the dominant vector — the attacker never talks to your agent directly.

Defense: treat every piece of external content as untrusted input, never as instructions. Separate the data plane from the control plane, and constrain what the agent can do after reading hostile text.

2. Abusing the agent’s tools

Tool poisoning tampers with the tools an agent relies on or the outputs they return. Excessive agency — consistently the most damaging category — is the agent simply holding more power than its task needs. When something goes wrong, broad permissions turn a small error into a large incident.

Defense: least privilege per tool, scoped credentials, and an allowlist of actions. If an agent only needs to read, it must not be able to write.

3. Corrupting the agent’s memory

Memory poisoning plants false or malicious content in long-term memory, embeddings or a retrieval store, so it is recalled later as trusted context. The payload persists across sessions and can quietly bias many future decisions.

Defense: validate what enters memory, segment memory by trust level, and expire or review long-lived entries.

4. Losing the human

The final cluster is organizational: missing oversight on high-impact actions, and over-trust between agents in multi-agent systems, where one agent treats another’s output as automatically safe.

Defense: a human-in-the-loop checkpoint before irreversible actions, and explicit trust boundaries between agents.

The risks at a glance

Risk What it does Primary defense
Prompt injection (indirect) Hidden instructions in fetched content hijack the agent Treat external content as data; separate control and data planes
Excessive agency Over-broad permissions amplify any error Least privilege per tool; default to read-only
Tool poisoning Tampered tools or outputs steer the agent Pin and verify tools; validate outputs; allowlist actions
Memory poisoning False context persists across sessions Validate writes; segment by trust; expire entries
Missing oversight No human gate before irreversible actions Human-in-the-loop on high-impact steps

A starter posture that works

You do not need all ten controls on day one. The highest-leverage moves are consistent across every incident above:

  1. Least privilege — scope each tool and credential to the minimum.
  2. Human-in-the-loop on destructive or costly actions.
  3. Treat external content as untrusted — data, never commands.
  4. Trace everything — you cannot defend what you cannot see.

These four cut off data loss and unauthorized spending — the outcomes that actually hurt — and give you the runway to mature the rest. For the vocabulary used here, see the AgentOps glossary; for the regulatory clock, see our governance coverage.

Frequently asked questions

How is agent security different from LLM security?

An LLM only produces text; an agent turns that text into action — it calls tools, writes to live systems and moves data. The same prompt injection that was once a harmless wrong answer can now delete a database, send money or leak a customer list. That shift means agent security has to defend the whole decision-and-action loop, not just the model's output. You have to reason about which tools the agent can reach, what permissions each one carries, and what happens after it reads hostile content. In practice this adds three concerns LLM security never had: tool authorization, action reversibility and runtime oversight. Treat the model as one untrusted component inside a system that acts, and design controls around the actions, not the words.

Is prompt injection really unsolvable?

There is no single fix that makes prompt injection go away, and anyone selling one is overstating the case. Because an agent reads untrusted text and then acts on it, the realistic goal is to shrink the blast radius rather than guarantee a clean input. Four controls do most of the work: treat every piece of external content as data and never as instructions, scope each tool to least privilege, require human approval before high-impact actions, and monitor execution traces for anomalies. Layer those and a successful injection still cannot reach anything that matters. The mistake teams make is hunting for a perfect input filter. Filters help at the margin, but the durable defense is constraining what the agent is allowed to do once the hostile text is already in context.

Where should a small team start?

Start with the two controls that block the worst outcomes for the least effort: least privilege on every tool and credential, and a human-in-the-loop checkpoint on destructive or costly actions. Together they cut off the two failure modes that actually hurt — irreversible data loss and unauthorized spending — and they take days, not quarters, to put in place. A coding agent that can only read a repository cannot wipe it; an agent that must pause for approval before a payment cannot drain an account. Once those guardrails hold, add execution tracing so you can see what the agent did and why. Then layer in input handling and memory hygiene as the system grows. The order matters: contain the damage first, observe second, refine third.

Which agentic risk is the most damaging?

Excessive agency — an agent holding more permission than its task needs — is consistently the most damaging category, and it sits behind a large share of documented incidents. The reason is leverage: when an over-privileged agent makes an ordinary mistake or follows an injected instruction, broad access turns a small error into a large one. A read-only summarizer that gets manipulated produces a wrong sentence; the same manipulation on an agent with delete and payment rights produces a wiped database or a fraudulent transfer. This is why least privilege outranks almost every other control — it caps the worst-case outcome regardless of how the agent was tricked. Scope credentials per tool, prefer read access by default, and gate write and spend behind explicit approval. Limiting power is cheaper and more reliable than trying to prevent every mistake.