Prompt Injection & theOWASP LLM Top 10 in 2026

Every claim in this article sits under one constraint, so read it first. Prompt injection is not a solved problem, and no control described here — not classifiers, not delimiters, not adversarial training, not capability-based information-flow control — makes an agent with tool access safe. The correct frame throughout is defense-in-depth and blast-radius reduction: assume the model's instruction boundary will be bypassed, and constrain what that bypass is able to reach.

That is not our framing. It is the framing of the organizations that build and defend these systems. The OWASP GenAI LLM Top 10, Version 2026 opens with it. OpenAI writes that prompt injection “much like scams and social engineering on the web, is unlikely to ever be fully ‘solved’” and that it “remains an open challenge for agent security, and one we expect to continue working on for years to come.” Google DeepMind writesthat “even with model hardening, no model is completely immune,” and that indirect prompt injection “is not the kind of technical problem you ‘solve’ and move on.”

Stop trying to build a model that cannot be fooled. Build the system around it, so that when the model is fooled, and it will be, nothing important breaks.

— OWASP Top 10 for LLM Applications, Version 2026 — Letter from the Project Leads

The rest of this piece is the engineering consequence of that sentence. It covers what the two current OWASP lists actually say and how they changed, why the problem is structural rather than an implementation gap, the adaptive-attack evidence that invalidated most published defenses, the small set of architectural approaches that hold up and what they cost, the two structural checks worth running before any code exists, the incidents that show what a real exploit looks like, and a pre-production checklist.

Get the versions right, because both current OWASP lists are new and both are labeled “Version 2026.” The OWASP Top 10 for LLM Applications, Version 2026 is dated August 4, 2026. It is a different document from the OWASP Top 10 for Agentic Applications, Version 2026, published in December 2025. Citing one when you mean the other is the most common error in secondary writing on this topic.

The LLM list changed methodology for the first time in its history. Previous versions were built purely on practitioner judgment. For 2026, the project pulled together a corpus of 7,714 real incidents from public vulnerability databases and an AI-harm database, built classifiers that read them, and placed the 6,639 that carried enough detail to sort. The final ranking weights the community vote at three-quarters and the incident data at one quarter— deliberately, so that, in the project's words, one noisy year of data does not overturn the judgment of the people doing the work.

The most interesting result of that exercise concerns prompt injection itself, and it is worth understanding before you read the ranking. Practitioners rank prompt injection the number one risk. Rank the categories by the raw incident record instead, and it falls out of the top ten entirely. OWASP calls that gap a defense effect: teams fight injection hard, so fewer clean exploits reach a public database, and the public count understates the risk that mature teams already spend real money holding off. Low recorded incident volume in this category measures defensive spend, not low risk.

OWASP Top 10 for LLM Applications, Version 2026 (August 4, 2026), with movement against the 2025 list.

Four moves matter for anyone building agents. Excessive Agency climbed from sixth to third — OWASP calls it the most consequential move on the list, because the vote and the incident record agree that agentic deployments are where the damage is landing. Unbounded Consumption rose four places, from tenth to sixth. Improper Output Handling fell the furthest, from fifth to tenth, though it now also spans the insecure code that assistants generate at scale. And System Prompt Leakage was renamed and expanded into Hidden Context Exposure, a broader frame for the same failure to trust information that should have stayed out of reach.

The OWASP Top 10 for Agentic Applications, Version 2026 came out of the project's Agentic Security Initiative in December 2025. Its entries are numbered ASI01 through ASI10, and they describe failures that only exist once a model plans, holds memory, calls tools, and acts with delegated authority.

OWASP Top 10 for Agentic Applications, Version 2026 (December 2025) — ASI01 through ASI10.

The scope boundary between the two lists is stated explicitly in the 2026 LLM document, and it is the cleanest available answer to “which list applies to me.” The LLM list owns the risk when the model is a component inside your application. The moment that model becomes an actor — with tools it can call, memory it carries between sessions, and consequences it sets in motion downstream — the risk moves to the Agentic list. OWASP notes that many of the incidents it read sit right on that boundary, and instructs readers to pair the entries, because neither list covers that ground alone.

SQL injection had a fix. Parameterized queries work because the database engine receives the query structure and the data through separate channels, and the structure is fixed before user data arrives. There is no equivalent for a language model, and OWASP states the reason in one sentence.

LLMs make no architectural distinction between “instructions” and “data” (both are tokens on the same stream), so there is no clean equivalent to parameterized queries.

— OWASP Top 10 for LLM Applications, Version 2026 — LLM01:2026 Prompt Injection

That is the whole problem, and it explains why every in-band defense — every delimiter, marker, warning, hierarchy, or classifier — is a heuristic operating inside the same channel it is trying to police. It also explains why the definition is broader than most engineers assume: inputs need not be human-readable, need not arrive directly from a user, and need not be visible in the rendered interface to change model behavior.

On top of that base problem, OWASP names three deployment-time properties that turn a model-level weakness into a system-level breach. These are the three things to look for in your own architecture diagram.

• Context-window pooling: The model treats system prompt, user input, retrieved documents, tool outputs, conversation history, and memory as a single token stream, with no enforced trust boundary between them. Everything that lands in the window has the same standing as everything else.
• Memory persistence: An injection that writes to long-term memory, a RAG corpus, a vector store, or a hosted memory service taints every subsequent session that reads from that store. One successful write becomes a permanent compromise until someone finds and removes it — and nobody is looking, because it does not present as an incident.
• Agentic execution: When model output drives tool calls — file system, shell, email, cloud APIs, MCP servers, sub-agents — the blast radius extends from the chat surface to whatever those tools can reach. Tool outputs then re-enter the context window, which is what enables chained and self-replicating effects.

The third one deserves the emphasis it gets in the 2026 list. OWASP's own reading of the incident corpus is that most high-impact prompt-injection incidents on record became severe not because the injection was clever, but because it landed inside a system whose tools, scopes, or output-rendering capabilities let the compromised model act on the attacker's behalf at the user's privilege level. Severity is a property of your architecture, not of the payload.

There is also a taxonomy worth adopting for threat modeling, because it turns a vague fear into three answerable questions. OWASP characterizes any injection along three axes: delivery surface (direct input, retrieved content, tool output, tool connection channel, or persistent memory), propagation behavior (single-shot, multi-step kill chain, cross-session through memory or RAG, or self-replicating across agents), and encoding (plain text, base64 or other obfuscation, invisible Unicode, multimodal or steganographic, low-resource language). Decompose your scenario on those three axes before choosing mitigations, or you will buy a text filter for an image payload.

This is the most important section in the article, and if you take one citation away from it, take this one. In October 2025 a joint team from OpenAI, Anthropic, Google DeepMind, ETH Zurich and Northeastern University published “The Attacker Moves Second” (arXiv:2510.09023). The argument is methodological: defenses are typically evaluated against a static set of harmful attack strings, or against weak optimization methods that were not designed with the defense in mind. Evaluate them instead against an attacker who has read the defense and spends real compute against it, and the picture inverts.

Using gradient descent, reinforcement learning, random search, and human-guided exploration, the team bypassed twelve recent defenses with attack success above 90% for most of them. The sentence that should end most vendor conversations is the researchers' own observation that the majority of those defenses had originally reported near-zero attack success rates.

Static versus adaptive attack success rates. ASR = attack success rate; lower is better. Figures as published, as of August 2026.

One finding in that paper deserves separate emphasis because it changes how you should staff a red team: human red-teaming succeeded on 100% of scenarios where automated static attacks succeeded on 0%. A defense can be perfectly robust against every attack string in your test suite and fall to the first person who reads your design document.

This is not one anomalous paper. Zhan et al. (NAACL 2025 Findings) evaluated eight defenses against indirect prompt injection and bypassed all eight, with attack success consistently above 50% — one defense moving from a 9% baseline to above 50% once the attacker adapted. The pattern is stable across research groups, model families, and defense categories.

OWASP has now folded this into its own mitigation guidance for LLM01, which is a meaningful signal about where consensus sits. Control #11 in the 2026 list instructs readers to test against adaptive attackers who have read the deployed defense, and to reject static-only attack-success claims — baselining with AgentDojo and JailbreakBench, then red-teaming with the full defense specification disclosed to the testers.

Google DeepMind's layered-defense paper (arXiv:2505.14534, May 2025) is the single most useful public dataset on this question, because it publishes the same defenses measured twice: once against non-adaptive attacks and once against adaptive ones. Undefended Gemini 2.0 was already at 94.8–100% attack success for the strongest attack family, with attack triggers costing under $10 to generate.

Attack success rate (%), non-adaptive versus adaptive, per defense and attack family. Google DeepMind, arXiv:2505.14534, May 2025 — still at version 1 as of August 2026.

Read the Spotlighting row against the vendor claim. Microsoft's original Spotlighting paper reported attack success falling from above 50% to below 2%. Here it sits at 18.0% non-adaptive and 82.4% adaptive for one attack family. Read the Paraphrase row too: it genuinely helps against two attack families and collapses to 95.2% against the third. Defenses are attack-family-specific, which is exactly why single-number claims mislead.

Then read the paragraph that should be printed and pinned above any team's benchmark dashboard. On a 1,799-prompt non-adaptive evaluation set, attack success fell from 92% on Gemini 2.0 to 18% on Gemini 2.5 — a result that looks like a decisive generational improvement in robustness. The authors ran adaptive attacks anyway.

Had we not conducted further adaptive attacks… we would have incorrectly concluded that Gemini 2.5 exhibits a higher degree of robustness than it does.

— Google DeepMind, arXiv:2505.14534

Adversarial fine-tuning from Gemini 2.0 to 2.5 produced roughly a 47% average reduction in attack success. Two data points from inside that average show why the average is misleading: on one task family, Beam Search attack success went from 98.6% to 0, while TAP went from 100% to 94.6% — barely dented. Layering helped materially: a warning defense on top of the adversarially trained Gemini 2.5 brought attack success to 6.2% where 2.5 alone had been at 94.6%. That is a real result and it is also not zero.

Independent government evaluation reaches the same place. The US AI Safety Institute found that Claude 3.5 Sonnet's agent-hijacking rate moved from 11% on baseline attacks to 81% on novel model-specific attacks — the same model, the same task, a different attacker.

The consistent finding across the adaptive-attack literature is that defenses which try to detect or resist injection inside the model's channel degrade badly, and defenses which enforce constraints outside it hold up far better. Not perfectly. Far better. OWASP frames the same conclusion as a design rule: defense is architectural rather than interceptive.

The most rigorous published result is CaMeL (Google DeepMind, arXiv:2503.18813). It works by having a privileged model emit a program in a restricted language, with capability metadata attached to every value, and a deterministic interpreter enforcing an information-flow policy at execution time. The model never holds the authority; the interpreter does.

Out-of-band and architectural defenses with their published results and self-reported limits, as of August 2026.

CaMeL's security numbers are genuinely the best published: zero successful attacks across 949 runs with policies enabled, where the next-best defense in the same comparison allowed eight, and a Gemini 2.5 Pro configuration going from 300 successful attacks to zero. Now the costs, which vendors summarizing this paper tend to omit. Utility drops from 84% undefended to 77% with provable security on the headline measurement, and on a per-suite measurement with Claude 3.5 Sonnet it falls to 63.92% against 90.72% undefended — with the travel suite collapsing to 25.00%. It consumes 2.82× the input tokens and 2.73× the output tokens, the highest overhead of any defense in its comparison. And with no attack present at all, its policy engine triggers a user confirmation on 33.87% of prompts under the normal policy and 53.23% under the strict one. That is the friction budget you are actually buying.

A note on the two categories people most often mistake for prompt-injection defenses. Anthropic's Constitutional Classifiers target universal jailbreaks and CBRN content, not prompt injection — do not launder that result into an injection number. On prompt injection specifically, Anthropic's cleanest published figure comes from Claude for Chrome: autonomous mode across 123 test cases and 29 scenarios moved from 23.6% attack success without mitigations to 11.2% with, and a browser-specific challenge set from 35.7% to 0%. Two things about 11.2%: it is not near-zero, and it is a non-adaptive evaluation. Separately, off-the-shelf detectors are the weakest link in the chain — Protect AI Detector, PromptGuard, and Model Armor all exceeded 90% attack success under adaptive attack.

Finally, on formal claims: certified prompt-injection defenses do not exist as of August 2026. There is no credible certified or cryptographically provable defense. The closest published work is a machine-checked non-interference theorem in Lean for a lambda-calculus formalization with information-flow labels, which still lost two of 1,296 attacked runs, and CaMeL's capability-based control, undermined by its own side channels. A 2026 preprint argues that perfect prompt-injection prevention is mathematically impossible in shared-embedding architectures without enforced control/data separation — worth reading, but it is a three-author preprint with no venue, so treat it as a suggestive formalization rather than a settled result.

Design Patterns for Securing LLM Agents against Prompt Injections (arXiv:2506.08837) is the best available taxonomy of architectural options. Read it for the vocabulary, not for evidence: it is a taxonomy paper with zero quantitative results. Six patterns, each trading agent generality for a constraint an injection cannot argue its way past.

Design patterns for securing LLM agents (arXiv:2506.08837) — a taxonomy, published without quantitative evaluation.

The Dual LLM pattern is worth its history. Simon Willison proposed it in April 2023: a privileged LLM that holds tools and only sees trusted input, a quarantined LLM that reads untrusted content and holds no tools, and a deterministic controller passing opaque variable tokens between them so the privileged side never sees attacker-controlled text. It has no measured numbers — it is a design proposal, and its author's own assessment was “this solution is pretty bad!” He later endorsed CaMeL as the rigorous version of the same idea. That lineage is the clearest illustration in the field of a good instinct becoming a measurable system.

Now the counter-example, included because this article would be dishonest without it. Not every defense collapses under adaptive attack. An adaptive evaluation of out-of-band defenses (arXiv:2606.26479) tested Progent, a deterministic policy-enforcement layer, and found attack success dropping from 25.8% to 4.2% — with a hand-crafted adaptive attack reaching only 2.6%. The authors' framing is that “deterministic out-of-band enforcement is a harder target for an adaptive attacker than in-band detection.” They also caveat it clearly: this is a single configuration, Qwen2.5-7B on AgentDojo. Directional support for the architectural thesis; not a general result, and not a claim of safety.

If you implement nothing else from this article, run these two checks. Both are structural, both are checkable before any code exists, and OWASP now cites both inside its LLM01 mitigation guidance — which is a strong signal that the field has converged on them.

The first is Simon Willison's lethal trifecta. An agent that can simultaneously (1) access private data, (2) ingest untrusted content, and (3) communicate externally has the conditions for high-impact exploitation. Removing any one leg removes them. OWASP restates it as a pre-deployment check in the LLM01 entry, and it earns that placement because it is the rare security heuristic you can apply to a whiteboard sketch.

The second is Meta's Agents Rule of Two, which states the same constraint as a capability budget: an agent should satisfy at most two of processing untrusted input, accessing sensitive data, and changing state or communicating externally. OWASP treats the Rule of Two as a floor, not a ceiling — any agent with all three properties needs per-action human approval, and two-of-three configurations need an explicit written residual-risk assessment. Both NIST's adversarial machine learning taxonomy (AI 100-2 E2025) and joint CISA and Five Eyes operational-technology guidance endorse the rule. Note its one blind spot, which OWASP flags: it is silent on autonomy depth. A two-of-three agent running unattended for two hundred steps is not the same risk as one running for three.

One more control belongs in the same tier, because it is the one OWASP names as load-bearing for agentic deployments: hold credentials and state-change capability in application code, not in the model, and grant least privilege per operation. Route privileged calls through a deterministic policy engine that re-validates intent and arguments at execution time. Broad convenience permissions and multi-agent hops re-introduce the risk downstream, which is how a well-scoped agent quietly becomes an over-scoped one two sprints later.

Teams repeatedly treat the utility loss from a security control as something to engineer away. The published evidence says it is a property of the problem. SecFid (arXiv:2606.30783, ICML 2026) measured instruction fidelity against injection security across 1,168 examples and 48 configurations spanning models and defenses.

The two endpoints tell the story. The highest-fidelity configuration reached 96.5% fidelity at only 47.8% security. The most secure reached 99.3% security at 71.0% to 73.9% fidelity. The authors' conclusion is unambiguous: no model or defense achieves both objectives.

You can see the same shape in the individual results elsewhere in this article. CaMeL buys near-total attack prevention with a travel suite that collapses to 25% utility and confirmations on up to 53% of prompts. AgentDojo's best simple defense (a tool filter) reaches 6.84% attack success at 73.13% utility. Google's layered configuration reaches 6.2% attack success by adding a defense on top of adversarial training. Every credible defense is a point on a frontier, not a free improvement.

Decide the utility you are willing to lose before you choose the control, and decide it per workflow. A finance-approval agent can afford confirmations on half its prompts. A customer-facing summarizer cannot — which is a reason to give that agent no state-change capability at all, not a reason to run it unprotected.

— Frenchy Digital engineering principle

This is also why the sequencing matters. If you pick the architecture first — Action-Selector for a routing agent, Plan-Then-Execute for a known workflow, Code-Then-Execute where you can afford an interpreter — you are choosing your position on the frontier deliberately. If you build a maximally general agent and bolt on defenses afterwards, the frontier chooses for you, usually by making the product annoying enough that someone turns the controls off.

Benchmarks tell you about probability. Incidents tell you about shape. These five are worth knowing in detail because each one breaks a different assumption engineers commonly hold.

Documented prompt-injection and agent-security incidents, 2025–2026, with the engineering assumption each one invalidates.

EchoLeak (CVE-2025-32711, CVSS 9.3) is the reference case for zero-click indirect injection. A crafted email caused Microsoft 365 Copilot to exfiltrate organizational data with no user interaction, and OWASP's own write-up of it notes that it bypassed both the deployed prompt-injection classifier and the link-redaction filter. Two independent detective controls, both defeated by a single email.

ForcedLeak is the reference case for supply-chain drift inside your own allowlist. Noma Labs planted instructions in a Salesforce Agentforce Web-to-Lead submission that executed later during a normal employee interaction, and exfiltrated through an image URL pointing at a domain that sat on the Content Security Policy allowlist, had expired, and was purchased by the researchers for about $5. Salesforce patched it, enforcing trusted URLs and re-securing the domain. The lesson generalizes: every allowlist entry is a live dependency with an expiry date.

GhostApproval is the reference case for approval-surface failure, and the one most likely to affect your own developers today. Wiz demonstrated in July 2026 that symbolic links — a decades-old file-system behavior — defeated human-in-the-loop review across six AI coding assistants. The approval diff displayed a change to an innocuous settings file; the write resolved through the symlink to a different target, including a developer's authorized SSH keys. The researchers' formulation is the one to repeat internally: the human-in-the-loop security model only works if the loop provides accurate information.

s1ngularity is the reference case for the agent-as-weapon. In August 2025, malicious versions of the Nx build system were published to npm; the payload invoked the developer's already-installed AI CLIs with their safety flags stripped, using the agent itself for reconnaissance and to widen the exfiltration scope beyond predefined paths. Thousands of credentials and private repositories were exposed. If a developer machine has an agent with broad file-system access and a bypass flag, that machine's threat model now includes every package it installs.

The Model Context Protocol is now the default way tools reach agents, and its security properties are therefore your security properties. The current specification revision is 2026-07-28. It contains real normative requirements, most of them aimed squarely at the confused-deputy problem — the failure mode where your server does something with someone else's authority because a token turned up.

Normative requirements from the MCP specification, revision 2026-07-28, and the authorization security considerations.

The attack classes worth naming, because they have vocabulary now and your vendors will use it: tool poisoning, where an attacker compromises the tool interface itself — MCP tool descriptors, agent cards — so that the host agent treats attacker-authored text as trusted guidance; rug pulls, where a server that behaved correctly during review changes its behavior after adoption; and line jumping, where a tool description injects into the model's context at listing time, before any tool is actually invoked. OWASP maps these to ASI04 (Agentic Supply Chain Vulnerabilities) and treats third-party tool packages under LLM04.

OWASP's own scenario for this class cites three production proofs, all of which involve a low-privilege channel and a high-privilege agent: Invariant Labs exfiltrating private repositories through a poisoned GitHub issue; General Analysis dumping a production database through a Supabase MCP server running with the service role, bypassing row-level security; and a malicious postmark-mcppackage that BCC'd email to an attacker across an estimated 300 organizations.

Practically, that means the MCP servers your agent loads should be treated exactly as you treat any other third-party dependency with production credentials: pinned by version, reviewed at the tool-description level and not just the code level, monitored for composition changes, and scoped so that a compromised server cannot reach anything the workflow does not require. OWASP's own caveat applies — pinning does not stop a payload shipped inside the pinned version, nor tool-description poisoning that leaves the version unchanged.

This is the list we work through on agent engagements. It is ordered by leverage, not by effort: the first two items decide more about your exposure than the remaining ten combined, and they are free.

Frenchy Digital pre-production checklist for agents with tool access, 2026. Derived from OWASP LLM01:2026 mitigation guidance and the adaptive-attack literature.

Two implementation notes that catch teams out. First, on output validation: use structural validation in trusted application code, not a second model call. A schema-valid response can still carry a malicious SQL query or an exfiltration-formatted email body — schema validation catches format violations, not semantic manipulation, and adding a second LLM to check the first one adds a second injectable surface.

Second, on provenance channels: passing external content through a structurally separate, provenance-labeled channel does help, and OWASP includes it. But be honest about the ceiling — it reduces attack success in non-adaptive tests only. An attacker who knows the marking scheme can mimic it, and StruQ, which is a well-executed implementation of exactly this idea, was driven to 100% attack success under adaptive attack.

Every one of these has appeared in a real vendor conversation or a real internal design review. None are hypothetical, and each maps to a specific published finding above.

The Frenchy Digital red-flag list for agent security claims, 2026.

A vendor who cannot tell you the attempt budget, the attacker model, and whether the red team had read the defense has not measured security — they have measured their own test suite. Ask for the adaptive number, and treat its absence as the answer.

— Frenchy Digital buyer's principle

These are the bands Frenchy Digital uses to scope agent engineering in 2026. They assume the security architecture described above is in scope from the first sprint, because retrofitting a deterministic policy layer onto a shipped agent is substantially more expensive than designing one in.

Frenchy Digital cost bands for AI agent engagements, 2026.

Senior-led delivery runs $150 to $225 per hour, and ongoing retainers run $2,500 to $9,500 per month, covering model and dependency upgrades, adversarial test-suite expansion, incident response, and a quarterly technical review. Every engagement carries a 30-day post-launch warranty, and you receive a written scope with a fixed-price phased proposal within 5 business days of the discovery call.

One budgeting note. The security substrate is largely a fixed cost paid once and reused: the policy layer, the credential model, the audit pipeline, and the adversarial test harness carry over to every subsequent agent. The first agent pays for all of it. The fourth inherits it. Organizations that sequence their agent roadmap get considerably better economics than organizations that pilot four disconnected agents in parallel, each with its own bespoke guardrail and its own shared API key.

This section applies to the article itself as much as to the systems it describes. Everything above has a shelf life, and some of it has known weaknesses worth stating.

• Every defense number here is provisional: The adaptive-attack literature exists precisely because published numbers did not survive contact with a motivated attacker. Assume the same is true of the numbers that currently look good, including CaMeL's, IPIGuard's, and SIEVE's. The 2026 papers reporting near-zero static attack success have not yet been through what the 2024 and 2025 papers went through.
• Benchmark results do not transfer to your system: AgentDojo, WASP, and their descendants measure specific task suites with specific tool sets. The Dawn Song position paper's argument that snapshot benchmarks are structurally incapable of evaluating data isolation applies to all of them. Your own workflow, tool scopes, and data sensitivity dominate any leaderboard delta.
• Architectural defenses cost utility, and the cost is not always affordable: A travel-planning suite dropping to 25% utility under CaMeL is not a rounding error, it is a product that no longer works. Some workflows genuinely cannot pay the price, and the honest answer there is to reduce the agent's capabilities rather than to run it undefended and hope.
• Human-in-the-loop degrades under load: OWASP names approval fatigue explicitly as a limitation of confirmation-based controls. A control that fires on half of all prompts trains its reviewers to click through. Instrument approval latency and override rate, and treat a flat override rate as evidence the control has stopped working.
• Text-to-text attacks have no data-flow signature: Information-flow control cannot see an injection whose entire payload is convincing text — a phishing message the agent writes, or a deliberately wrong summary that a human then acts on. CaMeL self-reports this. It is the class of attack with the least published defensive work and the most obvious business impact.
• Multi-agent and long-horizon autonomy are under-evaluated: The Rule of Two is silent on autonomy depth. Almost all published attack success rates come from short-horizon single-agent tasks. A two-of-three agent running two hundred unattended steps across sub-agents is a different risk profile with almost no measurement behind it.
• Model names, prices, and benchmark scores in this field go stale in weeks: Every figure here is as of August 2026 and carries its source date. Re-verify anything you are about to put in a decision document, and never carry a leaderboard position forward without checking when the page was last updated — AgentDojo's has not moved since February 2025.

None of this argues against building agents. It argues for building them with the blast radius decided in advance, the measurement running from day one, and the honest expectation that a successful injection will eventually happen. OWASP's instruction is the right one to close on: work all ten entries, start at the top, and build each of them for the day the model is turned against you.