OWASP Top 10 for Agentic Applications, Explained for Engineers

When your agent reaches security review, the reviewer will have a checklist, and increasingly it is the OWASP Top 10 for Agentic Applications. OWASP's earlier list for LLM applications covered chatbots; the agentic list covers systems that take actions, which changes the risk profile entirely. This post walks the categories the way an engineer meets them: what the failure looks like, which layer of your harness owns it, and the control that closes it. The exact wording and ordering of OWASP's list evolves; the categories below are the stable ones you will be asked about.

1. Prompt Injection

Failure: Content the agent reads (page, email, document, tool result) redirects it. Indirect injection is the dangerous form because the attacker is not the user. Owner: Guardrails and context layers. Control: Least-privilege tools per task, approval gates on side effects, provenance labels on untrusted content, output controls against exfiltration. Detection as an extra layer, never the boundary.

2. Insecure Tool Execution

Failure: A tool does more than its description says, runs with broad credentials, or executes model-generated input (SQL, shell, code) without isolation. The model is induced to call it with something hostile. Owner: Tool orchestration. Control: Input validation in every tool, least-privilege credentials per tool, parameterized queries, and a sandbox (container or microVM, no credentials, allowlisted network, timeout) for anything that executes generated input.

3. Excessive Agency

Failure: The agent has more tools, permissions, or autonomy than the task needs, so a mistake or an injection has a large blast radius. The most common root cause in real incidents. Owner: Tool orchestration and guardrails. Control: Tool allowlists per task type, not per agent. Side-effect tools gated behind approval. Turn and cost budgets. Ask "what is the worst call this task could make" and remove the tool if the answer is unacceptable.

4. Memory Poisoning

Failure: Bad content enters long-term memory (through an injection, a bad run, or a malicious user) and influences every future run. Owner: Context and memory. Control: The model proposes memory writes; the harness or a human commits them. Every entry carries provenance and is inspectable and deletable. Runs that read untrusted content have their memory proposals quarantined.

5. Identity and Privilege Abuse

Failure: The agent acts with a human's credentials, so its actions are indistinguishable from the human's; or one agent impersonates another; or a delegated token is broader than the task. Owner: Guardrails and observability. Control: Each agent has its own least-privilege identity. Agent-to-agent calls authenticate. Delegated scopes are narrow and short-lived. The trace records which identity performed each action.

6. Supply Chain: Servers, Skills, and Plugins

Failure: A third-party MCP server, skill, or plugin ships with malicious code or a description that injects. The agent trusts it because it is "installed". Owner: Tool orchestration. Control: Treat servers and skills like packages: pin versions, review code and descriptions, run untrusted servers in isolation with narrow scopes, and monitor for description changes across versions.

7. Cascading Failures and Rogue Agents

Failure: One compromised or malfunctioning agent feeds bad output to others, and the system amplifies it. In multi-agent setups, an agent that goes off-task drags the rest with it. Owner: Guardrails and verification. Control: Treat every agent's output as untrusted input to the next. Verification between steps. Circuit breakers on budgets and error rates. Fewer agents: most systems do not need more than one.

8. Insufficient Observability and Human Oversight

Failure: Nobody can answer what the agent did, what it proposed, what was refused, or who approved what. Incidents cannot be reconstructed. Owner: Observability. Control: Trace every proposed, refused, paused, and executed call with arguments, identity, cost, and timing. Approval records in the trace. Alerts on refused side-effect calls (probing), unusual approvals, and sandbox denials.

9. Unsafe Output Handling and Exfiltration

Failure: Model output is rendered or executed by downstream systems: Markdown images that fetch from attacker hosts, URLs auto-opened, generated HTML rendered, generated code run. Owner: Verification and guardrails. Control: Treat model output as untrusted. Do not render remote images from output; confirm URLs; sandbox generated code; validate structured output against schemas before use.

10. Goal Hijack and Misalignment Under Autonomy

Failure: Over a long run, the agent's working objective drifts from the assigned task (through injection, ambiguous instructions, or optimization for a proxy) and it pursues something the user did not ask for. Owner: Verification and guardrails. Control: Explicit task specifications with definitions of done. Verification checkpoints that compare progress to the spec. Budgets that end runs that are not converging. Human-in-the-loop at milestones for long tasks.

The Pattern

Read the "Owner" column again. Every category is a property of the harness, the code you write around the model. None is fixed by a smarter model, and none is fixed by a prompt. That is why security review is where prototypes die: a prototype has a model and no harness, so it fails every category at once.

The good news is that the controls overlap heavily. Per-task tool scoping, approval gates on side effects, a sandbox, provenance labels, a memory write policy, agent identity, and a complete trace close most of the list. Build those seven, red-team them, and you walk into the review with answers.

What to Practice Next

Make a table with the ten categories as rows and, for your agent, three columns: the concrete worst case, the control in place, and the evidence (a trace, a test, a red-team result). Blank cells are your backlog. The module ai-security-for-agents-prompt-injection-excessive-agency-and-sandboxing builds the controls; agent-evals-trajectories-tool-calls-and-regression-suites turns the evidence into a CI gate.