LLM Security in 2026: The OWASP Top 10 Mapped to Controls and Tests

LLM security means building the system around a language model so that when the model is fooled, nothing important breaks. You cannot make the model itself immune: it reads instructions and data as one stream of tokens, and OWASP's 2026 guidance states plainly that no reliable prevention for prompt injection exists today. So the work moves to the code around it. Narrow what the model can reach, check every action it requests outside the model, cap what it can spend, and treat what it writes as untrusted input. The checklist most teams use is the OWASP Top 10 for LLM Applications, whose 2026 edition came out in August 2026. Below, each of its ten risks is mapped to what it looks like in a real application, the control that limits it, and a test you can run before release.

What are the OWASP Top 10 risks for LLM applications in 2026?

This is the 2026 list in its official order, read on genai.owasp.org on 2026-10-07. The controls and tests are condensed from the mitigation sections of the OWASP document, cut down to what a small team can actually run.

The list covers the model as a component inside your application. Once the model acts on its own, with tools, memory between sessions and actions downstream, OWASP points to a second list, the Top 10 for Agentic Applications, published in December 2025. Most production agents need both.

What changed in the 2026 list, and why does it matter?

The 2026 edition is the first one checked against incident data. The project gathered 7,714 incidents from public vulnerability databases and an AI-harm database, classified the 6,639 that had enough detail, and gave that record a quarter of the weight, with the practitioner vote carrying the other three quarters.

The order moved more than in earlier years:

• Excessive Agency rose to third. OWASP calls this the most consequential move: agents are where the damage is landing.
• Unbounded Consumption rose four places to sixth. Practitioners now weigh cost and resource exhaustion higher than the old rank did.
• Improper Output Handling fell from fifth to tenth, and now also covers the insecure code that assistants generate at scale.
• System Prompt Leakage became Hidden Context Exposure, which covers tool schemas, developer instructions and policy text as well as the system prompt.
• Misinformation is seventh, but OWASP's project leads single it out: voters ranked it near the bottom, the incident record near the top.

One detail is worth knowing before you plan your budget. Ranked by the raw incident record alone, prompt injection falls out of the top ten. OWASP reads this as a defense effect: teams fight injection hard, so fewer clean exploits reach public databases. It stays first because the surface exists everywhere a model reads untrusted input.

What are the top 3 AI security risks?

By the 2026 list: prompt injection, sensitive information disclosure and excessive agency. They are best read as one chain.

An injection enters through content the model reads: a support ticket, a web page, a calendar invite, an issue title. What it can do next depends on what data the model can see (risk two) and what the model can make happen (risk three). OWASP's prompt injection entry says most high-impact incidents on record became severe because the injection landed in a system whose tools or scopes let the model act with the user's privileges.

That gives a test you can run on a whiteboard. Simon Willison calls it the lethal trifecta and Meta calls its version the Rule of Two, and the OWASP document cites both: an agent that can read untrusted content, reach private data and communicate externally (or change state) has everything an attacker needs. Remove one leg and the worst outcome shrinks. OWASP says any agent with all three needs human approval for each action.

Why can't a prompt filter fix prompt injection?

Because the attacker adapts and the filter does not. Nasr et al. (2025) showed it: across 12 recent defenses, attacks that almost never worked in static tests succeeded more than 90% of the time against most of them once the attacker could adapt to the defense. Structural separation schemes such as StruQ were bypassed the same way.

Managed guardrails show the same pattern at the input boundary. ML6 tested four of them on 80,000 Dutch-language prompts with a 63/37 split between benign and harmful, using default or near-default settings (published 22 June 2026):

The language matters (ML6 tested Dutch on purpose) and tuned settings would score differently, but the conclusion holds for any language: a guardrail is one layer that lowers the attack rate. Assume some injections get through, and design so that a fooled model cannot do much.

What does a pen test miss on an LLM application?

A standard web pen test still matters: authentication, session handling, injection into your own APIs and infrastructure all apply to an LLM application. What it usually does not exercise:

• Indirect injection: testers type into the chat box. The dangerous instructions arrive through documents, retrieved pages, emails and tool results the model reads on its own.
• Tool permissions: a pen test checks whether an endpoint is authorized. It rarely asks whether the model should be able to call it at all, or with which scope.
• Memory and RAG persistence: an injection written into long-term memory or a vector store affects every later session that reads from it. A single test session will not show it.
• Cost: exhausting your inference budget is an attack on the 2026 list. Few pen test scopes include a spending test.
• Adaptive attackers: a fixed set of prompts measures what static attacks achieve, and Nasr et al. showed how far that understates an attacker who adapts.
• Output sinks: model output that reaches a browser, a terminal, a database or another agent needs the same review as user input, and often sits outside the tested scope.

When you commission one, put these items in the scope document by name and ask for the payloads used. If the tester cannot tell you how they reached the model through retrieved content, the indirect path was not tested.

Which AI security best practices cover most of the list?

Six controls, all of them code you own, close most of the ten risks. These AI security best practices come straight out of the OWASP mitigation sections.

1. Authorization lives outside the model. The model proposes; code decides. Each tool call goes through a check of the user, the action and its arguments, which OWASP calls complete mediation. It limits injection, excessive agency and hidden context exposure at once, because nothing in the prompt grants anything. The habit that puts a service key in the client bundle also puts API keys in system prompts; both come out the same way.
2. Least privilege for every tool. A tool that summarizes email gets read access, not send or delete. A product recommender gets read access to one table. Avoid open-ended tools (shell, fetch any URL) when a narrow one would do. If you are building an MCP server, the staged rollout in a 90-day MCP server build, read-only first and actions with a person in the loop later, applies this directly.
3. Access checks inside retrieval. Filter by tenant and document permission in the index query, before results come back. That covers both sensitive information disclosure and the cross-tenant case in vector weaknesses.
4. Hard caps, enforced in code. Token limits per user and per minute, spending ceilings that stop inference, and step, recursion and time limits on agents.
5. Output is untrusted input. Encode for the place it lands, use parameterized queries, block auto-rendered Markdown images and link previews, and strip control characters before output reaches a terminal or a log. Code the model writes for you is output too, and gets the same review.
6. A person approves what cannot be undone. Payments, external messages, deletions. Show the reviewer the exact action that will execute, not a summary of it. Where to draw that line, and what it costs, is in what your AI is not allowed to decide.

One lesson from a model-driven pipeline we run on our own site (letters built from our audit numbers) sits behind item 1: a rule in the prompt did not hold. A model drafting from our own measurements inverted a percentage, added two separate measurements as if they were one, and ranked two figures the wrong way round. A prompt instruction against this did not survive two rewrites of the prompt. Code that checks each claim against the source data before anything is sent did. That is OWASP's claim-check-act pattern for misinformation.

How do you test an LLM application before release?

Treat it like a regression suite that runs on every change to the prompt, the model, the tools or the retrieval sources.

• Build a payload set per risk, using the table above as the outline: injected instructions in every content type you ingest, cross-tenant queries, extraction attempts on the system prompt, oversized inputs, output that would execute in your renderer. Start with a handful of cases per risk, as long as they follow your own application's paths.
• Use open tools for coverage: NVIDIA's garak describes itself as an LLM vulnerability scanner. Microsoft's PyRIT is an open framework for finding risks in generative AI systems. promptfoo runs red-team and vulnerability scans from declarative configs and plugs into CI. OWASP's 2026 entry names AgentDojo and JailbreakBench as baselines. PortSwigger's Web Security Academy has hands-on labs for web LLM attacks if your team has never run one.
• Then test adaptively: give a red-teamer the full description of your defenses and let them iterate. OWASP says to reject attack success numbers that come from static tests only.
• Test the blast radius as well as the injection: for each tool, ask what happens when the model calls it with the worst valid arguments. If the answer is unacceptable, the fix is in permissions or approval, and no prompt change will hold it.
• Gate the release: a failing case blocks the deploy the way a failing unit test does. Re-run after every model upgrade: a new model version is a new dependency.

If your product also exposes pages or actions to outside AI agents, browser-agent-ready SaaS covers the consent and audit surface those agents expect from you.

What does the EU AI Act require for LLM security?

For high-risk AI systems, Article 15(5) of the AI Act requires resilience against attempts to alter the system's use, outputs or performance, with measures against data poisoning, model poisoning, adversarial examples, confidentiality attacks and model flaws. That maps onto LLM05 (poisoning), LLM02 (confidentiality) and LLM01 (inputs crafted to make the model err).

The dates moved in 2026. Regulation (EU) 2026/1744, the Digital Omnibus on AI, sets the high-risk requirements to apply from 2 December 2027 for systems listed in Annex III (employment, education, credit and similar uses) and from 2 August 2028 for AI built into products covered by the Annex I safety laws. Breaching provider obligations can be fined up to 15 million euros or 3% of worldwide annual turnover, whichever is higher. The 7% tier applies to prohibited practices, not to security gaps. Sources: the European Commission on the AI Omnibus and Article 99 of Regulation (EU) 2024/1689.

A customer support assistant or an internal search tool is usually not high-risk under Annex III. The OWASP controls are still worth doing, and if you later move into a high-risk use, the test reports become your evidence.

Where should a small team start?

If you are shipping your first LLM feature, or you inherited one that was built fast, this order gets the largest reduction for the least work:

Then keep it running: re-run the suite on every model, prompt or tool change, and review the risk list when OWASP updates it. If nobody on the team owns the system after launch, that is the gap Care covers: someone takes over the self-built system, stabilizes it and keeps watching it.