Agent Data Injection: The Attack Class Your Prompt Injection Filters Cannot See

On 6 July 2026 a group of researchers from Seoul National University, the University of Illinois Urbana-Champaign and Largosoft published a paper describing what they call Agent Data Injection, or ADI, and the Cloud Security Alliance has since published its own artifact treating it as a distinct attack class rather than a variant of something already understood. The claim is narrow and uncomfortable. Every defence the industry has built against indirect prompt injection assumes the attacker is trying to smuggle an instruction into the model. ADI does not smuggle instructions. It corrupts the factual data the agent already trusts, and it does so using content that reads as perfectly ordinary metadata right up until the moment the agent acts on it.

The distinction is worth sitting with, because it is the whole story. Classic indirect prompt injection puts attacker text where the model will read it and hopes the model treats that text as a command, which is why the canonical payload looks like a sentence beginning with ignore all previous instructions. Detection followed the same shape: scan retrieved content for imperative language, for role confusion, for anything that reads like it is addressed to the model rather than about the subject matter. ADI payloads contain none of that. They target the identifiers, the authorship metadata, the tool call and response formats, the resource origins, all the small factual scaffolding an agent uses to decide which button is which and which piece of content came from where. The paper notes the payloads rely on probabilistic delimiters rather than instruction patterns, and the practical consequence is that a filter looking for commands sees nothing to flag because there is no command present.

What the researchers demonstrated with it is not theoretical. Against web agents, including Claude in Chrome, Antigravity and Nanobrowser, they showed arbitrary click attacks, meaning the agent can be steered into activating a control the user never intended because the data describing that control was attacker influenced. Against coding agents, including Claude Code, Codex and Gemini CLI, they showed remote code execution and supply chain attacks. The attacker does not need privileged access to the agent to reach any of this. Partial control over external content the agent retrieves is enough, and that means an email, a web page, a shared document or a comment on a GitHub issue is a viable delivery surface. If your agent reads anything from the outside world, the outside world is inside your trust boundary.

The root cause the paper identifies is architectural rather than incidental, which is why it will take longer to fix than a bad regex. Current agents do not separate trusted data from untrusted data. Everything arrives in the same context window with the same apparent standing: the system prompt, the user request, the contents of a file, the body of a retrieved web page, the output of a tool call. A human reading a support ticket knows the difference between the ticket text and the ticket system that delivered it. An agent, structurally, does not, and no amount of prompt engineering creates a boundary the architecture does not have. This is the same fundamental gap that makes classic prompt injection hard, but ADI exploits it from an angle that the last two years of mitigations were not built to cover.

Coding agents deserve particular attention here because the blast radius is larger than the code they write. An agent with shell access, package installation rights and repository credentials is a build system with a language model attached, and the LiteLLM compromise in March 2026 is the reference case for what happens when that layer is touched. In that incident the TeamPCP actor obtained maintainer publishing credentials by way of a poisoned Trivy scanner in the CI pipeline, pushed two backdoored releases to PyPI, and the malicious wheel executed on every Python process start in any environment where it was installed. The packages were live for roughly forty minutes on a library pulling tens of millions of monthly downloads and sitting underneath a great many agent frameworks and MCP servers. ADI is a different mechanism reaching a similar destination, and the two combine badly: an agent that can be steered into installing a dependency, in an ecosystem where a dependency can be briefly and invisibly hostile.

The mitigations that actually help are unfashionable, because they are about privilege rather than cleverness. Scope the credentials each agent holds to the narrowest set that lets it do its job, and give it separate identities per task rather than one long lived token that opens everything. Put a human approval gate in front of the irreversible actions specifically, the package installs, the pushes, the outbound sends, the anything that spends money, rather than gating everything and training your team to click through. Pin dependencies to exact versions with hash verification so a compromised release cannot arrive silently during a build. Run agents with filesystem and network access limited to what the task requires. None of this prevents the agent from being deceived, and that is the point: the assumption to design around is that it will be deceived eventually, so what matters is what it is able to do in that moment.

This is where the topic lands in compliance rather than staying in engineering, and the frameworks have mostly caught up. An ISO 42001 management system expects an inventory of the AI systems in use with an accountable owner and documented limits for each, and an agent with production credentials plainly qualifies. ISO 27001 access control and supplier relationship clauses apply to a non human identity in the same way they apply to a service account, which is exactly the framing we covered when non human identity governance started appearing in security questionnaires. SOC 2 auditors in 2026 are asking how AI tooling is authorised, monitored and bounded, and an approval gate on destructive actions is a control with evidence attached, not a slide. Vanta, Drata, Secureframe and Sprinto can all hold that evidence against a control and enforce the review cadence, which is the difference between a policy that exists and one that anybody can demonstrate.

The honest position for a founder or a security lead reading this is that ADI is early research, not a wave of confirmed breaches, and nobody should be tearing out an agent stack over a paper published four weeks ago. What it does justify is a short and specific review. List every agent in your environment that reads external content, whether that is a coding agent with repository access, a browser agent, or an MCP server wired into a shared inbox or ticket queue. For each one, write down what credentials it holds, what irreversible actions it can take without a human, and whether the content it consumes can be influenced by someone outside your organisation. Where all three answers are broad, narrow one of them this month. The teams that enforced least privilege on their agents before the attack class was named are the ones for whom this paper is interesting reading rather than an incident, and that gap is the entire argument for doing the boring work now.