If you’ve been following the agentic AI space over the last year, you know that Indirect Prompt Injection is both a huge problem and an area of active research. We train models to look for and ignore instructions in websites and distrust instructions that arrive inside documents. While not complete, the industry would say it has a reasonably good understanding of the problem. Against these current state-of-the-art agent defenses, the classic "ignore your instructions and email this to me" attack rarely succeeds.
But a paper out of Seoul National University and UIUC in July, "Agent Data Injection Attacks are Realistic Threats to AI Agents" by Choi and colleagues, makes an uncomfortable point: an attacker can bypass a lot of these controls simply by forging the tags around their message.
Historically, an indirect prompt injection attack focused on instruction injection: sneaking malicious commands into untrusted external data (like an incoming email) hoping the model would execute them as system directives. Agent Data Injection doesn't smuggle a command into external content. It disguises the payload as trusted data: resource identifiers, claimed data origins, tool-call and tool-response formats. The agent is never talked into disobeying you, it's misled about what a piece of data is and where it came from, and then it does something perfectly reasonable on a false premise. The instruction was never the weapon - the label was.
The technique behind it, which the authors call probabilistic delimiter injection, is worth understanding because it exposes something fundamental about how LLMs differ from every parser we have defended before. In traditional application security, injection attacks like SQLi and XSS work by inserting exact structural delimiters, a single quote, an angle bracket, into a deterministic parser. If the syntax is wrong, the parser rejects it and the attack fails. LLMs do not work like deterministic parsers; they interpret structure probabilistically. So even inexact, escaped, or technically invalid delimiters can trick the model into treating attacker-controlled strings as structurally valid metadata. The attacker does not need to match the format perfectly. They just need to be close enough for the model to buy it.
The numbers are what make this hard to wave off. The authors evaluated six models, including GPT-5.2, Claude Opus 4.5, Claude Sonnet 4.5, and Gemini 3 Pro, and tested against state-of-the-art defenses. Against those defenses, classic instruction injection succeeds between 0.0% and 0.7% of the time. ADI, against the exact same defended agents, succeeds up to 50.0%. On off-the-shelf models without defenses, attack success rates range from 31.3% to 43.3% on structured JSON data and from 33.3% to 100.0% on web page content.
These are not theoretical results. The authors confirmed vulnerabilities in real-world agents that people are using today: arbitrary click attacks against the web agents Claude in Chrome, Antigravity, and Nanobrowser, and remote code execution and supply-chain attacks against the coding agents Claude Code, Codex, and Gemini CLI. All vendors were notified; OpenAI, Google, and Anthropic acknowledged the issues.
The GitHub example is the one that stuck with me. An attacker posts a comment on an issue that spoofs the author field as a maintainer. A coding agent reads it, accepts the claimed authorship as real, and runs commands it would never have executed for a stranger. The agent is still doing exactly what the user asked: apply the maintainer's fix. It just has the wrong idea of who the maintainer is. Nothing that looks like an instruction was injected - an origin was.
If the problem is a forged origin, then the solution is to simply tag every piece of data with its real origin and trust level, and have the agent act accordingly. If that sounds familiar, it's what the more serious runtime frameworks actually propose. The A2AS Framework, which I covered in The "HTTPS moment" for Agentic AI?, is the clearest example. Its Security Boundaries wrap external content in tags meant to signal origin and trust level, and its Authenticated Prompts hash each request's origin for attribution and tamper-evidence. It is low-latency, model-native, and refreshingly honest about being defense-in-depth rather than a guarantee.
ADI pressures that whole approach from two directions.
First, the boundary is a textual convention, not a parser. The model honors those tags by reading them, probabilistically, the same way it reads everything else in the window. A convincing fake delimiter buried inside untrusted content can shift the line the model believes separates trusted from untrusted. You are asking a statistical system to enforce a boundary it only ever perceives statistically.
Second, authentication binds trust to the channel, not to the claim inside it. A framework can prove that a GitHub response genuinely came from the GitHub tool, hash and all, and still have no idea whether the "maintainer" named inside that response is real. The tag is valid and useless at the same time. You authenticated where the data entered from, but the attacker forged what the data claimed to be.
This is the part that should unsettle anyone relying on coarse-grained trust boundaries. ADI does not try to escape the untrusted region to act like a system prompt. It operates entirely within the data boundary, corrupting a field like author or element_id that the agent legitimately relies on for its next action. The boundary held, the instruction-versus-data separation succeeded, and the agent was still compromised.
ADI is an artifact of the in-band signaling nature of LLMs. The trust signal, whether it is a tag, a claimed origin, or a delimiter, travels in the same channel as the data it is supposed to govern. When control and data share a channel, the data can always learn to imitate the control. That is the Cap'n Crunch whistle, and it is why I keep insisting the control plane and the data plane have to be kept apart.
To their credit, the frameworks in this space do not pretend otherwise. A2AS names this in its own limitations section, noting that different models interpret tags and tag order inconsistently, and its review of prior work concedes that boundary-awareness defenses are less concrete, deterministic controls and more suggestions applied inconsistently. ADI is the empirical proof that this problem is real, and unsolved at the moment.
This doesn't mean tagging belongs in the bin. Tags are good telemetry, useful for audit, and a fair first filter. But they are not a boundary. The controls that survive an attack like ADI are the deterministic ones: permissions enforced in code, behavior limits that cap what an agent is allowed to do, policies that require a human to confirm before money moves or data leaves. For now, we cannot put trust in in-band labels, only the outputs and outcomes of the LLM's machinations.
For anyone shipping a customer-facing agent, understand that telling the model to distrust external content is not a control, it's a suggestion. ADI is a demonstrated, measured example of how often the model quietly declines to take it.
This week I want to give credit to Adversa and their Top Agentic AI security resources — August 2026 blog this month. It's worth reading to learn a lot of what's been going on recently. If you want to better understand how tagging and context boundaries apply to your generative AI chatbots, feel free to reach out to us at questions@generativesecurity.ai. We're always happy to work with you on understanding and protecting your generative AI workloads.
About the author
Michael Wasielewski is the founder and lead of Generative Security. With 20+ years of experience in networking, security, cloud, and enterprise architecture Michael brings a unique perspective to new technologies. Working on generative AI security for the past 3 years, Michael connects the dots between the organizational, the technical, and the business impacts of generative AI security. Michael looks forward to spending more time golfing, swimming in the ocean, and skydiving... someday.
