The OWASP LLM Top 10 for teams shipping AI agents

Oct 21, 2026 · 4 min read

The OWASP Top 10 for LLM Applications (2025) is the closest thing the field has to a shared checklist. It was written for LLM apps in general. If you're shipping an agent that calls tools, some items matter a lot more than others, and some change shape completely.

The useful split: is the risk in what the model says, or in what the agent does? A chatbot can only say things. An agent can export, delete, write and send.

The list, read for agents

#	Risk	Where it lives for an agent	Main controls
LLM01	Prompt Injection	Input. The danger is what the injected instruction makes the tools do	Treat tool inputs as untrusted; constrain and check high-impact actions
LLM02	Sensitive Information Disclosure	Output and actions: replies, exports, emails, API calls	Least-privilege data access; check outbound actions by destination and volume; scan outgoing content
LLM03	Supply Chain	Models, packages, MCP servers and plugins you install	Pin versions; review and scan third-party servers
LLM04	Data and Model Poisoning	Training, fine-tuning and retrieval data	Data provenance; evaluation
LLM05	Improper Output Handling	Model output passed into code, SQL, shells, HTML	Validate and encode output; never pass it raw to an interpreter
LLM06	Excessive Agency	The action layer. Too many tools, too many permissions, too little oversight	Fewer tools, narrower permissions, human approval for high-impact actions
LLM07	System Prompt Leakage	The prompt	Keep secrets and authorization logic out of the prompt
LLM08	Vector and Embedding Weaknesses	Retrieval	Access control on the vector store; tenant isolation
LLM09	Misinformation	Output	Grounding, citations, human review where it matters
LLM10	Unbounded Consumption	Cost and availability	Rate limits, budgets, timeouts

The three that bite agents hardest

LLM01: prompt injection becomes an action problem

You can't reliably filter every injection out of a support ticket, a web page or a PDF. Assume some get through. The question then is what an injected instruction can make the agent do. If the answer is "export the customer table to any address", the prompt defence is carrying the whole load. If exports to external destinations always pause for a person, a successful injection produces a review request instead of a breach.

LLM02: disclosure goes through tools

For a chatbot, disclosure means the model saying something it shouldn't. For an agent, the bigger channel is actions: an export tool, an email tool, an outbound webhook. Those carry whole tables, not sentences. Controls that work here look at the action: what resource, which destination (internal, external email, external API), how many records.

LLM06: excessive agency is the agent risk

OWASP describes three causes: excessive functionality (tools the agent doesn't need), excessive permissions (tools that can do more than the task needs), and excessive autonomy (high-impact actions with no human check). The first two you fix at design time: remove tools, narrow credentials. The third needs something at runtime that can say "this one waits".

Where a runtime decision fits, and where it doesn't

Vulnify sits right before an agent action runs and answers ALLOW, REVIEW or BLOCK, with a 0–100 score and the reasons, from your policies and a rule-based risk engine. Mapped to the list:

LLM06, directly: per-action decisions, a review queue with a separate approver, Slack approval, and MFA for high-risk approvals.
LLM02, partly: outbound actions are decided on destination and volume, and optional content scanning flags things like CPF, card numbers, emails and API keys. It doesn't see what the model writes in a chat reply.
LLM01, as containment: it doesn't detect injections. It limits what a successful one can do.
LLM03, 04, 05, 07, 08, 09, 10: not covered. Use scanners, data controls, output encoding and rate limits for those.

No single tool covers the list. Anyone who says otherwise is selling you a slide.

A practical order of work

Inventory. List every tool each agent can call. Remove the ones it doesn't need (LLM06).
Narrow credentials. One token per purpose, not one token for everything (LLM06, LLM02).
Gate the high-impact actions. Exports, deletes, bulk writes and external sends get a runtime check, in monitor mode first (LLM06, LLM02, LLM01).
Handle output safely before it reaches code or a shell (LLM05).
Scan what you install (LLM03), and set budgets (LLM10).
Keep an audit trail of what was allowed, reviewed and blocked, and by whom.