OWASP Top 10 for LLM Applications applied to AI agents

Every risk in the OWASP Top 10 for LLM Applications gets worse when the application is an AI agent, because a mistake becomes an action rather than a sentence. Injection, disclosure and misinformation now reach tools; supply chain and poisoning reach your systems through the agent's sources. Excessive agency, which sets how much damage follows, comes first.

What does the OWASP list require?

The OWASP Top 10 for LLM Applications is a community list of the most important security risks in applications built on large language models. It describes each risk, gives example scenarios and suggests mitigations. It is guidance, not a standard you certify against, and it is revised periodically. The entries below follow its current edition: prompt injection, sensitive information disclosure, supply chain, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation, and unbounded consumption.

For a short answer on whether and how it applies, see how the OWASP Top 10 for LLM Applications applies to AI agents.

Who does it apply to?

Teams that build, buy or secure LLM applications. Security reviewers use it to structure design reviews and tests; buyers use it in due diligence; auditors use it as a reference. In regulated firms it supports duties that are binding, such as security of processing under data protection law and ICT risk management under resilience rules.

How does each risk change when the application acts?

Prompt injection. In a chatbot, injected instructions change what it says. In an agent, they can change what it does, through every tool it holds. The control is containment: untrusted text cannot authorise an action.

Sensitive information disclosure. Agents retrieve data, carry it across steps and send it through tools, adding routes for leaks. Scope retrieval to the case and check what leaves; our piece on OWASP sensitive information disclosure by agents covers it in depth.

Supply chain. An agent depends on a model provider, a platform, connectors and data feeds. A change anywhere in that chain changes behaviour. Inventory the chain and re-test after changes.

Data and model poisoning. For agents, the practical risk is poisoned sources: a knowledge base article edited to include false instructions or facts. Control who can change sources and label each by origin.

Improper output handling. Agent output often becomes input to another system: a database query, an API call, a message. If downstream systems trust it without validation, the agent becomes a route for injection into them. Validate agent output as you would any untrusted input.

Excessive agency. The entry that sets the ceiling on harm. Too many tools, too many permissions or too much autonomy turn every other risk into a loss. Cut each to what the capability needs, enforced outside the model.

System prompt leakage. An agent's brief may describe its limits and tools. Leaking it helps attackers plan. The deeper lesson is that limits written only in the brief are not controls; enforce them elsewhere and treat the brief as discoverable.

Vector and embedding weaknesses. Agents that retrieve from shared vector stores can pull content across customer or permission boundaries. Enforce access control in retrieval, not after it.

Misinformation. A wrong statement from an agent may become a wrong action: a fee charged, a claim declined. Require that facts behind actions trace to supplied sources, and have the agent stop when sources are silent.

Unbounded consumption. An agent in a loop can call tools or models thousands of times. Set caps on actions and spend per task and per period.

Take an illustrative case. An e-money firm reviews its onboarding agent against the list. It finds three gaps: the agent's retrieval tool reads a shared document store without customer filtering; agent output is written directly into the case system without validation; and there is no limit on how many times it can request documents from a customer in a day. Each gap is fixed with a control outside the model, and each fix is added to the firm's adversarial test plan.

How do you meet the list for agents?

To test these controls, see red-teaming agents against the OWASP Top 10.

What will a security reviewer or auditor ask?

• Which OWASP entries apply to each agent, and where is each addressed?
• Which controls are enforced by the model's instructions alone?
• What can the agent do if every model-level defence fails?
• How do you validate agent output before other systems use it?
• When did you last test each entry, and what did you change?

What does the list not cover?

It does not cover business risks such as unfair treatment of customers, conduct failures or poor decisions within the rules. It does not set legal duties or tell you what your agent should be allowed to do. It is a security list; governance, model risk and consumer protection need their own controls. For the binding side, see our guide to AI agent regulation mapped to controls.

This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.

Where Pryme fits

Pryme enforces limits outside the model. Every fact arrives through the Pryme Context Protocol labelled sealed, signed, declared or external, and an external claim cannot authorise a payment. Every action meets the minimum chain, and the verdict, whether allowed, held, refused or withheld, is filed in an append-only record.