Skip to content
AI Security Wire

Published

- 7 min read

By

Agent Data Injection Attacks Hit Claude Code, Codex, and Gemini CLI

img of Agent Data Injection Attacks Hit Claude Code, Codex, and Gemini CLI

A research team from Seoul National University, the University of Illinois Urbana-Champaign, and Largosoft published a paper on July 6, 2026 (arXiv 2607.05120) introducing Agent Data Injection (ADI) as a distinct attack sub-class within the indirect prompt injection taxonomy. Their findings are specific and replicable: ADI achieved success rates of up to 50% against AI agents deployed with purpose-built indirect prompt injection defenses, while classic instruction-injection attacks against those same hardened systems achieved near-zero success. The paper demonstrates working attacks against Claude Code, Codex, Gemini CLI, Claude in Chrome, Nanobrowser, and Antigravity.

What ADI Is, and What It Is Not

Indirect prompt injection attacks embed malicious instructions in content that the agent retrieves or processes: a webpage, a document, a database record. The agent reads the content, processes the embedded instruction as a directive, and acts on it. Defenses against IPI focus on detecting instruction-shaped content in retrieved data before it reaches the model.

ADI targets a different layer. Rather than hiding instructions in retrieved text, it corrupts the structured metadata and context data that agents treat as implicitly trusted. This includes resource identifiers, data origin fields, tool call formats, and tool response schemas.

The agent is not tricked into following a command embedded in a document. It is tricked into misinterpreting the structure of its own operational data.

That distinction is what breaks existing defenses. They scan for instruction-shaped content in untrusted fields. ADI content does not look like an instruction. It looks like a malformed value in a JSON object, an unexpected element ID in a DOM tree, or an unusual delimiter in a tool response. No current scanner flags these, and the paper shows current defenses cannot readily be adapted to do so without substantial redesign.

Probabilistic Delimiter Injection: The Core Technique

The attack mechanism is called probabilistic delimiter injection. Attackers inject delimiter characters of the target data format into untrusted string fields: curly braces for JSON, angle brackets for XML, element ID patterns for web DOM.

A deterministic parser would reject these inputs as malformed. LLMs do not use deterministic parsers. They infer structure from context, probabilistically. An injected } appended to a product name in a JSON array causes the model to close the object early and interpret whatever follows as a new top-level key. A comment text field in a web page DOM that mimics an adjacent element’s ID causes the model to treat the comment as an actionable UI element.

Because LLMs interpret structure probabilistically, the injected delimiter does not need to be exact. Parser-invalid delimiters succeed at the rates the paper documents: 31.3%–43.3% attack success rate across six frontier models on JSON-formatted tool data, and 33.3%–100.0% on web DOM data. These are not edge-case numbers.

Confirmed Targets and Attack Outcomes

The researchers tested production AI agent systems and documented working attacks across two deployment classes.

Web agents. Claude in Chrome, Antigravity, and Nanobrowser are all affected. The attack vector is content embedded in web pages these agents browse: a planted product review field, a comment section, an image alt-text attribute. The outcome is arbitrary click execution. The illustrative scenario in the paper: an agent tasked with summarizing product reviews instead clicks “Buy Now” because a poisoned review field corrupted the agent’s interpretation of the surrounding DOM structure. The user sees nothing unusual; the agent simply acts.

Coding agents. Claude Code, Codex, and Gemini CLI are all affected. Attack vectors include poisoned GitHub issue comments, manipulated package registry metadata, and corrupted tool call response formats. Outcomes are more severe. The paper demonstrates scenarios where a fake comment in a GitHub thread causes the coding agent to execute attacker-supplied code on the user’s machine. Supply-chain attack scenarios are also documented: an ADI payload in a package registry entry causes the agent to add a malicious dependency during a code generation task.

Why Existing Defenses Fail

The paper tests ADI against three purpose-built IPI defenses. Classic instruction injection (order-smuggling attacks where malicious directives are embedded in retrieved content) achieved 0.0%–0.7% success rate against all three systems. ADI achieved up to 50.0% against the same configurations.

The failure mode is architectural. Current defenses were designed against a threat model where attacks embed instruction-shaped content in data. They detect sentinel tokens that agents treat as directives, prompt structure anomalies that resemble injected system prompts, and natural language that pattern-matches to command structures. ADI payloads contain none of these signals. A JSON field that ends with }, "admin": true is not instruction-shaped. A DOM element ID that echoes an adjacent interactive element is not instruction-shaped. Scanners built for the previous threat model pass both.

The paper also tested a simple mitigation: adding a short random tag as a suffix to trusted field names in agent context data. This acts as a per-session nonce: trusted keys carry the tag, injected content cannot replicate it without access to the session-specific value. The mitigation reduced ADI success rates from approximately 49% to approximately 29%. A real reduction. Not a solution.

Parallel Research: Zenity Labs’ Data-Structure Injection

Security vendor Zenity Labs independently published research on a related technique they call Data-Structure Injection (DSI). Zenity’s framework identifies three variants: argument exploitation (manipulating tool input values), schema exploitation (corrupting the schema that defines valid tool inputs), and workflow exploitation (hijacking multi-agent orchestration by corrupting step-record data that determines subsequent agent actions).

Zenity’s analysis focuses on enterprise agentic AI deployments where multiple agents share structured operational data. The enterprise context is relevant: multi-agent systems create larger attack surfaces for DSI because corrupted context data can propagate across agent boundaries. An ADI payload that corrupts a tool response seen by one agent can influence decisions made by downstream agents that consume shared state.

Two independent research groups identifying the same structural vulnerability class in the same month is the pattern that typically precedes active exploitation. The arXiv paper was publicly released on July 6. The Zenity Labs post and the broader IPI research community have both picked it up.

Defensive Guidance

No complete defense against ADI exists at the time of writing. The practical measures available:

Treat agent context data as an untrusted attack surface. Tool outputs, retrieval results, and metadata fields should receive the same scepticism as user input. The assumption that structured data formats imply trust is the vulnerability; removing that assumption is the direction.

Implement nonce-based field validation. The random-tag mitigation from the paper is implementable at the application layer. Adding a per-session random suffix to trusted structural field names distinguishes legitimate context data from injected content. The ASR reduction from 49% to 29% is not a full defence, but the implementation cost is low enough to make this worth deploying now.

Apply strict least-privilege to agent capabilities. ADI payloads can only achieve outcomes the agent is capable of. An agent that cannot initiate payments, install packages outside a sandbox, or execute shell commands cannot be weaponised for the highest-severity outcomes the paper documents. Capability minimisation at the agent design level reduces blast radius for any injection attack class.

Log and alert on structural anomalies in tool outputs. Monitoring for unexpected delimiter characters in metadata fields, tool responses that do not conform to declared schemas, and context data with unexpected key structures adds a detection layer above the model-level defenses that current agent frameworks lack.

The paper is available at arxiv.org/abs/2607.05120. Zenity’s DSI research is at labs.zenity.io.

References

Frequently Asked Questions

What is Agent Data Injection (ADI) and how does it differ from classic prompt injection?
ADI injects malicious data into the structured metadata and context data that agents treat as implicitly trusted, such as resource identifiers, tool call formats, and response schemas. Classic indirect prompt injection hides instructions inside retrieved text content. ADI does not embed instruction-shaped content; it corrupts data structure, which is why existing IPI defenses that scan for instruction patterns fail to detect it.
What is probabilistic delimiter injection?
The core ADI technique involves injecting delimiter characters for the agent's data format (curly braces in JSON, element IDs in web DOM) into untrusted string fields. A deterministic parser would reject these as malformed, but LLMs interpret structured data probabilistically and misparse the structure. The attack succeeds even with approximate or parser-invalid delimiters, achieving 31.3%–43.3% success on JSON data and 33.3%–100% on web DOM across six frontier models.
Which AI agents are confirmed vulnerable?
The paper confirmed working attacks against web agents (Claude in Chrome, Antigravity, Nanobrowser) for arbitrary click execution, and coding agents (Claude Code, Codex, Gemini CLI) for remote code execution and supply-chain attacks. Separately, Zenity Labs documented similar Data-Structure Injection vulnerabilities in enterprise agentic AI deployments.
What mitigations are available against ADI attacks?
No complete defense exists yet. The paper demonstrates that adding a random nonce suffix to trusted field names roughly halves success rates from 49% to 29%. Practical measures include treating all tool outputs and retrieved metadata as untrusted, applying strict least-privilege to agent capabilities, and monitoring for unexpected delimiter characters in tool response fields.