4.7% at one attempt, 63% at a hundred

TL;DR. Published system card figures give indirect prompt injection success in agentic coding environments at 4.7% at one attempt, 33.6% at ten, and 63.0% at a hundred, and a later card gives GUI agent figures of 17.8% at one attempt rising to 78.6% by the two hundredth. Those are frontier models with active defences. The arithmetic is the same one as the previous article, with the sign reversed: reliability decays across repeated attempts and so does security, because an attacker chooses how many times to try. EchoLeak, CVE-2025-32711 at CVSS 9.3, was the first known zero-click attack on an AI agent, where a crafted email planted instructions a copilot later retrieved as context. Cisco's 2026 assessment found injection weaknesses in 73% of audited production deployments, with 83% of organisations planning agentic AI and 29% feeling ready to deploy it securely.

---

Status: established, and the strongest figures come from the developers themselves. Sources include published model system cards, the OWASP Top 10 for LLM Applications and its 2026 agentic companion, the EchoLeak CVE record, and vendor security surveys which are labelled where used. Disclosure: one set of system card figures comes from Anthropic, which makes the model used in drafting parts of this site. This article describes measured outcomes and defensive posture. It contains no attack technique.

---

The numbers that matter are the ones with an attempt count

A model system card published in November 2025 reported indirect prompt injection success in agentic coding environments, measured with an external red-teaming tool, at three attempt levels.

4.7% at one attempt. 33.6% at ten. 63.0% at a hundred.

A later card reported a GUI-based agent at 17.8% for a single attempt without safeguards, reaching 78.6% by the two hundredth.

Both sets are self-published by developers, on their own models, with defences active. That is a costly disclosure against interest and it is the most useful evidence in this subject.

And the single-attempt figure is the one that travels. "Under 5%" is a reassuring number. It describes an attacker who tries once, and no attacker tries once.

Which is the previous article's arithmetic, reversed

Agent reliability established that a 61% single-attempt success rate becomes 25% across eight consecutive attempts, because a customer gets one try and every attempt must succeed.

Security runs the same compounding in the opposite direction. The defender must succeed every time. The attacker needs to succeed once.

A defence holding 95% of the time fails within a hundred attempts with near certainty, and one analysis puts it in operational terms: a 1% per-attempt failure rate against an agent running thousands of times a day still produces dozens of successful attacks.

So the two articles describe one phenomenon. Repeated attempts move a per-attempt rate toward a certainty, and which certainty depends only on whether you need all of them to work or one of them.

The reporting convention is identical in both cases and wrong in both. Reliability is quoted at pass@1. Security is quoted at one attempt. Neither describes the situation the number is used to reason about.

What EchoLeak established

EchoLeak, recorded as CVE-2025-32711 at CVSS 9.3, was the first known zero-click attack against an AI agent.

A single crafted email planted hidden instructions that Microsoft 365 Copilot later retrieved as context, causing it to exfiltrate data from the user's environment with no clicks and no user interaction.

Microsoft patched it server-side and no in-the-wild exploitation was confirmed.

The significance is structural rather than incidental. The attack surface was the document, not the user. Nothing the user did was wrong, and no user action was required, which removes the entire layer of defence that security awareness training addresses.

And the technique generalises to any agent that reads untrusted content, which is most of them.

The condition that makes it catastrophic

Simon Willison identified the structural condition, and it is the most useful framing in this subject.

An agent that simultaneously has access to private data, processes untrusted external content, and can communicate externally or take external actions.

When all three hold, a successful indirect injection can exfiltrate private data to an attacker-controlled endpoint with no human interaction, detection or authorisation.

Most deployed agents in 2026 have all three, because all three are what makes an agent useful. An assistant that cannot see your data is not an assistant, one that cannot read the web is not an agent, and one that cannot act is a search box.

Which is why this is a design problem rather than a patching problem. The capabilities that create the exposure are the capabilities being purchased.

A researcher framing puts the gradient plainly: a browser AI that can only summarise is low risk, while agents with email, terminal or payment access become high-priority targets. That second description is the agent profile enterprises deployed most actively through the first half of 2026.

Why it is not fixable in the usual sense

OWASP has ranked prompt injection first on its LLM Top 10 since 2025 and the category remains highest-ranked in the 2026 update, with the agentic companion adding direct goal manipulation and indirect instruction injection as separate entries.

The root cause is architectural: current models frequently fail to distinguish content they are asked to process from content trying to instruct them, particularly where no provenance signalling or structured boundary is enforced.

In February 2026 OpenAI launched Lockdown Mode for ChatGPT and publicly acknowledged that prompt injection in AI browsers may never be fully patched.

That statement deserves attention because of who made it. A developer saying a class of vulnerability in its own product may be permanent is not a marketing position.

And adversarial training does not close it. Training against known attacks improves a specific model, and new attacks routinely defeat the updated weights within weeks. The defence improves and the attack surface does not shrink, which is the same dynamic detection faces and for the same reason.

The exposure numbers, with their provenance

These come from vendor security reports and should be weighted accordingly.

Cisco's State of AI Security 2026 found prompt injection weaknesses in 73% of audited production AI deployments, and reported that 83% of organisations plan to deploy agentic AI while 29% feel ready to do so securely. Only 34.7% have deployed dedicated prompt injection defences.

CrowdStrike's 2026 Global Threat Report documented prompt injection attacks at more than 90 organisations during 2025, alongside AI-enabled adversary operations rising 89% year on year and 82% of intrusions involving no traditional malicious code.

Documented injection attempts against enterprise AI rose roughly 340% year on year in late 2025, with indirect attacks now more than 55% of incidents and carrying 20 to 30% higher success rates than direct ones.

Every one of those figures is published by a company selling security products. The direction is consistent across independent vendors and the magnitudes should be read as indicative. The system card figures are the reliable core of this article and the survey figures are the surrounding context.

What actually reduces it

One reported figure puts layered defences at reducing attack success from 73.2% to 8.7%, which is a large improvement and is not a solution.

The measures named across OWASP guidance and incident post-mortems are consistent and unglamorous.

Isolate retrieved content from instructions, so a document cannot occupy the same channel as a command.

Constrain what an agent may do regardless of what its context says, which is the only measure that survives a successful injection: if the agent cannot send data externally, an instruction telling it to fails at the capability layer rather than at the reasoning layer.

Require human confirmation before sensitive actions. Slow, unpopular, and the thing that stopped every documented exfiltration chain that was stopped.

And inventory. The first priority named in the research is mapping every agent that ingests untrusted external data and what tools and credentials each can invoke when triggered. Most organisations do not have that list, which means they cannot compute their own exposure.

The pattern is the same one Territory 9 found: detection fails and constraint holds. A defence that classifies malicious input is in an arms race. A defence that limits what the agent can do regardless of input is not.

The two curves, side by side

Setting the last two articles against each other makes the shared structure legible, and the shared structure is the finding.

Four rows agree and one differs. The reporting convention is identical, the compounding is identical, the disclosure gap is identical. Only the sign changes.

Which produces an uncomfortable joint conclusion. The same volume that erodes reliability erodes security. An agent used more is both less dependable per session and more exposed in aggregate, and both effects are invisible in the numbers published about it.

And the two are not independent. A workflow with retries, added to improve reliability, multiplies attempts. Every retry that raises the chance the task eventually succeeds also raises the chance an injection eventually lands, and no published analysis treats them as one design decision.

That is the specific thing this pair of articles adds and neither could have said alone: retry budget is a security parameter. It is currently set by reliability engineers who are not told this, using a number chosen to hit a success target, in a system where the same knob controls exposure.

What an organisation can compute today

Every measurement in this article and the last comes from a benchmark or a system card. None comes from a deployment, and the deployments are where the numbers would mean something.

Three computations, all from logs an enterprise already holds.

Attempts per agent per day, by tool and by data source. This is the missing input that converts a per-attempt breach rate into an exposure figure. A vendor publishing 4.7% cannot tell you your risk without it, and you have it.

Retry counts by task type. The reliability parameter that is also the security parameter. An organisation that cannot state its retry budget cannot state either number.

And the trifecta inventory. Which agents hold private data, ingest untrusted content and can act externally, and which hold all three. The research names this as the first priority and most organisations do not have the list, which means the question of exposure has not been asked rather than answered unfavourably.

None of these requires a vendor's cooperation, a new tool, or a research budget. They require somebody to run three queries and write down the answers.

Which is the same conclusion the previous territory reached about disclosure and worth repeating because it keeps being true: the party best placed to measure the thing has the data, no obligation, and no habit.

Three things this establishes

A per-attempt security rate is the wrong number and it is the number reported. 4.7% is true and describes nothing anyone faces. 63% at a hundred attempts is the same measurement of the same system, published in the same document, and it is the one that matters because attempts are free to the attacker.

The exposure is created by the features, not by the defects. Private data, external content and the ability to act are what an agent is. A patch does not remove them and no version will, which makes this a question of what the agent is permitted to do rather than what it can be tricked into wanting.

And developers disclosing their own failure rates is the strongest evidence in this subject. Both attempt-scaled figures here come from system cards published by the model developers, against interest, at a level of detail no third party could produce. That should be encouraged by being used rather than by being quoted selectively.

What it does not establish

That agents should not be deployed. The measures that work are known, the layered-defence figures are large, and the alternative is forgoing the capability entirely.

That EchoLeak caused harm. It was patched server-side with no confirmed in-the-wild exploitation. Its significance is that it worked, not that it was used.

That the survey figures are precise. They come from vendors selling remediation, and the direction is more reliable than any specific percentage.

And nothing about any particular deployment's exposure. That depends on an inventory this article cannot perform.

What the incident record predicted

Territory 6 examined nine documented AI failures that reached courts, regulators or parliaments, and found that not one was fixed by a better model. The remedies were procedural: burden of proof, contestability, disclosure, and constraint on what a system was permitted to do.

This subject fits that finding exactly, and it fits it before the incidents have happened.

Every measure that works here is procedural. Isolating retrieved content from instructions is an architecture decision. Bounding capability regardless of context is a permissions decision. Human confirmation is a process decision. None of them is a model improvement, and the model improvements that have been made are real and have not closed the gap.

Which is unusual in one respect worth noting. Territory 6 examined failures retrospectively, after courts and inquiries had produced records. Here the developers published the failure rates in advance, at attempt-scaled detail, before any comparable public incident record exists.

That is a substantially better epistemic position than the incident record described, and it is worth crediting: the sepsis model was deployed at hundreds of hospitals before an independent validation existed, and the Dutch benefits system ran for years before a parliamentary inquiry produced numbers.

The question is whether better information produces better decisions, and this corpus has not found much evidence that it does on its own. Cisco's figures suggest not yet: 83% of organisations planning agentic deployment against 29% feeling ready to secure it is a gap that the published system cards have been available to close.

Which makes this the clearest available test of a claim this corpus keeps implying. If disclosure is the remedy, then a subject where developers publish their own attempt-scaled failure rates, where a CVE record exists, where OWASP ranks the risk first, and where the defences are known and cheap, should show better outcomes than a subject where none of that holds.

That is falsifiable and the answer is not yet in. If enterprise injection incidents rise through 2027 at the rate the survey figures project, disclosure will have been necessary and demonstrably insufficient, which is a finding this corpus should record against its own preferences.

What is unresolved

Whether architectural separation is achievable. Every current defence operates on a model that cannot reliably distinguish data from instruction, and no proposed architecture has demonstrated that separation at frontier capability.

What the real-world attempt distribution looks like. The system card figures scale to a hundred and two hundred attempts. Nobody publishes how many attempts a production agent actually receives, which is the missing input for converting a per-attempt rate into an exposure.

Whether human confirmation survives contact with scale. It works and it removes most of the value of automation, and no published analysis states where the boundary should sit.

And whether disclosure norms hold. Two developers currently publish attempt-scaled injection figures in system cards. That is a norm rather than a requirement, and norms under commercial pressure have a poor record in this corpus.

Why this article contains no technique

A note on what has been left out, since the omission is deliberate and a reader should know it was a choice.

This article gives measured success rates, a CVE record, a structural condition and a defensive checklist. It gives no attack construction, no example payload and no evasion method.

That is not squeamishness about a topic the corpus otherwise covers. Territory 6 documented nine failures in detail, including exactly how a facial recognition match became an arrest and how an income-averaging formula produced unpayable debts. Mechanism was the point in every one.

The difference is what the mechanism enables. Understanding how income averaging fails helps a reader evaluate a benefits system and helps nobody defraud one. Understanding how a specific injection evades a specific filter is directly operational, and the population that benefits is not the population reading an encyclopedia.

The defensive content survives the omission intact. An organisation does not need an example payload to isolate retrieved content from instructions, bound what an agent may do, require confirmation on sensitive actions, or inventory which agents hold the trifecta. Every measure that works is a design decision rather than a countermeasure to a specific string.

Which is itself the article's argument arriving from a different direction. If the defence were classification, a reader would need to know what to classify. Because the defence is constraint, they do not, and an article that cannot help an attacker can still fully help a defender.

The counter-argument

Attempt-scaled figures may overstate practical risk. A hundred injection attempts against one agent is a determined targeted campaign, not background noise, and most deployments are not individually targeted. A per-attempt rate may be closer to the right measure for an average system than this article allows.

The security vendor figures are doing more work here than their provenance supports. Cisco, CrowdStrike and the survey sources all sell into this market, the 73% and 340% figures have no published methodology, and stripping them out would leave a much thinner article.

Human confirmation is not the answer it appears to be. Confirmation fatigue is a documented failure mode: an agent asking for approval on every action trains the user to approve without reading, which is automation bias arriving from the other direction and converts a security control into a rubber stamp.

And the framing that this is unfixable may be premature. Structured prompt boundaries, provenance signalling and capability-scoped credentials are all young, and declaring an architectural problem permanent three years into serious work on it is the kind of claim this corpus criticises elsewhere.

The short version

Published system cards give indirect prompt injection success in agentic coding at 4.7% at one attempt, 33.6% at ten and 63.0% at a hundred, and a GUI agent at 17.8% rising to 78.6% by the two hundredth attempt. Frontier models, defences active, self-reported.

That is the previous article's arithmetic with the sign reversed. Reliability requires every attempt to succeed and decays; security requires every attempt to fail and decays the same way. The attacker chooses the attempt count, and a 1% per-attempt failure rate against an agent running thousands of times daily still produces dozens of successes.

EchoLeak, CVE-2025-32711 at CVSS 9.3, was the first zero-click attack on an AI agent: a crafted email planted instructions a copilot later retrieved, exfiltrating data with no user action. Patched server-side, no confirmed exploitation, and the technique generalises to any agent that reads untrusted content.

The condition that makes it catastrophic is three capabilities together: access to private data, ingestion of untrusted content, and the ability to act externally. Most deployed agents have all three because all three are what an agent is.

Which is why constraint beats detection. Isolating retrieved content from instructions, limiting what the agent may do regardless of context, and requiring confirmation before sensitive actions are the measures that survive a successful injection. A defence that classifies input is in an arms race. A defence that bounds capability is not.

And the exposure context, from vendor surveys and weighted accordingly: injection weaknesses in 73% of audited production deployments, 83% of organisations planning agentic AI against 29% feeling ready to secure it, and attacks documented at more than 90 organisations in 2025.

Common questions

What is the headline finding? That prompt injection success rates scale with attempts, and the single-attempt figure is the one that gets reported. Published system cards give indirect injection success in agentic coding environments at 4.7% at one attempt, 33.6% at ten, and 63.0% at a hundred, and a GUI-based agent at 17.8% for a single attempt rising to 78.6% by the two hundredth. These are frontier models with defences active, measured and published by the developers themselves.

How does that relate to agent reliability? It is the same arithmetic with the sign reversed. Reliability requires every attempt to succeed, so a 61% single-attempt success rate falls to 25% across eight. Security requires every attempt to fail, so a small per-attempt breach rate rises toward certainty across many. The attacker chooses the number of attempts, which is why a 1% per-attempt failure rate against an agent running thousands of times a day still produces dozens of successful attacks.

What was EchoLeak? Recorded as CVE-2025-32711 with a CVSS score of 9.3, it was the first known zero-click attack on an AI agent. A single crafted email planted hidden instructions that Microsoft 365 Copilot later retrieved as context, causing exfiltration of data from the user's environment with no clicks and no user interaction. Microsoft patched it server-side and no in-the-wild exploitation was confirmed. Its importance is that the attack surface was the document rather than the user, which removes the layer of defence that security training addresses.

Why can't this just be patched? Because the root cause is architectural. Current models frequently fail to distinguish content they are asked to process from content attempting to instruct them, especially where no provenance signalling or structured boundary is enforced. Adversarial training hardens a specific model and new attacks routinely defeat the updated weights within weeks. In February 2026 OpenAI launched Lockdown Mode for ChatGPT and publicly acknowledged that prompt injection in AI browsers may never be fully patched, which is a notable statement from a developer about its own product.

What is the condition that makes an agent high risk? Three capabilities together: access to private data, processing of untrusted external content, and the ability to communicate externally or take external actions. When all three are present, a successful indirect injection can exfiltrate data to an attacker-controlled endpoint with no human interaction. Most deployed agents have all three, because all three are what makes an agent useful, which makes this a design question rather than a defect.

What actually works? Constraint rather than classification. Isolate retrieved content from instructions so a document cannot occupy the same channel as a command. Limit what an agent may do regardless of what its context says, since a capability the agent lacks cannot be invoked by any instruction. Require human confirmation before sensitive actions. And inventory every agent that ingests untrusted data alongside the tools and credentials each can invoke, which most organisations have not done and which is the prerequisite for computing exposure. One reported figure puts layered defences at reducing attack success from 73.2% to 8.7%.

How reliable are the exposure statistics? Less reliable than the system card figures, and they are labelled as such. The 73% of audited production deployments showing injection weaknesses, the 83% planning against 29% ready, the 340% year-on-year rise in documented attempts and the 90-plus affected organisations all come from companies selling security products into this market, with no published methodology. The direction is consistent across independent vendors and the magnitudes should be read as indicative rather than precise.

What is the strongest objection to this framing? That attempt-scaled figures may overstate risk for most deployments. A hundred injection attempts against a single agent describes a determined targeted campaign rather than background exposure, and a per-attempt rate may be the more appropriate measure for a system nobody is specifically targeting. A second objection concerns human confirmation, which sounds like a solution and produces confirmation fatigue: an agent requesting approval for every action trains users to approve without reading, converting a security control into a rubber stamp.