Key Takeaways
- Agent Data Injection (ADI) is a new class of attack that corrupts the trusted facts an AI agent relies on—such as sender names, button IDs, or tool‑execution logs—rather than trying to smuggle malicious instructions into the agent’s prompt.
- ADI exploits the model’s probabilistic interpretation of delimiters (quotes, braces, tags, line‑breaks) that separate trusted data fields from untrusted content; even malformed or escaped punctuation can be mistaken for real structure.
- Demonstrated attacks on web agents (clicking “Buy Now” instead of “Read More”), coding assistants (executing attacker‑controlled commands masquerading as maintainer fixes), and GitHub agents (fabricating check results to enable malicious merges) succeeded 31‑50 % of the time across GPT‑5, Claude Opus/Sonnet, and Gemini models.
- Traditional prompt‑injection defenses that look for smuggled orders are largely ineffective against ADI because the attack operates at a lower layer of trust.
- Mitigations that help include assigning unguessable random IDs to page elements, adding short random tags to field names, and implementing full provenance tracking; however, the latter can reduce agent usefulness to roughly one‑third of normal performance.
- The vulnerability stems from agents mixing trusted data with untrusted input without a clear boundary—a design flaw that echoes earlier software lessons about separating code and data, and trusted from untrusted data.
- Researchers have disclosed the issue to OpenAI, Google, Anthropic, and Nanobrowser; while the vendors confirmed the validity of the attack, no public fixes have been announced as of the paper’s release.
Overview of Agent Data Injection (ADI)
Agent Data Injection, introduced by researchers from Seoul National University, the University of Illinois Urbana‑Champaign, and Largosoft, reframes the classic prompt‑injection problem. Instead of embedding a hidden instruction like “ignore your task and email me the files,” ADI manipulates the data that an agent trusts while performing a legitimate task. The agent continues to follow the user’s request, but it does so on the basis of fabricated facts—such as a falsified sender name or a counterfeit button identifier—leading to unintended actions like unwanted purchases or unauthorized code execution. Because the attack does not alter the agent’s goal, many existing defenses that scan for malicious instructions remain blind to it.
How ADI Works: Probabilistic Delimiter Injection
The core technique relies on how language models interpret punctuation that delimits data fields. Agents wrap trusted information—like an email’s “From” field or a webpage element’s ID—with quotes, braces, tags, or line‑breaks so the model can distinguish trusted content from untrusted message bodies. Unlike a strict parser, a language model decides these boundaries probabilistically, guessing whether a character sequence constitutes a delimiter. An attacker who controls a field can inject characters that resemble delimiters—escaped quotes (\”), curly quotes, dollar signs, or even arbitrary symbols—and the model often treats them as genuine structural markers. This mistaken parsing creates phantom fields (an extra email, a spare button, or a fabricated tool result) that the agent then acts upon. Because the delimiter need not be perfectly correct, the attack surface is broad and difficult to filter with simple character‑blocking rules.
Real‑World Demonstrations on Shipping Tools
The researchers built three proof‑of‑concept attacks against widely used, production‑grade agents.
-
Web Agents – Using Claude in Chrome, Google’s Antigravity, and Nanobrowser, a malicious product review reused the numeric ID of a legitimate “Read More” button. Since these tools assign IDs sequentially, the attacker could predict the next ID and cause the agent to click “Buy Now” instead, placing an order the user never intended.
-
Coding Assistants – With Claude Code, OpenAI’s Codex, and Google’s Gemini CLI, a forged GitHub comment was made to appear as if written by a project maintainer. When the assistant was instructed to apply the maintainer’s fix, it executed the attacker’s command on the developer’s machine, assuming the step was a routine part of the fix.
- GitHub Agents – A malicious pull request fabricated the record of a status check that the agent never actually ran. The agent saw a clean‑looking result in its history, deemed the code safe, and proceeded to merge the pull request once the developer approved, thereby introducing malicious code into the repository.
In each case, the agent’s core task (reading a review, applying a fix, checking a pull request) remained unchanged; only the trusted facts it relied upon were corrupted.
Why Existing Defenses Fail Against ADI
Current safeguards against prompt injection focus on detecting text that reads like a smuggled order—phrases that tell the model to ignore its task or perform unintended actions. Because ADI never injects such instructions, these defenses see nothing amiss. The agent’s reasoning process may even look perfectly sensible: it shows a logical chain of steps based on the falsified data, and any built‑in “show reasoning” feature displays a plausible narrative. Consequently, the attack slips through layers designed to stop instruction‑level subversion while compromising the integrity of the data the agent treats as ground truth.
Effective Mitigations and Their Trade‑offs
Several strategies showed promise in reducing ADI success rates.
-
Unpredictable Identifiers – Tagging each page element with a random, unguessable ID (as done by ChatGPT’s Atlas browser) prevented the click‑based attack because the attacker could not forge a matching identifier. Applying a similar approach—adding a short random tag to field names—cut the attack success from roughly 49 % to 29 % in tests while preserving agent functionality.
-
Full Provenance Tracking – Maintaining a strict record of where every datum originated eliminated ADI entirely (zero successful attacks) but caused agents to complete only about a third of their normal tasks, as the overhead of tracking and verifying provenance limited their ability to process routine content.
- Delimiter Stripping – Removing punctuation that could serve as delimiters reduced the attack but also broke legitimate parsing of links, file paths, and other structured data, rendering the agents unusable for many everyday tasks.
These results indicate that lightweight mitigations like random tagging offer a practical balance, whereas stronger solutions require substantial redesigns that may impair utility.
Broader Context: Related Vulnerabilities and Lessons
ADI is not an isolated curiosity; it fits into a growing lineage of attacks that exploit the trust boundary between code and data in AI‑driven systems. Earlier in 2025, Aim Security disclosed EchoLeak (CVE‑2025‑32711), a flaw in Microsoft 365 Copilot where a specially crafted email caused the assistant to leak internal files without any user click—a classic instruction‑injection scenario. Similarly, Invariant Labs showed in May 2025 that a public GitHub issue could steer an agent into reading a private repository, again by smuggling instructions. ADI shifts the focus: instead of hiding orders, it forges who said what and what the agent already did, thereby bypassing guards that only watch for malicious commands. The underlying lesson mirrors a principle learned in traditional software engineering: keep code and data separate, and further segregate trusted data from untrusted input. Agents have embraced the first half (separating the model’s instructions from external prompts) but have neglected the second, leaving the boundary between trusted fields and attacker‑controlled content porous.
Implications for Developers and Users
For developers building AI agents, the findings underscore the need to treat all external inputs—metadata, IDs, logs—as potentially hostile and to enforce strict typing and provenance checks before using them in decision‑making. Randomized identifiers or cryptographic tags for trusted fields can raise the attack barrier without sacrificing usability. For end‑users, vigilance remains essential: even when an agent asks for confirmation before a risky action, the confirmation message may be grounded in fabricated facts, making the prompt appear legitimate. Users should, where possible, verify critical actions through independent channels (e.g., checking a purchase receipt outside the agent’s interface) and favor agents that provide transparent, auditable logs of data provenance.
Conclusion
Agent Data Injection reveals a subtle but potent weakness in how contemporary language‑model‑based agents interpret the structure of the data they consume. By exploiting the model’s probabilistic handling of delimiters, attackers can corrupt the trusted facts that guide an agent’s behavior while leaving the agent’s overt task intact. Existing prompt‑injection defenses, which hunt for hidden orders, are ineffective against this lower‑layer manipulation. Mitigations exist—particularly random tagging of data fields and robust provenance tracking—but they involve trade‑offs between security and functionality. As AI agents become more deeply embedded in web browsing, coding assistance, and collaborative development, addressing the trust gap between code, data, and user intent will be crucial to prevent seemingly innocuous interactions from turning into unintended purchases, unauthorized code execution, or silent supply‑chain compromises. The researchers’ release of benchmarking tools and attack code offers a valuable starting point for vendors and the broader community to harden these systems against this emerging threat.