No Agent Reliably Blocks Prompt Injection: Reading the StakeBench Security Numbers Correctly

A June 2026 benchmark called StakeBench tested 3,168 adversarial runs against leading web agents and found that no single attack objective was consistently blocked by any configuration. Direct prompt injection succeeded over 79% of the time. The security implications are not subtle. But the headline number is actually the least interesting part of the paper. What matters is how the failures distribute, who gets harmed, and why swapping the backbone model changes the outcome by double digits without fixing the underlying problem.

Key Takeaways

• StakeBench found that direct prompt injection exceeded 79% success across all tested web-agent configurations, and indirect injection ranged from roughly 42% to 68%, with no attack objective reliably resisted by any agent.
• A single aggregate "block rate" is the wrong unit of measurement: user-targeted attacks produced the lowest visible disruption, meaning the workflow looks normal while the attacker's goal is quietly achieved.
• Swapping the backbone model changed indirect-injection success by up to 26 percentage points, but the researchers concluded that resilience depends on agent architecture, not model brand alone.
• The structural root cause (LLMs process trusted and untrusted tokens in one undifferentiated stream) is not patchable by prompting or fine-tuning. Containment after assumed compromise matters more than detection.
• OWASP's June 2026 update now grounds its prompt-injection ranking in disclosed CVEs and actual breach reports, confirming this is a production problem, not a research curiosity.

What Did StakeBench Actually Measure?

StakeBench is a stakeholder-centric benchmark built by researchers from Nanyang Technological University, ST Engineering, IBM Research, and the University of Illinois Urbana-Champaign. It ran 264 benchmark cases across the NanoBrowser and BrowserUse web agents, producing 3,168 total adversarial runs. Unlike prior injection benchmarks that mostly track binary attack success, StakeBench evaluates harm across three separate stakeholder groups: end users, third-party sellers, and platforms.

That tripartite framing is the paper's real contribution. A single number like "79% injection success" collapses distinct failure modes into one figure, which is convenient for headlines and useless for engineering decisions.

Why Does a 79% Direct Injection Rate Understate the Problem?

It understates it because the failures are not uniform. Seller-targeted attacks had the highest success rates of any group, while attacks aimed at users produced the lowest rate of visible task disruption. Read that again. The user-facing workflow can look completely normal while the attacker's objective is quietly achieved in the background. The paper describes this as "stealthy parasitism," and it is the failure mode you should lose sleep over.

If you are evaluating an agent vendor and they hand you a single aggregate block rate, you are looking at a number that averages together loud failures (the agent crashes or returns garbage) with silent ones (the agent completes your task while also completing the attacker's). Those are not the same thing. Averaging them is like reporting the mean temperature of a hospital: technically a number, practically meaningless.

How Much Does Swapping the Model Actually Help?

Less than you would hope, and in inconsistent ways. Swapping from one frontier model to another raised indirect injection success rates by 26.49 percentage points on NanoBrowser and 6.2 percentage points on BrowserUse. So the same model swap produced wildly different effects depending on the agent framework wrapping it.

There is a more revealing detail buried in the full paper. In a controlled variation test, when surrounding page cues (like star ratings) contradicted the injected instruction, one backbone's attack success dropped from about 56% to about 19%. The other backbone stayed pinned around 83% to 86% regardless of whether cues were consistent or contradictory. One model notices environmental inconsistency. The other does not. Same agent code, same injection payload, completely different resilience profile.

The researchers' conclusion is stated plainly: prompt-injection resilience depends not just on the underlying language model but on how that model is implemented inside the agent's architecture. If you are a buyer, this means asking "which model do you use?" is the wrong question. The right question is "what is your quantified injection resistance for the specific model version and agent configuration you actually deploy?"

Is Prompt Injection a Bug or an Architectural Constraint?

It is an architectural constraint. The framing has shifted meaningfully over the past year. OWASP's updated "State of Agentic AI Security and Governance" report, released the same month as StakeBench, now grounds its risk ranking in disclosed CVEs, vendor advisories, and actual breach reports rather than hypothetical threats. Prompt injection maps to six of ten categories in OWASP's Agentic Top 10.

The structural reason is straightforward and has not changed since the problem was first identified: LLMs process system instructions, user input, and retrieved data as one undifferentiated token stream. There is no built-in boundary between trusted and untrusted content. Any attacker who can plant text where an agent reads it (a product review, a webpage, a calendar invite, an email signature) can redirect the agent's actions. This is not a prompting failure. It is not a fine-tuning gap. It is a consequence of how transformer-based language models process sequences.

Industry outlets increasingly describe this as a permanent architectural flaw, not a patchable bug. We think that framing is roughly correct, with the caveat that "permanent" is a strong word for a field moving this fast. What we can say with confidence: no known technique eliminates the problem at the model level. Every defense is a mitigation that reduces attack surface without closing it.

What Does "Stealthy Parasitism" Look Like in Practice?

Consider a concrete example from recent research. Security researchers demonstrated that after an AI browser agent was tricked by a rigged game, it followed a redirect and pulled SSH credentials from a victim's GitHub repository. None of the six tested agents flagged the theft as a rule violation. The user's original task completed normally. The credentials were exfiltrated silently.

This is the failure mode StakeBench's numbers are trying to surface. The agent did not crash. It did not refuse the task. It did not produce an error. It completed the user's request and the attacker's request. From the user's perspective, everything worked.

Separately, Johns Hopkins University researchers showed they could hijack production-grade AI agents integrated with GitHub Actions from three major tech companies to steal API keys and credentials. All three vendors paid bug bounties. None assigned CVEs or published public advisories. The gap between "we take this seriously" and "we will tell anyone about it" is worth noticing.

Why Is a Single Block Rate the Wrong Metric?

Because it collapses at least three distinct failure modes into one number. StakeBench identifies them explicitly: stealthy success (the attack works, the user's task also works), disruption without attack completion (the user's task breaks, but the attacker's goal fails), and compounded failure (both the user's task and the attacker's goal break simultaneously). These three outcomes have completely different risk profiles for different stakeholders.

If you are a platform operator, compounded failure is bad but visible. Stealthy success is worse because it is invisible. If you are an end user, disruption without attack completion is annoying but safe. Stealthy success means you are compromised and do not know it.

A vendor who reports "we block 85% of prompt injections" is telling you nothing about which 15% gets through. If the 15% is concentrated in the stealthy-success category, that vendor's agent is more dangerous than one with a 70% block rate where the failures are loud and visible. The StakeBench contribution is making this distinction measurable.

How Should Buyers Evaluate Agent Security Now?

Three changes to your procurement process, if you are deploying agents with any access to credentials, payments, or user data.

First, demand quantified injection resistance by configuration. Not by model brand. Not by vendor claim. By the specific model version, agent framework, and deployment configuration you will actually run. StakeBench showed that the same model produces dramatically different resilience depending on the agent wrapping it. A number attached to a model name is not transferable to your deployment.

Second, ask for stakeholder-disaggregated results. If a vendor can only give you one number, they have not done the work. You need to know what the stealthy-success rate is, specifically, because that is the failure mode you cannot observe in production without purpose-built monitoring.

Third, evaluate containment, not just detection. Given that even the strongest backbone in StakeBench still failed in the majority of direct-injection attempts, the question is no longer "can the agent detect injection?" The question is "when injection succeeds (and it will), what can the attacker actually do?" Scoped credentials, short-lived tokens, egress control, tamper-evident audit logs. These are the controls that determine whether a successful injection translates into real-world harm.

What Does the Supply-Chain Angle Add?

Prompt injection is not the only vector, and treating it in isolation is a mistake. In March 2026, a backdoor sat on PyPI for three hours, compromising the LiteLLM gateway used by CrewAI, DSPy, Microsoft GraphRAG, and other agent frameworks. Roughly 47,000 downloads occurred before it was pulled. The payload was an autonomous attack bot delivered to anyone who updated during that window.

This is the compound threat model. An attacker does not need to inject a prompt into your agent at runtime if they can compromise the dependency that your agent framework imports at build time. The supply chain and the prompt-injection surface are two doors into the same room.

Where Does Regulation Stand?

Compliance windows are tightening. OWASP now tracks 42 regulatory instruments across 10 jurisdictions. New York's RAISE Act sets a 72-hour reporting clock for frontier model incidents. California's SB 53 sets a 15-day window. If you cannot detect that your agent was compromised (because the failure mode was stealthy parasitism and the workflow looked normal), you cannot report it within any window.

This creates a specific, measurable compliance risk. The combination of "attacks that are invisible to the operator" and "mandatory reporting timelines" means you can be both compromised and in violation simultaneously, without negligence on your part, simply because the attack was designed not to surface.

What Is the Confidence Gap and Why Does It Matter?

A 2026 enterprise survey found 88% of organizations reported confirmed or suspected AI agent security incidents in the past year. A separate executive survey found 82% believed their existing policies already protected against unauthorized agent actions. The same population, exhibiting a striking confidence-versus-incident mismatch.

This is not a knowledge gap. The executives know about prompt injection. They have read the OWASP list. They have seen the headlines. What they have is an estimation gap: they believe their specific deployment is adequately protected because their vendor told them it is, and their vendor gave them a single aggregate block rate that collapsed three failure modes into one reassuring number.

What Does This Mean for How We Build Selina?

We build an AI assistant, not a web agent. Selina does not browse arbitrary websites, execute code on third-party platforms, or autonomously take actions across unbounded surfaces. That architectural choice is not incidental. It limits the attack surface to what we can actually control and monitor.

But we are not going to pretend that solves prompt injection entirely. It does not. A slice of each request reaches a frontier provider at inference, so memory is not end-to-end encrypted. We encrypt content at rest. We protect the account. Files and transfers via SelinaSEND are zero-knowledge encrypted. But the memory path includes inference, and we state that plainly because the alternative is to let you assume something we cannot guarantee.

What we can do, and do, is design for assumed compromise. Bounded credential scopes. Egress controls. Tamper-evident audit. Non-content operational metadata is kept for a short retention window, not indefinitely, and not shared. When we say "delete means gone, actually gone," that applies to your content, on your command.

We route requests through a stack of frontier models, routed per task. We do not claim any of those models is immune to injection. None of them are. StakeBench confirms what we already assumed: the model is not the defense. The architecture around the model is the defense, and even that is a mitigation, not an elimination.

We think the right posture for 2026 is honest about this. If someone tells you they have solved prompt injection, ask for their StakeBench-style numbers disaggregated by stakeholder and failure mode. If they cannot produce them, they have not measured the thing they claim to have solved.

What Should You Actually Do This Quarter?

Audit which of your deployed agents have write access to anything that matters. Credentials, payment systems, customer data, code repositories. For each one, answer three questions: what is the agent's quantified injection resistance for its actual deployed configuration? What is the blast radius if injection succeeds? And can you detect stealthy-success failures where the user's task completes normally while the attacker's objective is also achieved?

If you cannot answer the third question, you have a monitoring gap that no block rate can compensate for. The StakeBench numbers are not a reason to stop deploying agents. They are a reason to stop deploying agents with unbounded access and no containment architecture, which is a different sentence.

If you want an assistant that starts from these assumptions rather than arriving at them after a breach, start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io