llmaudit.eu

LLM security audit · European Union

Scope an audit

Annex 02

OWASP Top 10 for LLM Applications 2025: what an auditor tests

Updated 10 min read llmaudit.eu

The OWASP Top 10 for LLM Applications 2025 is a good catalog and a poor test plan. It names the risks; it does not say how an assessor demonstrates one, what artifact should end up in the report, or which fix survives the next model upgrade. This annex fills in those three columns.

How to use this list

The 2025 edition, published by the OWASP GenAI Security Project, replaced the 2023 list and reordered it around how applications actually fail. Treat each entry below as a row in a coverage matrix with four cells: what is tested, which MITRE ATLAS techniques the finding maps to, what evidence the report carries, and the control that keeps working after the model is fooled.

A matrix is only useful if it records absence. An entry marked "not tested" with a reason is more valuable to a reader than an entry silently omitted, and it is the difference between an audit report and a sales document. Where an application is agentic, pair this list with the OWASP Agentic Top 10, which covers the failure modes that only appear once a model can act.

LLM01:2025 Prompt Injection

What is tested. Whether user input, retrieved documents, uploaded files, fetched web pages, ticket bodies or tool descriptions can override the system instructions, and whether the effect persists into later turns. Direct and indirect variants are tested separately because they have different owners: direct is usually a prompt design problem, indirect is always an architecture problem.

ATLAS. AML.T0051 with its direct and indirect sub-techniques, AML.T0065 prompt crafting, AML.T0068 obfuscation, AML.T0093 infiltration through a public-facing application, AML.T0094 delayed execution.

Evidence. A transcript per successful case with the exact payload, the ingestion channel, the run count and the observed success rate. A single successful run is a finding; the rate tells the reader how reliable it is.

Fix pattern. There is none at the model layer. What works is reducing the consequence: separate instruction from data structurally, strip or fence retrieved content, deny the model any privileged identity, and require confirmation for actions with side effects. The full method is in testing for prompt injection.

LLM02:2025 Sensitive Information Disclosure

What is tested. What the assistant will reveal that the requesting identity has no right to see: other tenants' records, documents outside the user's permissions, personal data pulled in as context, credentials embedded in configuration. Testing includes the oblique routes, because a model that refuses to quote a document will often summarize, translate or answer questions about it.

ATLAS. AML.T0057 LLM data leakage, with AML.T0064 where the attacker first works out which documents are indexed.

Evidence. The disclosed field or document, the identity that requested it, and the access-control decision that should have prevented it. Findings are stated against the source of truth, not against the model behavior.

Fix pattern. Filter at retrieval, not in the prompt. The retrieval layer should apply the same authorization as the underlying store, per request, using the end-user identity. Asking the model politely not to disclose is not a control.

LLM03:2025 Supply Chain

What is tested. Provenance and change control for everything that ends up in the inference path: base models and hosted endpoints, adapters and fine-tunes, embedding models, prompt templates, agent frameworks, and MCP servers. Whether versions are pinned, who can change them without review, and what would be noticed if they changed.

ATLAS. AML.T0104 publish poisoned AI agent tool, AML.T0110 AI agent tool poisoning.

Evidence. A component inventory with source, version and update path. Most teams discover during this exercise that they cannot produce one, which is itself the finding.

Fix pattern. Pin versions, review third-party MCP servers as dependencies rather than as features, and maintain an AI bill of materials alongside the software one. CVE-2025-6514 in mcp-remote, an operating-system command injection triggered by connecting to an untrusted MCP server, is the clearest reminder that this is a classic dependency problem wearing new clothes.

LLM04:2025 Data and Model Poisoning

What is tested. Whether content a low-privileged user can submit reaches a fine-tuning set, a feedback loop, a shared memory or an index that higher-privileged users query, and what review stands between submission and ingestion. For most application audits this is a data-flow question rather than a machine-learning one.

ATLAS. AML.T0070 RAG poisoning, AML.T0080 AI agent context poisoning.

Evidence. The write path from an untrusted submission to the model context, drawn end to end, with the review or filtering step at each hop marked present or absent.

Fix pattern. Curate what enters training and retrieval sets, keep user-submitted content in a separate namespace from authoritative content, and label provenance so the model and the interface can distinguish the two.

LLM05:2025 Improper Output Handling

What is tested. Everything that consumes the model response as though it were trustworthy: markdown and HTML renderers, image and link construction, JSON parsers, shells, SQL builders and downstream services. This is the classic injection family in a new position, and it is the risk most often missed by teams who treat the model as the whole system.

ATLAS. AML.T0077 LLM response rendering, AML.T0067 trusted output components manipulation.

Evidence. The rendered payload plus the request it produced or the command it executed. For exfiltration cases, the collector log showing the data arriving.

Fix pattern. Encode on output, validate against a schema before any consumer acts, and restrict where rendered content may fetch from. An egress allow-list is the control that turns a disclosure into a non-event.

LLM06:2025 Excessive Agency

What is tested. The gap between what the assistant needs to do its job and what it is permitted to do. Every tool is inventoried with its arguments, its side effects, the identity it runs as and the confirmation it requires. Then each one is triggered from untrusted content rather than from the user.

ATLAS. AML.T0053 AI agent tool invocation, AML.T0086 exfiltration via tool invocation, AML.T0101 data destruction via tool invocation.

Evidence. The tool inventory with the privilege each call actually holds at run time, and a transcript for each tool that fired without a user asking for it.

Fix pattern. Least agency. Remove tools rather than restricting them in the prompt, split read and write into separate scopes, carry the end-user identity into every call, and put a human in the loop for anything irreversible. The GitHub MCP case from May 2025 turned on none of these being present.

LLM07:2025 System Prompt Leakage

What is tested. Whether the system prompt, tool schemas, retrieval configuration and guardrail wording can be recovered, and then, more importantly, what the recovered text discloses. The words themselves are rarely sensitive; the endpoints, allow-lists, business rules and occasional credentials inside them are.

ATLAS. AML.T0056 extract LLM system prompt.

Evidence. The recovered configuration, mapped item by item to the system it describes, with a note on what each disclosed item enables.

Fix pattern. Assume the prompt is public and design so that this costs nothing. Move secrets and authorization decisions out of the prompt and into the application, where they belong.

LLM08:2025 Vector and Embedding Weaknesses

What is tested. The retrieval layer as a system in its own right: who can write into the index, whether retrieval enforces the same access control as the source store, whether a planted passage can outrank the authoritative one, and whether tenants share a namespace or a cache.

ATLAS. AML.T0070 RAG poisoning, AML.T0071 false RAG entry injection, AML.T0064 gather RAG-indexed targets, AML.T0082 RAG credential harvesting.

Evidence. The index write path, a retrieval trace per test query showing which passages were returned, and the answer the assistant produced from a poisoned passage.

Fix pattern. Per-request authorization at retrieval time, tenant partitioning enforced server-side rather than by a filter parameter, provenance on every chunk, and monitoring for anomalous index writes.

LLM09:2025 Misinformation

What is tested. In a security audit this is assessed where a wrong answer causes a decision or a transaction: whether responses are grounded in retrievable sources, whether citations resolve to documents that support the claim, and what the interface does when the model has no basis for an answer.

ATLAS. Not an adversarial technique. It is a reliance failure, and it belongs in the report when the application design encourages unverified reliance.

Evidence. Examples where the assistant produced a confident answer with no supporting source, and the interface treatment that presented it as authoritative.

Fix pattern. Ground answers in retrieval, show citations that resolve, and make abstention a first-class response in the interface rather than something the model has to be argued into.

LLM10:2025 Unbounded Consumption

What is tested. Cost and availability treated as security properties: per-user, per-tenant and global limits, context inflation, recursive agent loops, and whether an unauthenticated visitor can drive inference spend or exhaust a shared quota. Agent architectures make this materially worse than a classic rate-limit test, because one request can fan out into many.

ATLAS. AML.T0034.002 agentic resource consumption.

Evidence. The observed limits, the point at which they stop applying, and the cost per unit of abuse where the provider exposes it.

Fix pattern. Budget caps per tenant and per session, a hard ceiling on agent iterations and tool calls, and alerting on spend anomalies rather than only on error rates.

Mapping the ten onto agentic risks and AI Act articles

Two mappings make the matrix useful outside the security team. The first connects the LLM list to the OWASP Top 10 for Agentic Applications 2026, so that an agentic system is not audited against a catalog written for chat. The second connects it to the EU AI Act obligations that the same evidence answers.

Coverage mapping: OWASP LLM 2025, agentic equivalents and AI Act articles
OWASP LLM 2025Agentic equivalentAI Act article the evidence supports
LLM01 Prompt InjectionASI01 Agent Goal HijackArt. 15 robustness and cybersecurity
LLM02 Sensitive Information DisclosureASI03 Identity and Privilege AbuseArt. 15; Art. 26(9) DPIA input
LLM03 Supply ChainASI04 Agentic Supply ChainArt. 15; Art. 17 quality management
LLM04 Data and Model PoisoningASI06 Memory and Context PoisoningArt. 15, named explicitly
LLM05 Improper Output HandlingASI05 Unexpected Code ExecutionArt. 15
LLM06 Excessive AgencyASI02 Tool Misuse and ExploitationArt. 14 human oversight; Art. 26(2)
LLM07 System Prompt LeakageASI03 Identity and Privilege AbuseArt. 15 confidentiality attacks
LLM08 Vector and Embedding WeaknessesASI06 Memory and Context PoisoningArt. 10 data governance; Art. 15
LLM09 MisinformationASI09 Human-Agent Trust ExploitationArt. 13 transparency to deployers
LLM10 Unbounded ConsumptionASI08 Cascading FailuresArt. 15 robustness
Article references indicate which obligation the technical evidence helps satisfy. They are not a legal opinion on whether the obligation applies to a given system.

Article 15 carries most of the load because it is the one that names this work. High-risk systems must be resilient against attempts by unauthorized third parties to alter their use, outputs or performance, and the article lists data poisoning, model poisoning, adversarial examples and confidentiality attacks as the AI-specific vulnerabilities to address. Those obligations apply to Annex III systems from 2 December 2027 and to Annex I product-embedded systems from 2 August 2028, following Regulation (EU) 2026/1744.

Turning the list into a report

A finished coverage matrix has ten rows, or twenty for an agentic system, and four columns: tested, findings, evidence reference, not-applicable reason. Fill the last column honestly. A RAG-free chatbot has no LLM08 findings and should say why rather than presenting a clean row as a result.

  • Severity comes from reach and consequence, not from payload novelty. A one-in-five injection into a tool that sends email outranks a reliable jailbreak of a read-only assistant.
  • Every finding carries a reproduction transcript. If it cannot be reproduced, it is an observation, and it belongs in a different section.
  • Every not-tested row carries a reason: out of scope, no test environment, destructive, or a control the customer declined to expose.
  • The executive summary states residual risk in plain language, including the risks that remain after every recommendation is implemented. For prompt injection that number is never zero.

Sources

  1. OWASP Top 10 for LLM Applications 2025 OWASP GenAI Security Project · 2025 Source of the ten official risk names and identifiers used throughout this annex.
  2. OWASP Top 10 for Agentic Applications 2026 OWASP GenAI Security Project · 2026
  3. MITRE ATLAS technique data MITRE · 2026 Source of every AML technique identifier cited above.
  4. OWASP AI Testing Guide OWASP · 2025
  5. OWASP LLM Verification Standard OWASP
  6. CVE-2025-6514 (mcp-remote command injection) NIST National Vulnerability Database · 2025
  7. Regulation (EU) 2024/1689, Articles 10, 13, 14, 15, 17 and 26 EUR-Lex · 2024
  8. Regulation (EU) 2026/1744 (Digital Omnibus on AI) EUR-Lex · 2026

Questions

Related questions

Is the OWASP LLM Top 10 a compliance standard?
No. It is an awareness and prioritization document published by the OWASP GenAI Security Project, with no conformity scheme behind it. It is useful precisely because it is common vocabulary: a finding filed as LLM06 means the same thing to your team, your auditor and your customer. Compliance obligations come from the AI Act and from sectoral law, and the OWASP catalog is one convenient way to organize the evidence for them.
What about the LLM Verification Standard?
OWASP also maintains an LLM Verification Standard as an incubator project, aimed at giving verifiable requirements rather than a risk list. It is worth tracking, and it is not yet the settled reference the OWASP Application Security Verification Standard is for web applications. Until it is, the Top 10 plus the AI Testing Guide remains the practical pairing.
Do we need to test all ten every time?
Test all ten for applicability every time; test in depth where the architecture supports the risk. A stateless assistant with no retrieval, no tools and no memory genuinely cannot exhibit LLM08, and saying so with a reason is a better use of the budget than manufacturing coverage.