The Impossibility Result Changes the Premise
Published on May 17, 2026, arXiv 2605.17634 by Abdelnabi and Bagdasarian reframes prompt injection as a structural limit rather than a bug awaiting a patch. Working from a Contextual Integrity lens, the paper states an impossibility result: an attacker can always construct a context in which a flow that should be blocked looks legitimate, and a defender cannot fully distinguish a genuine context from a disguised one in principle. So the goal of defense shifts away from a 0% success rate toward limiting blast radius — keeping damage from spreading even when some injections get through.
What Data-Instruction Separation Misses
The mainstream defense so far has been data-instruction separation: mark untrusted data apart from system instructions. The paper argues this falls short in two directions. It misses context-manipulation attacks, and it also degrades normal operation by mistaking legitimate data for instructions. When an attack takes the form of redefining a norm rather than violating one, a tag that labels input as data will not catch it.
Three Attack Categories and the Breadth of Agentic Risk
The paper groups attacks into three categories. Flow disguise makes a malicious flow read like a normal workflow; contextual-norm manipulation changes the norm itself about what sharing is appropriate; multi-flow composition chains individually harmless flows to exfiltrate sensitive data. OWASP GenAI's State of Agentic AI Security and Governance 2.01 confirms that injection shows up across 6 of the Agentic Top 10 categories — evidence that this is a risk running through agent design as a whole, not an isolated vulnerability.
From Design to Operations: A Blast-Radius Reduction Checklist
At the planning stage, set the defense goal as blast radius rather than block rate. One rule clarifies the whole checklist: never grant untrusted input, sensitive-data access, and external transmission to a single session at the same time. Target metrics follow from it — the human-approval rate on risky tool calls, the number of resources actually touched when an injection simulation succeeds, and the review cadence for permission scopes. In practice that means requiring 100% human approval for risky tools like external sending, deletion, or payment, and capping touched resources at one or fewer per simulation.
Failures recur in three places. First, the assumption that passing a filter means safety — the impossibility result is precisely what breaks this assumption. Second, giving read tools and write/send tools the same permissions, so a lookup agent ends up sending mail or deleting files after a single injection. Third, no session-level permission separation, so a session that read untrusted text scraped from the web keeps its access to the internal DB and external APIs.
Design recovery branches per flow. Hold risky tool calls by default and route them through a human-approval gate, and lock the session's external send channel while approval is pending. When injection is suspected, isolate the session without halting the whole service — separate read-only sessions from write sessions physically so contamination on one side does not propagate to the other.
Least privilege sits at the center of the operations checklist. Split tools into three tiers — read, write, and send — and scope each session down to only the tier it genuinely needs. Logs should carry the session ID, input trust level, invoked tool tier, approval status, and the list of touched resources, which is what lets you measure blast radius as a number in simulations. Before release, pass at least one red-team scenario for each of the three categories: flow disguise, contextual-norm manipulation, and multi-flow composition.
The improvement loop feeds simulation results back into design. Cases where touched resources exceed the target auto-enqueue as candidates for permission-scope review, and that review runs every release rather than every quarter. If approval rate and touched-resource counts are not improving across releases, it signals that your defense is a written rule that isn't actually shrinking the radius.
Takeaways at a Glance
Building on the premise from arXiv 2605.17634 that injection cannot be fully blocked, move the center of gravity from prevention to blast-radius reduction. With the rule of never concentrating untrusted input, sensitive data, and external transmission in one session as the axis — splitting tools into read, write, and send tiers, gating risky tools behind human approval, and measuring the radius continuously via per-category red-team scenarios and touched-resources-per-simulation — a partly successful injection stays trapped inside a single flow.
References
arXiv 2605.17634: AI Agents May Always Fall for Prompt Injections
OWASP GenAI: State of Agentic AI Security and Governance 2.01