There is a slide going around, and it has a number on it.

The number is the share of attacks that some AI security product stopped, and it is large. The slide says AI threat defence is the new baseline — that any organisation running language models needs a detection layer in front of them, the way it once needed a firewall.

I want to be careful here, because the slide is not wrong. That is what makes it difficult. The products are real, the reduction is real, and the people selling them are not charlatans. But that number was produced under a particular set of conditions, and the conditions are the part that does not make it onto the slide.

Here is what does not fit the story. On 11 June 2025, Microsoft published a fix for a flaw in M365 Copilot — a command injection that let an unauthorised attacker disclose information over a network (CVE-2025-32711). Just under a year later, on 4 June 2026, another Copilot record landed in the same broad category: command injection, information disclosure over a network (CVE-2026-42824). Let me be precise about what that does and does not show. The public record does not tell you these are the same defect returning; the later one involves a materially different chain, and I am not going to claim continuity the record does not support. What it shows is a category that was still generating advisories a year after the fix that was meant to close it.

So the question is not whether AI is risky. You know it is. The question is narrower, and it is sitting on your desk this quarter: of the two things in front of you — the tooling spend and the architecture review — which one actually decides your exposure?

The flaw is in the channel, not in the model

Start with the mechanism, because everything else follows from it.

When a language model reads a document, an email, a web page, or the output of a tool, that content arrives in the same stream as your instructions. There is no separate wire for "this is what you should do" and "this is material you should consider." It is one channel. Which means a document your system reads can contain something that reads, to the model, exactly like something you said.

This is not my framing. It is NIST's. In its adversarial machine learning taxonomy, NIST writes that "underlying many of the security vulnerabilities in LLM applications is the fact that data and instructions are not provided in separate channels to the LLM, which allows attackers to use data channels to inject malicious instructions in inference-time attacks (a similar flaw to that which underlies decades-old SQL injection attacks)" (NIST, 2025). The original academic description of the attack against real deployed applications came from Greshake et al. (2023), who named it indirect prompt injection.

Hold onto the SQL comparison. It is the most useful thing in this piece and also the most commonly misread. People hear it as reassurance: we worked out SQL injection, we will work this out too. We did work out SQL injection — but look at how, and look at what "worked out" actually bought. It was not solved by getting better at spotting malicious strings. Input filtering was the era before the answer. The answer was parameterised queries: changing the interface so that data submitted as data could no longer be executed as instruction. The fix was structural. It changed how applications talk to databases.

It is also worth saying, since it matters later, that knowing the fix did not make the problem disappear. Injection still sits at A05 in the OWASP Top 10 for 2025, and SQL injection alone accounts for more than 14,000 CVEs (OWASP, 2025). That is not because parameterisation fails. Parameterisation works. It is that a fix which has to be built by hand, in every application, by teams with other priorities, gets built unevenly — and a structural fix closes a class only to the extent that people actually build it.

That distinction — filter harder versus change the interface — is the whole argument, and we will come back to it.

For now, one more piece of the mechanism. Is the separation problem simply not solved yet, or is something harder going on? Zverev et al. (2024) built a formal measure of instruction-data separation and tested it across models. Their finding, in their words: "all models fail to achieve high separation, and canonical mitigation techniques, such as prompt engineering and fine-tuning, either fail to substantially improve separation or reduce model utility." Note the shape of that result — the techniques that move the needle on separation tend to take capability with them. NIST reaches the same conclusion about the mitigation landscape, stating that current mitigations "do not offer full protection against all attacker techniques" (NIST, 2025).

An academic group measuring it directly and a federal standards body reviewing the field, arriving at the same place: the gap is open.

One qualification I owe you, because it is the strongest thing pointing the other way on the mechanism itself. "One channel" describes the models you can deploy today; it is not a law of nature. The same lead author who measured the separation gap has since proposed closing it inside the model: ASIDE, published at ICLR 2026, applies an orthogonal rotation to the embeddings of data tokens so that instructions and data occupy distinguishably different representations, reporting substantially higher separation without a performance penalty (Zverev et al., 2026). Other labs are working the same problem from the training side. So the honest statement is not that this is unsolvable — it is that the separation does not exist in the systems you are being sold this quarter, and a research result is not a procurement option. If that changes, the argument below changes with it.

The numbers on the slide were measured with the attacker standing still

Now the part that should change how you read a vendor datasheet.

Almost every published defence arrives with a protection figure. The figure is generated by running a benchmark: a fixed set of injection attempts, thrown at the defended system, and the proportion that succeed. This produces small, impressive numbers.

Then someone lets the attacker adapt.

One 2025 study did exactly that, at scale, across twelve recently published defences. It broke all twelve, reaching attack success above 90% on most of them — and the authors point out that most of those same defences had reported near-zero attack success when they were published (Nasr et al., 2025). The same work reports the gap directly on a named benchmark: two prompting defences implemented on AgentDojo showed attack success as low as 1% using the benchmark's own static attacks, and above 95% under a search-based adaptive attack. A training-based defence reporting 2% went to 96% on adaptive re-evaluation.

A separate group, in work appearing in Findings of NAACL 2025, evaluated eight indirect prompt injection defences built for LLM agents and bypassed all of them, consistently achieving over 50% attack success (Zhan et al., 2025).

And it is not only outside critics finding this. Google DeepMind published its own account of defending Gemini against indirect prompt injection, and the honesty in it is worth reading twice. Across their grid of eight defences and three attack techniques, they report that "in 16 out of 24 cases (8 defenses × 3 attacks), the adaptive attack is equal to or outperforms the non-adaptive counterpart." On one evaluation set, attack success ran at 92% against Gemini 2.0 and dropped to 18% on Gemini 2.5 — and they write: "Had we not conducted further adaptive attacks and evaluations, we would have incorrectly concluded that Gemini 2.5 exhibits a higher degree of robustness than it does" (Shi et al., 2025).

That is a defender, evaluating its own production model, saying the flattering number would have misled them.

The pattern extends to the products themselves. Independent academic testing drove attack success above 90% against three guardrail classifiers using a search-based attack with the detector's own confidence score fed back to the attacker; the most resistant of the four tested still reached 71% (Nasr et al., 2025). A different group testing six protection systems, including Microsoft's Azure Prompt Shield and Meta's Prompt Guard, reported that both of its methods could evade detection "while maintaining adversarial utility achieving in some instances up to 100% evasion success" (Hackett et al., 2025).

NIST names the methodological failure at the root of this, though it does so in the context of adversarial machine learning evaluation generally rather than prompt-injection guardrails specifically: "The field has a history of publishing defenses evaluated under relatively weak adversarial models that are subsequently broken by more powerful attacks. Mitigations need to be evaluated against strong adaptive attacks" (NIST, 2025).

One caution before anyone quotes a figure from the paragraphs above. The authors of the twelve-defence study state plainly that their robustness numbers are not necessarily comparable across defences. There is no single residual failure rate for defended systems, and I am not offering one. Every number above belongs to a particular defence, on a particular benchmark, in a particular evaluation setting, and it should not travel without them. These are also benchmark rates, not field incident rates. Nothing I found measures how benchmark residuals translate into real-world compromise.

What the defences do buy, at full strength

If the piece stopped there it would be making a claim the evidence does not support, so let me put the other case as strongly as I can.

Defences work. They do not close, but they move the number by large factors, and dismissing them would be its own kind of malpractice.

Adversarial fine-tuning cut attack success against Gemini 2.5 by roughly 47% on average across three attack techniques — an average that includes the Calendar Event scenario, which sat outside the adversarial training data (Shi et al., 2025). And an independent adaptive re-evaluation of out-of-band defences found Progent cutting mean attack success about sixfold, from 25.8% to 4.2%, with a hand-built adaptive attack unable to push it back up — though the same authors are careful to say how limited that stress test was, so it is a promising data point rather than a settled one (Narisetty et al., 2026).

And then there is the result that arrived a week before I wrote this, which is the strongest of the lot. In the Claude Opus 5 System Card, published on 24 July 2026, Anthropic reports that with its "auto mode" safeguards enabled, no attack succeeded against Opus 5 across all 129 browser-use scenarios — a zero, in an evaluation section explicitly about robustness against adaptive attackers, where professional red-teamers got ten attempts per scenario. The same model without those safeguards scored 3.70%.

I want to give that its full weight. It is the most current and most prominent evidence that this gap can be closed in practice, it comes from a lab that cites the same adaptive-attack literature I quoted above, and it is a zero where I have spent several paragraphs telling you not to expect one.

Two things about it are worth your attention, and the second one cuts against me.

First, read what produced the zero. Anthropic describes auto mode as combining "prompt injection probes that flag malicious tool results and a classifier that blocks potentially dangerous tool calls, acting on incoming data and outgoing actions respectively so that the two layers fail independently." One layer watches what comes in. The other sits on the way out, at the point where the agent tries to act. The model alone did not reach zero — it reached 3.70%. The system around it reached zero, and half of that system is a check on actions rather than on text.

Second, and I would rather say this than have you notice it yourself: that outgoing layer is a classifier, and classifiers are the thing I spent the previous section showing you fall over under determined optimisation. It sits at the action boundary, which is a better place to stand than the input, but it is still something making a judgement call, not a capability the agent structurally cannot reach. That is a weaker claim than CaMeL's provable restriction, and I should not blur the two. The evaluation also used professional red-teamers with ten attempts per scenario — a serious test, and not the same test as the automated search and gradient optimisation that broke twelve published defences. Elsewhere in the same card, on a benchmark built with Gray Swan, the UK AI Security Institute, the US Center for AI Standards and Innovation and other model developers, the figure is not zero: an attacker succeeded against Opus 5 2.0% of the time within fifteen attempts.

So the honest reading is narrower than I would like. The result does not show that detection has been solved, and it does not show that architecture is unnecessary. What it does show is that the numbers moved when the defence moved closer to the action — and that the model on its own was not what got there.

Both of the earlier results come with their authors' own limits attached. In the same evaluation that produced the 47% average, one attack technique still achieved 94.6% attack success in the Calendar Event scenario against the hardened model. And the DeepMind team is explicit about the ceiling on what training can promise: because they cannot cover the entire spectrum of possible attacks, adversarial training "provides protection against known attacks; it may provide some amount of protection against other attacks but since they are unknown, it is unquantifiable" (Shi et al., 2025).

And the strongest result of the lot runs in the direction this piece is heading. CaMeL takes the plan from the trusted instruction and refuses to let anything the system later reads change it — its authors describe extracting the control and data flows from the trusted query so that "the untrusted data retrieved by the LLM can never impact the program flow" — then checks capabilities at the moment a tool is called. It solves 77% of AgentDojo tasks with provable security, against 84% for an undefended system (Debenedetti et al., 2025). That is a real security guarantee at a measurable price.

Read the shape of that carefully. The design that achieves the strongest result does not work by making the model harder to fool. It works by ensuring that fooling the model does not get the attacker anything. The model still reads the poisoned document. The system just is not arranged so that reading it matters.

CaMeL's own authors are careful about what they have and have not done. They note that while control flow is protected, data flow can still be manipulated — an attacker can affect the values passed within an allowed control flow, which they compare directly to an SQL injection that manipulates query parameters rather than query structure. And they say plainly that their approach "is not perfect and does not completely address every potential attack vector."

So: not futility. Not a solved problem either. A problem where the interventions that work best are the ones that change what the system is allowed to do.

Where the guidance points, and where I go further than it does

Let me separate two things carefully here, because the temptation to blur them is strong and I nearly did.

NIST's taxonomy is a catalogue, not a ranking. It documents input and output filtering, adversarial training, detection and several other mitigation families as first-class categories, and it does not tell you that one of them matters more than the others. So I am not going to claim NIST endorses the argument I am making. What NIST does say, in the taxonomy's own words, is this: "Because current mitigations do not offer full protection against all attacker techniques, application designers may design systems with the assumption that prompt injection attacks are possible if a model is exposed to untrusted input sources, such as by using multiple LLMs with different permissions or by allowing models to interact with potentially untrustworthy data sources only through well-defined interfaces" (NIST, 2025).

That passage is a design instruction, and it is the one I keep coming back to. Assume it succeeds. Design for a model that has already been captured. But note what it is and is not: it is one option among many that NIST puts on the table, not the option NIST tells you to pick.

There is a related, narrower point in NIST's control-overlay work for securing AI systems. The overlays, it says, "will not be a comprehensive set of controls for securing an enterprise and will assume that certain controls are already in place (e.g., organization-wide policies, procedures, and implementations of access control for datasets and services, account management, identification and authentication, configuration management, incident response)" (NIST, 2025b).

Read that for exactly what it establishes and no more: the AI-specific overlay presumes ordinary enterprise security hygiene underneath it. It is a statement about prerequisites, not a claim that architecture beats detection. I find it useful because it locates the AI layer on top of access control you were supposed to have anyway — but that is me drawing an implication, not NIST ranking anything. The same instinct shows up in the multinational guidance on adopting agentic AI systems that CISA released on 1 May 2026, in collaboration with the Australian Signals Directorate's Australian Cyber Security Centre and other international and U.S. partners (CISA et al., 2026): the response to agentic risk is framed as designing, deploying and operating these systems securely, not as a product you place in front of them.

Now the honest part. Not one of these bodies says what I am about to say. NIST catalogues detection alongside architecture without ranking them. The CISA-led guidance is about adopting agentic systems carefully, not about where to put your next dollar. Google DeepMind's team, having spent a paper hardening a production model, advocates adversarial training "as a necessary but not sufficient protection mechanism" and pushes the field toward defence in depth "that provide mitigations at both the model and system level" (Shi et al., 2025). And Article 15(5) of the EU AI Act names detection among the measures a high-risk system is expected to include where appropriate. Every source I have put in front of you prescribes both layers. None of them tells you which one decides your exposure.

That last step is mine, and I will own it rather than dress it in someone else's authority: I think detection is not the layer where the decision gets made. The evidence I can point to for that is the shape of the results rather than anybody's recommendation — the defences that collapse under optimisation are the ones asking the model to judge text, and the results that hold up best are the ones that narrow what the system can do with the judgement it reaches. That is an inference. It is the one this piece is for. Weigh it as a practitioner's read of the evidence, not as guidance handed down by a standards body.

What this costs, honestly

I do not want to sell containment as a free lunch, because it is not one.

The strongest published containment result carries a measurable utility cost: roughly seven percentage points of task completion, in CaMeL's case, for the security guarantee. That is not nothing when the business case for the agent was efficiency in the first place.

There is a harder problem than the cost, and it is the one that should temper how you read the advice at the end of this piece. Designs of CaMeL's kind are still, as far as I can tell, largely research artefacts rather than things you can buy and switch on — more than a year after publication I am not aware of them being common in production. That is my read rather than a measured finding, and it cuts against the practicality of what I am recommending: if the architectural option is not yet a product, then telling you it is the real decision is easy for me to write and expensive for you to act on. The honest version is that this is a design conversation with your own engineers, and it will be slower than a procurement cycle.

There is also a serious technical objection to the way containment is usually implemented. A 2026 position paper on system-level defences argues that fixed, task-agnostic permission rules are the wrong shape for real work, because "dynamic replanning and security policy updates are often necessary for dynamic tasks and realistic environments" (Xiang et al., 2026). The same authors point to the limitations of existing benchmarks "that can create a false sense of utility and security" — a caution that applies to the containment numbers I quoted above as much as to anyone else's.

And there is law, though less absolutely than I first wrote it. Article 15(5) of the EU AI Act requires high-risk AI systems to be resilient against unauthorised third parties exploiting system vulnerabilities, and says the technical solutions addressing AI-specific vulnerabilities "shall include, where appropriate, measures to prevent, detect, respond to, resolve and control" such attacks (European Parliament and Council, 2024). Note the qualifier, and note that detection sits in a list of five co-equal measures rather than being singled out. It is not an unconditional mandate to buy a detection product. It is a regulator naming detection among the things a compliant high-risk system is expected to have thought about — which is still enough that you cannot simply architect your way out of considering it.

So the argument is not architecture instead of detection — and if you take one thing from this piece, take that. Buy both. My claim is narrower and it is a claim about sequence and about who owns what: one of these is a decision that someone in your organisation has to make and live with, and the other is a layer you can procure. They have been getting swapped, and the swap is comfortable because a purchase order feels like a resolution.

The question to ask on Monday

Here is how I would use all of this in an actual review. It is my judgment rather than a finding from a source — and I should say at once that the shape of it is not original to me.

Simon Willison named the pattern in June 2025 as the "lethal trifecta": private data, exposure to untrusted content, and the ability to communicate externally, where holding all three at once is what makes an agent exploitable (Willison, 2025). Meta later turned the same insight into a design rule, the "Agents Rule of Two", holding that an agent should satisfy at most two of processing untrusted input, accessing sensitive data, and changing state or communicating externally — and that when all three are genuinely needed, the agent should run under human supervision (Meta, 2025). OWASP's LLM01 entry prescribes much the same defensive posture. What follows is my version of that idea, aimed at a decision-maker rather than an engineer, and the credit for the underlying framing belongs to them.

Assume the model is perfectly obedient to whoever wrote the last document it read. Not "might be tricked." Assume it. Then walk the system and ask four questions.

What untrusted content does this system ingest? Not "could it be exposed to" — what does it actually read, today, that someone outside your organisation can write? Email bodies. Shared documents. Web pages. Support tickets. Tool output from a third party.

What capability does it hold while it is reading that? Which credentials, which data, which tools, which systems of record.

Which of its actions cannot be undone? Sending, paying, deleting, publishing, granting.

And then: what is the blast radius when the instruction succeeds? Not if.

Notice what those four questions have in common. Not one of them has a product as its answer. They are all questions about how the system is put together and what it is permitted to do — which means they are answered by whoever owns the architecture, not by whoever owns the security budget. If the honest answer on capability is "everything the user can do," and the honest answer on blast radius is "irreversible," no detection layer will save that design. It will only reduce how often it gets tested.

The bill for the interface

The SQL comparison, one last time.

SQL injection stopped being an unsolved problem, and it did not stop because detection finally got good enough. It stopped because the industry changed the interface between code and data so that the ambiguity could not arise. That was expensive. It was structural. It touched every application. And it was nobody's product — you could not buy your way to parameterised queries. You had to change how your systems spoke to each other.

It is also why injection is still on the OWASP Top 10 in 2025. The answer was known and the answer worked; it just had to be built, application by application, by people who could have shipped something else that quarter instead. That is the honest version of the precedent, and it is the less comfortable one.

The same bill is now arriving for systems that read the world and act on it. Some of it will be paid in architecture that separates the part that plans from the part that touches untrusted input. Some in permissions that look uncomfortably narrow next to the demo. Some in agents that get told no.

So buy the detection layer. The law may require it, and the evidence says it will genuinely lower your odds. Just do not let the purchase order close the question — because the question it appears to answer is the one it cannot. What this system is permitted to do with input you do not control is a design decision. And design decisions do not come with vendors.

---

Provenance and verification

This piece was produced by an automated writing pipeline with an isolated adversarial review stage. Everything below is a record of what that process actually did — it is reported as logged, including where the process was weakest.

Adversarial review

  • Rounds run: 5 of a cap of 5. Tier: flagship, reviewed by a three-lens panel (sourcing/fabrication, domain accuracy, counter-case). Each reviewer read only the draft — never the author's research notes, sources, or citations — and re-sourced every claim independently.
  • Verification guarantee: `external-truth` — reviewers confirmed claims against live external sources rather than checking the draft for internal consistency.
  • Final round result: 90 of 90 claims verified; 0 wrong, 0 unsupported, 0 misrepresented; no blocking issues. The review loop terminated `STOP-CLEAN`.

Earlier rounds did not come back clean, and the corrections mattered. Round-by-round, as logged:

| Round | Claims checked | Verified | Wrong | Unsupported | Misrepresented | Outcome | |---|---|---|---|---|---|---| | 1 | 78 | 71 | 1 | 4 | 2 | routed for correction | | 2 | 84 | 78 | 0 | 1 | 5 | routed for correction | | 3 | 104 | 99 | 0 | 3 | 2 | routed for correction | | 4 | 98 | 91 | 0 | 4 | 3 | routed for correction | | 5 | 90 | 90 | 0 | 0 | 0 | STOP-CLEAN |

Defects the panel caught and the author corrected, in order: a stated interval between two CVEs that was wrong in the direction that flattered the argument; an overstated claim that SQL injection had been solved; an attribution to OWASP of a statement OWASP does not make; a material omission of the strongest contrary result then available; institutional endorsement implied for a ranking no cited body actually makes; a dropped "where appropriate" qualifier on EU AI Act Article 15(5); and missing credit to prior art that the closing framework draws on.

Sourcing and originality

  • Source policy: deterministic check clean — every load-bearing claim rests on two or more independent, admissible Tier 1–2 origins.
  • Originality: checked with guarantee `source-comparison` against a captured corpus of 55 source excerpts; 20 flagged passages, all remedied (quoted and attributed, rewritten, or credited). Deterministic verifier reports clean.
  • Placeholders: every unresolved-fact marker was resolved against a primary source or cut. None remain.

Load-bearing claims and their sources

These are the claims the argument rests on. Each was required to hold two or more independent origins at Tier 1–2. Every row here is a sourced finding, not the author's opinion — the author's own judgments are listed separately below.

| Claim | Tier | ≥2 independent origins | Sources | |---|---|---|---| | Instructions and data are not carried in separate channels in current LLM-integrated systems: the model receives one combined text stream, and that is the structural cause of prompt… | tier2_institutional + tier1_primary | yes | 1 · 2 | | No deployed mitigation - prompt engineering, fine-tuning, spotlighting or filtering - achieves full instruction-data separation; an empirical formal measure and NIST's own review of the… | tier1_primary + tier2_institutional | yes | 1 · 2 | | Defences that report near-zero failure under static evaluation fail at high rates when the evaluation is adaptive. One 2025 systematic study bypassed 12 recent defences at attack success… | tier1_primary + tier2_institutional | yes | 1 · 2 · 3 | | The static-versus-adaptive gap is measured, not asserted: on the AgentDojo benchmark two prompting defences showed attack success as low as 1% under the benchmark's own static attacks and… | tier1_primary + tier2_institutional | yes | 1 · 2 | | The same pattern appears in a model vendor's own published evaluation: Google DeepMind reports adaptive attacks equalled or beat their non-adaptive counterparts in 16 of 24 cases, and that… | tier1_primary + tier2_institutional | yes | 1 · 2 | | NIST states the field's evaluation-methodology failure explicitly: defences published under relatively weak adversarial models are subsequently broken by more powerful attacks, and… | tier2_institutional + tier1_primary | yes | 1 · 2 | | Commercially sold prompt-injection detection is not full protection. NIST states plainly that current mitigations do not offer full protection against all attacker techniques; independent… | tier2_institutional + tier1_primary | yes | 1 · 2 · 3 | | NIST's prescription is architectural, not model-side: because current mitigations do not offer full protection, application designers may design systems on the ASSUMPTION that prompt… | tier2_institutional + tier1_primary | yes | 1 · 2 | | Official AI-security guidance treats conventional access control as the assumed prerequisite baseline, not as something an AI-specific product substitutes for: NIST's control-overlay… | tier2_institutional + tier1_primary | yes | 1 · 2 |

What in this piece is NivaLogic's judgment, not a sourced finding

This distinction is the reason the piece was sent back for correction twice, so it is stated plainly here:

  • The central ranking — that the architectural decision is what determines exposure, and detection is a layer that cannot substitute for it — is NivaLogic's own inference. No cited body endorses it. NIST's taxonomy catalogues mitigation families, including filtering, adversarial training and detection, without ranking them. The CISA-led guidance, Google DeepMind's report, and EU AI Act Article 15(5) all prescribe both model-level and system-level measures. Weigh the ranking as a practitioner's read of the evidence.
  • The feasibility caveat — that CaMeL-style designs remain largely research artefacts rather than purchasable products — is the author's read, explicitly marked as such in the text, not a measured finding.
  • The reading of the Claude Opus 5 result — that the safeguard reaching zero acts on outgoing actions as well as incoming data — is the author's interpretation of figures that are themselves quoted accurately. The text also states the counter-case against that reading.

Known limitations of this record

  • Source-policy coverage gap. Several sources central to the piece match no tier in the pipeline's source policy: `eur-lex.europa.eu` (the authoritative EU AI Act text), `owasp.org`, `anthropic.com`, `simonwillison.net` and `ai.meta.com`. None is blocked, and reviewers verified each word-for-word against the live source, but under the policy they cannot carry a load-bearing claim. The following points are therefore carried as non-load-bearing for that reason alone, not because of any doubt about them: EU AI Act Article 15(5); the OWASP Top 10:2025 injection figures; the Claude Opus 5 System Card results; and the prior-art credits to Willison and Meta. National cyber-security agency guidance (`ncsc.gov.uk`, `cyber.gov.au`) hit the same gap and was excluded from the spine entirely.
  • Benchmark rates are not incident rates. Every attack-success figure in this piece comes from a benchmark under a stated evaluation setting. No source found measures how those figures translate into real-world compromise, and the piece does not claim they do.
  • Single-origin figures are attributed in the text rather than asserted, including CaMeL's task-completion numbers and every figure from the Claude Opus 5 System Card, which is a vendor evaluating its own product.
  • Reviewer access limits. Some primary PDFs intermittently resisted automated extraction, and `cisa.gov` and `eur-lex.europa.eu` returned blocks to direct fetching in several rounds. Where that happened, reviewers corroborated against independent reproductions and logged it rather than claiming verification they had not performed.

---

References

Anthropic. (2026, July 24). Claude Opus 5 system card. https://www-cdn.anthropic.com/c5fbac3f0b1280a933ebd26d3cb8bb9f5bdeaf48/Claude%20Opus%205%20System%20Card.pdf

Cybersecurity and Infrastructure Security Agency, Australian Signals Directorate's Australian Cyber Security Centre, and international and U.S. partners. (2026, May 1). Careful adoption of agentic AI services. https://www.cisa.gov/resources-tools/resources/careful-adoption-agentic-ai-services

Debenedetti, E., Shumailov, I., Fan, T., Hayes, J., Carlini, N., Fabian, D., Kern, C., Shi, C., Terzis, A., & Tramèr, F. (2025). Defeating prompt injections by design. arXiv:2503.18813. https://arxiv.org/abs/2503.18813

European Parliament and Council. (2024). Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 15. EUR-Lex, CELEX 32024R1689. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689

Greshake, K., Abdelnabi, S., Mishra, S., Endres, C., Holz, T., & Fritz, M. (2023). Not what you've signed up for: Compromising real-world LLM-integrated applications with indirect prompt injection. arXiv:2302.12173. https://arxiv.org/abs/2302.12173

Hackett, W., Birch, L., Trawicki, S., Suri, N., & Garraghan, P. (2025). Bypassing LLM guardrails: An empirical analysis of evasion attacks against prompt injection and jailbreak detection systems. arXiv:2504.11168. https://arxiv.org/abs/2504.11168

Narisetty, P., Kore, S. N. B., Kattamanchi, U. K. R., & Kumarapu, J. (2026). Adaptive evaluation of out-of-band defenses against prompt injection in LLM agents. arXiv:2606.26479. https://arxiv.org/abs/2606.26479

Nasr, M., Carlini, N., Sitawarin, C., Schulhoff, S. V., Hayes, J., Ilie, M., Pluto, J., Song, S., Chaudhari, H., Shumailov, I., Thakurta, A., Xiao, K. Y., Terzis, A., & Tramèr, F. (2025). The attacker moves second: Stronger adaptive attacks bypass defenses against LLM jailbreaks and prompt injections. arXiv:2510.09023. https://arxiv.org/abs/2510.09023

National Institute of Standards and Technology. (2025). Adversarial machine learning: A taxonomy and terminology of attacks and mitigations (NIST AI 100-2e2025). https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2e2025.pdf

National Institute of Standards and Technology. (2025b). SP 800-53 control overlays for securing AI systems (COSAIS) — concept paper. https://csrc.nist.gov/csrc/media/Projects/cosais/documents/NIST-Overlays-SecuringAI-concept-paper.pdf

Meta. (2025). Agents rule of two: A practical approach to AI agent security. https://ai.meta.com/blog/practical-ai-agent-security/

National Vulnerability Database. (2025). CVE-2025-32711. https://nvd.nist.gov/vuln/detail/CVE-2025-32711

National Vulnerability Database. (2026). CVE-2026-42824. https://nvd.nist.gov/vuln/detail/CVE-2026-42824

OWASP. (2025). A05:2025 — Injection. OWASP Top 10:2025. https://owasp.org/Top10/2025/A05_2025-Injection/

Shi, C., Lin, S., Song, S., Hayes, J., Shumailov, I., Yona, I., Pluto, J., Pappu, A., Choquette-Choo, C. A., Nasr, M., Sitawarin, C., Gibson, G., Terzis, A., & Flynn, J. (2025). Lessons from defending Gemini against indirect prompt injections. arXiv:2505.14534. https://arxiv.org/abs/2505.14534

Willison, S. (2025, June 16). The lethal trifecta for AI agents: Private data, untrusted content, and external communication. https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/

Xiang, C., Zagieboylo, D., Ghosh, S., Kariyappa, S., Greshake, K., Xiao, H., Xiao, C., & Suh, G. E. (2026). Architecting secure AI agents: Perspectives on system-level defenses against indirect prompt injection attacks. arXiv:2603.30016. https://arxiv.org/abs/2603.30016

Zhan, Q., Fang, R., Panchal, H. S., & Kang, D. (2025). Adaptive attacks break defenses against indirect prompt injection attacks on LLM agents. Findings of NAACL 2025. arXiv:2503.00061. https://arxiv.org/abs/2503.00061

Zverev, E., Abdelnabi, S., Tabesh, S., Fritz, M., & Lampert, C. H. (2024). Can LLMs separate instructions from data? And what do we even mean by that? arXiv:2403.06833. https://arxiv.org/abs/2403.06833

Zverev, E., et al. (2026). ASIDE: Architectural separation of instructions and data in language models. ICLR 2026. arXiv:2503.10566. https://arxiv.org/abs/2503.10566