The OWASP Top 10 for LLM Applications, Read for AI Agents: Which Risks Grow When the Model Can Act
Once a model can call tools, four OWASP entries matter most: LLM01 Prompt Injection, LLM06 Excessive Agency, LLM05 Improper Output Handling and LLM02 Sensitive Information Disclosure, because text the agent reads can now become an action. The other six change too, from supply chain to unbounded consumption. Each has an agent-specific control, and almost all of them sit outside the model.
On this page
The OWASP Top 10 for LLM Applications was written for applications built on language models. An AI agent is one of those applications, with one difference that changes the picture: its output becomes an action.
When a chatbot is manipulated, it says something it shouldn't. When an agent is manipulated, it does something it shouldn't, with whatever tools and permissions it holds. The same ten entries apply, but their weight shifts. This post reads the 2025 list entry by entry for agents.
OWASP has since published a separate Top 10 for Agentic Applications for 2026. If your security programme already works from the LLM list, this is how to read it once tools are involved.
The four OWASP LLM risks that matter most for AI agents
LLM01:2025 Prompt Injection
For agents, the dangerous form is indirect: instructions hidden in a web page, a retrieved document, an email or a tool's output, which the model reads while doing its job. OWASP's entry on prompt injection is frank about the limits: given the stochastic way models work, "it is unclear if there are fool-proof methods of prevention".
That changes the design goal. Assume some injections will get through, and limit what a hijacked agent can do. OWASP's own mitigations point the same way: enforce least privilege, handle privileged functions in application code rather than giving the model direct access, require human approval for high-risk actions, and segregate and label external content. Tool descriptions are a channel too: a poisoned tool description can steer an agent before any user prompt arrives.
Agent control: bound what a successful injection can do, rather than betting on detecting every one.
LLM06:2025 Excessive Agency
This is the agent entry. OWASP traces excessive agency to three root causes: excessive functionality, excessive permissions and excessive autonomy. Its mitigations read like an agent design review: minimise the extensions an agent can call, avoid open-ended ones such as a shell or an arbitrary URL fetch, execute actions in the user's own security context, require approval for high-impact actions, and implement authorisation in downstream systems "rather than relying on an LLM to decide if an action is allowed or not".
Agent control: authorise every tool call outside the model, with credentials scoped to the task.
LLM05:2025 Improper Output Handling
For an agent, tool arguments are model output. A SQL query, a shell command, a file path or a URL that the model wrote is untrusted input to whatever executes it. OWASP's entry on improper output handling says to "treat the model as any other user, adopting a zero-trust approach", to use parameterised queries, and lists model output passed straight into a shell, exec or eval as a route to remote code execution.
Agent control: validate every tool call's arguments against a schema and a policy before execution, exactly as you would a request arriving from the internet.
LLM02:2025 Sensitive Information Disclosure
A chatbot can only leak what it says. An agent can also leak through what it does: a customer record pasted into an outbound email, an API key passed as a parameter to the wrong tool, a summary posted to the wrong channel. OWASP's entry on sensitive information disclosure asks for access to sensitive data based on least privilege, and for limits on the model's access to external data sources.
Agent control: scope the data each agent can read to its task, and check outbound tool calls for data that is not allowed to leave.
How the other six OWASP entries change for AI agents
| Entry | What changes for an agent | Agent-specific control |
|---|---|---|
| LLM03:2025 Supply Chain | OWASP's entry covers third-party models, datasets and fine-tuning adapters. Agents add tools and tool servers to that chain | Apply the same vetting, provenance checks and patching to every tool and server the agent can call |
| LLM04:2025 Data and Model Poisoning | Poisoned training, fine-tuning or embedding data can plant a backdoor that waits for a trigger. An agent that writes to memory or a shared store is one more writer | Control and log who, and which agents, can write to the data an agent retrieves |
| LLM07:2025 System Prompt Leakage | OWASP says the system prompt should not be treated as a secret or used as a security control | Keep credentials out of prompts, and enforce every limit outside the model |
| LLM08:2025 Vector and Embedding Weaknesses | Shared vector stores can leak data across users and contexts | Permission-aware retrieval: the agent retrieves with the user's rights, not its own |
| LLM09:2025 Misinformation | A confabulated fact stops being a wrong answer and becomes the premise of an action | Validate key outputs automatically before high-stakes actions, as OWASP recommends |
| LLM10:2025 Unbounded Consumption | Loops, retries and fan-out become runaway cost, a form OWASP calls Denial of Wallet | Spend ceilings, step limits and timeouts held outside the agent |
LLM07 deserves a second look, because it states plainly a mistake that is very easy to make with agents. Critical controls such as privilege separation and authorisation bounds checks, OWASP says, "must not be delegated to the LLM". If a permission exists only as a sentence in a system prompt, it is not a control.
What the ten entries have in common for agents
Read for agents, the list keeps returning to one idea. The model reads untrusted text, and the model decides what to do next, so the model cannot also be the thing that decides what it is allowed to do. Nearly every agent-specific control above moves a decision out of the model: into an authorisation check, a schema, a permission-aware store, a budget, or a person.
That also explains why text filters on the prompt and the reply miss much of this list once tools are involved. The harm happens in the call, not in the chat. The attack patterns against tool-calling agents are the threat model behind that point.
An OWASP review checklist for an AI agent
- Which tools can this agent call, and could any be removed or narrowed? (LLM06)
- If an injected instruction took control of it, what is the worst single action it could take? (LLM01)
- Are tool arguments validated before execution, by code the model cannot skip? (LLM05)
- What data can it read, and what checks run on data leaving through its tools? (LLM02, LLM08)
- Does any security rule live only in the system prompt? (LLM07)
- Who and what can write to its memory and retrieval stores? (LLM04)
- What stops a run that loops? (LLM10)
Where Syntrox fits
Nucleus, our judge, treats any text inside the material it evaluates as evidence, never as instructions, and an instruction addressed to the evaluator counts against the output. That is the property any model-based check needs if it is going to read the same untrusted text as the agent. Its injection-resistance probes run as a release gate with explicit thresholds, and Syntrox sits outside the agent, where a check has to be.