OWASP LLM Top 10 Explained for Engineers (2025 Edition and the Agentic List)
All ten OWASP LLM Top 10 risks with an engineering example and a control for each, plus the Agentic Top 10.
Framework mapping on the platform: OWASP LLM Top 10 and MITRE ATLAS mapped to controls.
The OWASP Top 10 for LLM Applications is the list security reviewers hand to engineers when an AI feature reaches review. It is useful, and it is easy to read as a compliance checklist instead of an engineering one. This post goes through each entry the way an engineer would: what actually fails, a small example, and the control that addresses it. It also covers the newer OWASP list for agentic applications and where MITRE ATLAS fits.
A note on versions. Lists change. This post uses the 2025 edition of the LLM list, published by the OWASP GenAI Security Project, with identifiers LLM01:2025 to LLM10:2025, and the Top 10 for Agentic Applications released in December 2025, ASI01 to ASI10. Check genai.owasp.org for the current text before you cite either in a document.
The 2025 list at a glance
| ID | Risk | One-line engineering view |
|---|---|---|
| LLM01 | Prompt Injection | Input changes model behaviour in ways you did not intend |
| LLM02 | Sensitive Information Disclosure | The model or its context reveals data it should not |
| LLM03 | Supply Chain | Compromised models, datasets, adapters or tools |
| LLM04 | Data and Model Poisoning | Training or retrieval data is manipulated |
| LLM05 | Improper Output Handling | Model output is trusted by downstream systems |
| LLM06 | Excessive Agency | The system can do more than the task needs |
| LLM07 | System Prompt Leakage | Instructions and secrets in prompts are exposed |
| LLM08 | Vector and Embedding Weaknesses | Retrieval stores leak or are poisoned |
| LLM09 | Misinformation | Confident, wrong output drives decisions |
| LLM10 | Unbounded Consumption | Nothing limits how much the system will do or cost |
Three themes cut across them. Untrusted text reaches the model (LLM01, 04, 05, 08). The system is given too much authority (LLM06, 02, 10). And you cannot see or prove what happened (all of them). The controls below reflect that.
LLM01: Prompt Injection
What fails: the model cannot separate instructions from data, so text from a user, a document, a web page or a tool result can redirect it. Direct injection comes from the user; indirect injection is planted in content the model later reads.
Example: an agent summarises a vendor email that contains a hidden line telling it to include the contents of the last five messages in its reply.
Controls: constrain what the model can do, so a fooled model has little to reach: least-privilege tools, human approval on high-risk actions, segregation and labelling of external content, output validation, egress control. Filters help at the margin and should never be the only layer. Test adversarially. We cover this in depth in prompt injection defense in agentic systems.
LLM02: Sensitive Information Disclosure
What fails: personal data, credentials, proprietary information or other confidential content appears in model output, either because it was in the context, in the training data or retrievable.
Example: a support assistant with broad access to the CRM answers a question with another customer's details because retrieval was not scoped to the asker.
Controls: classify data and decide which models may see which classes; scope retrieval by the asker's permissions; filter output at a gateway; minimise what you put in context; keep secrets out of prompts altogether. This risk rose from sixth to second place between editions, a reasonable signal of how often it bites in production.
LLM03: Supply Chain
What fails: a third-party model, adapter, dataset, library or tool is compromised, malicious or simply different from what you reviewed.
Example: a community MCP server is updated and its tool descriptions now carry instructions. Or a fine-tuned model from an unreviewed source contains a backdoor.
Controls: a registry of approved models and tools; version pinning; provenance and integrity checks; review on change; supply-chain events for installs an agent initiates. See securing MCP servers and tool access. MITRE ATLAS covers this under AI supply chain compromise (AML.T0010).
LLM04: Data and Model Poisoning
What fails: data used for pre-training, fine-tuning or retrieval has been manipulated to introduce bias, backdoors or targeted misbehaviour.
Example: a shared wiki that feeds your retrieval index is editable by many people, and one page has been altered to steer answers about a policy.
Controls: provenance and access control on every data source; review of what gets into fine-tuning sets; monitoring for drift; testing retrieval paths for poisoned content. In the EU, Article 15 of the AI Act refers to measures against poisoning for high-risk systems where appropriate.
LLM05: Improper Output Handling
What fails: downstream systems trust model output. Output that is passed to a shell, a database query, a browser or another service without validation becomes an injection vector in the classic sense.
Example: a model generates a command and a script executes it directly. Or output containing script is rendered in a web page.
Controls: treat model output as untrusted input. Validate against a schema, encode for the destination, never execute directly, and let policy deny forbidden commands before they run. This entry fell from second to fifth between editions, but it is the one that most reliably turns a model quirk into a conventional vulnerability.
LLM06: Excessive Agency
What fails: the system has more functionality, permissions or autonomy than the task needs, so any error or manipulation has large consequences.
Example: a summarisation agent is given a mail tool with send rights "for convenience."
Controls: minimise tools, scope credentials, add per-action limits and human approval for high-impact actions, separate decision from execution. In controlled-autonomy terms, set the level by the worst thing the agent could do. Excessive Agency is the single most useful entry to start with, because limiting agency contains several other entries as a side effect.
LLM07: System Prompt Leakage
What fails: instructions in the system prompt, sometimes including secrets or business rules, are exposed to users or attackers.
Example: an API key placed in a system prompt "so the model can call the service" is extracted by a direct injection.
Controls: assume the prompt is readable. Keep secrets, credentials and sensitive logic out of it. Enforce authorisation in code and in runtime policy, not in prompt wording. A prompt that says "never reveal the admin rules" is a request, not a control.
LLM08: Vector and Embedding Weaknesses
What fails: retrieval-augmented systems store embeddings and chunks that can leak across tenants or users, be poisoned, or be inverted to reveal source content.
Example: a shared vector index lacks per-user filtering, so a query returns chunks from documents the asker cannot normally open.
Controls: enforce access control at retrieval time, partition by tenant, validate and monitor what is ingested, log retrievals. Test cross-boundary leakage specifically.
LLM09: Misinformation
What fails: the model produces plausible, wrong output, and a person or process acts on it.
Example: an assistant cites a policy clause that does not exist, and a decision is made on it.
Controls: ground answers in retrieved, cited sources; show the citations; add human review where decisions depend on the output; evaluate against known material; make the system able to say it does not know. This is partly a product design problem, not only a security one.
LLM10: Unbounded Consumption
What fails: nothing limits how much the system will do. Attackers or bugs can cause denial of service, denial of wallet through expensive requests, resource exhaustion or model extraction through high-volume querying.
Example: an agent enters a loop calling a tool and a large model on every iteration overnight.
Controls: rate limits, token and spend budgets, per-agent and per-user caps, timeouts, anomaly alerts and cost attribution. In an agent context, add action caps and a kill switch.
The Agentic Top 10, in short
Agents plan, remember, call tools and act with delegated authority. OWASP's Top 10 for Agentic Applications lists ten risks specific to that:
| ID | Risk |
|---|---|
| ASI01 | Agent Goal Hijack |
| ASI02 | Tool Misuse and Exploitation |
| ASI03 | Identity and Privilege Abuse |
| ASI04 | Agentic Supply Chain Vulnerabilities |
| ASI05 | Unexpected Code Execution |
| ASI06 | Memory and Context Poisoning |
| ASI07 | Insecure Inter-Agent Communication |
| ASI08 | Cascading Failures |
| ASI09 | Human-Agent Trust Exploitation |
| ASI10 | Rogue Agents |
Several map cleanly to the LLM list: goal hijack is the agentic form of prompt injection, tool misuse and privilege abuse extend excessive agency, and supply chain appears in both. The new ones to take seriously are cascading failures, where one agent's error propagates through a chain, human-agent trust exploitation, where people approve something because the agent was persuasive, and rogue agents, which are agents operating outside the oversight you think you have.
Practical controls: a distinct identity and owner per agent; per-tool policy; kill switches and caps; approval screens that show evidence; an inventory and discovery process so unregistered agents are visible. See agent runtime security and shadow AI discovery.
Where MITRE ATLAS fits
OWASP tells you what to prevent. MITRE ATLAS, the Adversarial Threat Landscape for Artificial-Intelligence Systems, is a knowledge base of adversary tactics and techniques against AI systems, built on the ATT&CK model and updated frequently. Recent releases have added agent-focused techniques. Technique counts and identifiers differ between releases, so we cite none in bulk here, and you should look up IDs at atlas.mitre.org rather than from a blog.
Use it as a shared vocabulary. When a red team reports a finding, label it with the ATLAS technique. When a SOC sees suspicious agent behaviour, label it the same way. Then the two groups are talking about the same thing, and you can ask whether your detections cover the techniques that matter to you. LLM Prompt Injection (AML.T0051) and AI Supply Chain Compromise (AML.T0010) are two long-standing IDs.
Turning the list into engineering work
A list is not a control. A workable sequence:
- Inventory. Which models, agents, tools and data sources do you run? Without this, none of the rest has a subject.
- Excessive Agency and Prompt Injection first. Apply the Rule of Two to each agent, minimise tools and scopes, and add approval gates where state changes or data leaves.
- Output handling. Validate everything that leaves a model on its way to something that executes.
- Data. Classify, scope retrieval, filter output, secure the vector store.
- Supply chain. Registry, pinning, review on change.
- Consumption. Budgets, caps, kill switches.
- Evidence. Log the chain: identity, inputs, model, tools, policy, approval, action, outcome. See the AI audit trail.
- Test. Adversarial testing tagged to each entry, on every change that can shift behaviour. See AI red teaming.
What "OWASP-aligned" does and does not mean
When we say platform controls are mapped to OWASP, we mean we have designed them to address the named risks and that you can test them against those risks. OWASP does not certify products, and neither this post nor the platform pages claim any certification or audit by OWASP or MITRE. A mapping tells you where to look; it is not a result.
For teams working under EU rules, the OWASP and ATLAS vocabulary helps give concrete content to open-ended duties such as the robustness and cybersecurity expectations in Article 15 of the EU AI Act, or the risk-management measures in Article 21 of NIS2. The records and tests that come out of the work above support the evidence you need. They do not make a use compliant by themselves.
Where to go next
Read the mapped view at OWASP LLM Top 10 and MITRE ATLAS mapped to controls, then the SecOps hub. To pair this with the offensive side, see AI red teaming. If you want to talk through your own estate, talk to our team.