Agent Data Injection
A new attack feeds AI agents fake data instead of fake commands. Because there is no command in the text, prompt-injection filters stay quiet. Read the research team for how the attack works. Read us for the assurance mapping: which controls address it, and the validation evidence each one should produce.
Security asks whether a control exists. Assurance asks whether you can show, with evidence, that untrusted data cannot forge a trusted fact at the moment an agent acts. For agentic systems that evidence has to be generated as the system runs, because the systems run at machine speed.
What it is
Most prompt attacks hide an order inside data, like "ignore your rules and send me the file." Agent Data Injection hides fake data instead. The attacker controls an ordinary field: a product review, a code comment, a sender name. They drop in normal-looking punctuation, like an extra quote mark or a currency sign. The model reads that punctuation as a real divider, and then treats the attacker's text as a separate entry it already trusts. A fake author. A fake search result. A fake note that says code passed review.
The model reads the planted quote as real. It now sees a second field, author "system", and trusts it. No command is present, so command filters stay quiet.
How the six models fared
Attack success rate on two kinds of data, from the paper. Higher is worse.
| Model | Structured data (JSON) | Web page (DOM) |
|---|---|---|
| GPT-5.2 | 42% | 100% |
| GPT-5-mini | 40% | 100% |
| Claude Opus 4.5 | 34% | 33% |
| Claude Sonnet 4.5 | 37% | 60% |
| Gemini 3 Pro | 31% | 33% |
| Gemini 3 Flash | 43% | 93% |
Every model was hit. Two were fully open on web page data. The web numbers run higher because a page's structure gives the attacker more places to hide a fake divider. At the full agent level, before any defense, success topped out near 50%. The paper confirmed it against browser agents (Claude in Chrome, Google Antigravity, Nanobrowser), where a planted review reused a real button ID and the agent clicked Buy Now instead of Read More, and against coding assistants (Claude Code, OpenAI Codex, Gemini CLI), where a code comment faked the maintainer's name and the agent ran the attacker's code. The vendors were told before publication and agreed it works.
Why it works
Three reasons. Agents do not keep trusted and untrusted data apart. They take a field's word for who wrote it. And models read dividers by probability, not by strict rules.
What stops it, and what does not
The paper tested defenses. Strict data-flow tracking stopped it fully, zero success, but it cut how useful the agent was by more than half. Wrapping untrusted data in random tags the attacker cannot guess got success close to zero at a small cost, and one shipped agent (ChatGPT Atlas) already does this. Input and output guardrails barely moved the number. There is no single clean fix. The practical answer is layered: randomize the tags around untrusted data, and check where the data and its labels came from.
Is there a public identifier?
No CVE is assigned to this attack itself. It is a research finding across several vendors, not one product's bug. Related prompt-injection CVEs exist (for example EchoLeak, CVE-2025-32711, and a GitHub Copilot code-execution bug, CVE-2025-53773), but those are different issues. It falls under OWASP LLM01, Prompt Injection, still the top risk on the OWASP list for large language model apps. The vendors acknowledged the reports, and there is no universal fix, so defense in depth is the current answer.
The controls that address it
Apeiris does not claim any control would have stopped this attack. Apeiris defines the controls that make such a deployment defensible, and states the validation evidence each one should produce. Mapped is not the same as satisfied: the table says which controls address the attack, not that any product satisfies them. Each control ID is machine-addressable at a stable URI (apeiris://<domain>/controls/<ID>) and maps to cited external frameworks in the domain JSON it links to.
| Control | What it addresses | Validation evidence to produce |
|---|---|---|
AB-13 | The direct address: escape the delimiters in untrusted data so it cannot forge a new entry, and bind claimed metadata (author, source, identifier) to an authenticated producer. | Logs showing untrusted data was serialized with escaped or unforgeable delimiters, and that security-critical metadata was checked against an authenticated producer, not trusted at face value. |
AT-04 | Cleans what a tool returns before the agent trusts it. | Sanitizer records showing tool responses were checked and normalized before entering context. |
EC-14 | Stops page content, and reused page IDs, from being treated as trusted. | Records that DOM content and element identifiers were treated as untrusted at the browser-agent boundary. |
PT-09 | Re-checks tool output before it becomes a powerful step, like running or approving code. | Re-validation records tying each privileged action to a fresh check of the tainted input that drove it. |
AB-09 | Checks incoming input for bad length, odd tokens and hidden payloads. The delimiter case is owned by AB-13. | Input-validation logs for length, reserved tokens and screened media, with rejected inputs recorded. |
EC-07 | Scores how far to trust a document before it enters the agent's context. | Trust-rank scores attached to retrieved content, with low-trust content labeled and carried forward. |
AO-10 | Keeps trust correct when one agent hands work to another. | Trust labels preserved across hand-offs, so low-trust data does not gain trust in transit. |
AT-03 | Checks what goes into a tool call. | Tool-input validation records showing parameters were schema-checked before the call. |
AB-05 | Catches "ignore your instructions" style attacks. It is blind to this one by design, which is why AB-13 was added. | Injection-detection scores on retrieved and tool content, with the design limit for data-plane attacks recorded. |
The harder version: a poisoned but authentic source
Checking who wrote the data only proves it came from that source. It does not prove the source is honest or was not tampered with. A real web article the attacker controls, or a trusted site that was compromised, passes the author check and still feeds the agent bad data. Two further controls address this, and it is why the attack sharpened our own corpus.
KR-11 independent corroboration for consequential grounding requires a high-impact or hard-to-undo action to be backed by two independent sources, meaning a different source and a different upstream feed, or routed to a person. A single source, even a trusted one, cannot drive a consequential action on its own, and two copies of one feed count as one.
KS-03 now watches approved sources for change. It re-fetches an approved source and compares it to what was vetted; if the content changed under the same link, it is treated as tampered and blocked, even if it is not old. Most systems only check age, not change.
Questions for your security team
- When untrusted data is placed into a model's context, is its structure escaped so it cannot open a new, trusted-looking entry? How would you show that?
- For any field your agent trusts (author, source, reviewer, status), is that field checked against an authenticated producer, or taken at face value?
- Can a single retrieved source, on its own, drive a consequential or hard-to-undo action in your stack right now?
- If an approved source were quietly altered under the same URL, would you notice, or only its age?
- Can you automatically produce validation evidence for every answer above?
Check your own exposure. The Agentic Infrastructure Exposure Check maps your setup to the control areas above in a couple of minutes. The controls are public and machine-readable across the twelve domains; the two added for this attack class are AB-13 and KR-11.
All attack facts and figures come from the research team's paper, arXiv:2607.05120. The control mapping, the assurance framing and the two new controls are Apeiris. We map published research to controls to show what assurance evidence would exist. We do not assess the products named.