Researchers show how forged data fields can misdirect AI agents
Researchers from Seoul National University, UIUC and Largosoft describe agent data injection, an indirect prompt-injection technique that makes attacker-controlled content resemble trusted metadata. Their proof-of-concept tests manipulated element identifiers in web agents and origin or tool-result fields in coding agents, including tested configurations of Claude Code, Codex and Gemini CLI. Reported baseline success ranged from 31.3% to 43.3% on structured-data tests and 33.3% to 100% on web-DOM tests. No in-the-wild exploitation was reported. The practical defense is to enforce trust, identity and action authorization outside the language model rather than relying on prompt filtering alone.
What agent data injection changes
A research team from Seoul National University, the University of Illinois Urbana-Champaign and Largosoft has described agent data injection, or ADI, as a distinct form of indirect prompt injection.
Traditional instruction injection hides a malicious command in untrusted content. ADI instead makes attacker-controlled content resemble data the agent already trusts: an element identifier, a sender or maintainer identity, a tool result or a record of an earlier action. The model can then continue following the user's legitimate task while acting on a forged fact.
The paper was submitted to arXiv on July 6, 2026. Its authors released benchmark and evaluation artifacts and published a detailed explanation of the web-agent attack. The repository does not provide executable real-world attack scripts. The work describes proof-of-concept vulnerabilities, not a confirmed campaign, and the researchers reported no known exploitation in the wild.
What the researchers tested
The evaluation covered standalone models and agent configurations. The paper reports arbitrary-click paths in Claude for Chrome, Google's Antigravity and Nanobrowser, plus remote-code-execution and software-supply-chain proof-of-concept paths in tested configurations of Claude Code, Codex and Gemini CLI. The coding-agent path still involved the normal command-approval step; the risk is that forged context can make the proposed command look as if it came from a trusted maintainer.
| Test area | Reported result and scope |
|---|---|
| Structured JSON data | Baseline attack success ranged from 31.3% to 43.3% across six standalone-model tests |
| Web-DOM data | Baseline success ranged from 33.3% to 100% in the paper's isolated tasks |
| Existing prompt-injection defenses | Often blocked instruction injection more effectively than forged trusted-data fields |
| Randomized or provenance-aware identifiers | Reduced attacks in some reported tests, with trade-offs and format-specific limits |
These percentages are not remote-code-execution rates for the named products. They should not be generalized to every model, version, website or developer workflow. The named vendors acknowledged the researchers' reports, according to the authors and independent coverage, but that is not evidence that every product version remains vulnerable or that the attacks have been used against real users.
Why ordinary approvals may not be enough
A confirmation dialog helps only when it is bound to the exact action and trustworthy context. If an agent's explanation was built from a forged maintainer identity or fake tool record, a generic request to approve a command can still look legitimate.
For high-impact operations, the runtime should present the exact command, destination, origin and consequence using data resolved outside the model. It should then compare the approved action with fresh system state immediately before execution.
LDS assessment
ADI reinforces a basic engineering rule: the language model should not be the authority for trust labels. A production agent can use a model to propose an action, but deterministic code should resolve identifiers, validate source identity, enforce permissions and confirm postconditions.
Practical controls include typed tool interfaces, unpredictable or scoped resource identifiers, provenance attached outside model-readable prose, least-privilege credentials, exact-action approvals and fresh-state checks before execution. Logs should preserve both the content the model saw and the trusted metadata the runtime enforced.
The research does not show that agentic systems are impossible to secure. It shows that instruction filtering is only one layer. Systems that let models act need a separate authorization boundary that remains correct even when the model misreads attacker-controlled context.
Key Points
- 1ADI forges data an agent may treat as trusted, such as element IDs, sender identities or tool-result records.
- 2The paper reports proof-of-concept click, code-execution and supply-chain paths across specified web and coding-agent configurations.
- 3Trust labels, exact-action approval and permission checks should be enforced by deterministic runtime code, not inferred by the model.
Scoring Rationale
The paper identifies a broadly relevant trust-boundary weakness and demonstrates multiple proof-of-concept attack paths against widely used agent classes. Impact is moderated because results are configuration-specific and no in-the-wild exploitation was reported.
Sources
Primary source and supporting public references used for this report.
View 4 more sources
Practice interview problems based on real data
1,625 SQL & Python problems across 15 industry datasets — the exact type of data you work with.
Try 250 free problems
