Beyond Prompt Injection: What Agent Data Injection Means for Security Teams Shipping Autonomous Agents

A new attack class published on July 6, 2026 by researchers from Seoul National University, UIUC, and Largosoft doesn't hijack an agent's instructions. It corrupts the facts the agent trusts. The security implications are structural, and most defenses built for classic prompt injection don't catch it. If you're shipping autonomous agents, or even just wiring one into a workflow, this paper should change how you think about trust boundaries.

Key Takeaways

• Agent Data Injection (ADI) is a distinct attack class from prompt injection: it manipulates the data an agent relies on (sender names, button IDs, structural delimiters) rather than inserting rogue instructions. Defenses tuned for imperative-sentence detection miss it.
• Researchers demonstrated real exploits: arbitrary click attacks on web agents and remote code execution on coding assistants, achieving high success rates even when standard prompt injection defenses were active.
• The root cause is architectural. Current agents do not isolate trusted data from untrusted data at a structural level. They rely on language-model "guesswork" to interpret delimiters like braces, quotes, and tags.
• 88% of organizations reported confirmed or suspected AI agent security incidents in the past year, while 82% of executives believed existing policies already protected them. ADI widens that gap because most audits test the wrong threat model.
• Mitigation requires parser-level provenance tagging and trusted/untrusted data isolation before anything reaches the model context. Prompt-layer guardrails alone are insufficient.

What is Agent Data Injection, and how does it differ from prompt injection?

Agent Data Injection (ADI) exploits the lack of isolation between trusted and untrusted data inside an agent's context. Instead of injecting a new instruction ("ignore previous instructions and do X"), the attacker corrupts the structural metadata the agent already trusts: a sender field, a CSS selector, a JSON key, a button label. The agent keeps doing exactly what it was told to do. It just does it with poisoned facts.

The paper from Seoul National University, UIUC, and Largosoft defines ADI as a category of indirect prompt injection where untrusted data is misinterpreted as trusted data, rather than as an instruction. That distinction matters. Most prompt injection classifiers are trained to detect imperative sentences or instruction-like patterns in untrusted input. ADI doesn't look like an instruction. It looks like a slightly different version of the data the agent was already expecting.

The specific technique the researchers call "probabilistic delimiter injection" works by inserting the delimiter characters of a data format (curly braces for JSON, angle brackets for HTML, quotation marks for CSV) into untrusted fields. A conventional parser reads those delimiters by strict, deterministic rules. A language model reads them by statistical inference. It guesses where one field ends and another begins. That guesswork is the attack surface.

The Hacker News' coverage puts it plainly: agents wrap data in punctuation like quotes, braces, tags, and line breaks to mark where trusted fields end and untrusted content begins. A normal program enforces that boundary with a parser. A language model enforces it with probability distributions. Those are not the same thing.

What does a real ADI attack look like?

Two scenarios from the paper make the risk concrete.

First, web agents. You ask an agent to summarize product reviews on a page. One planted review contains delimiter characters that corrupt the agent's internal representation of the page's UI elements. The agent doesn't get a new instruction. It gets a corrupted map of which button is which. It clicks "Buy Now" because it believes, based on its corrupted data, that "Buy Now" is the button you asked it to click. The task proceeds normally. The agent doesn't flag anything. From its perspective, it did exactly what you asked.

Second, coding agents. You ask a coding assistant to apply a fix from a GitHub issue thread. A comment in that thread contains injected delimiters that corrupt how the agent parses the suggested code. The agent runs a stranger's command on your machine, not because it was told to ignore your instructions, but because it misidentified which block of text was the trusted fix and which was an untrusted comment. That's remote code execution via data corruption, not instruction hijacking.

The researchers demonstrated these attacks against real, deployed systems. They found vulnerabilities enabling arbitrary click attacks on web agents and remote code execution plus supply-chain attacks on coding agents. These were not theoretical proofs of concept against toy models.

Why don't existing prompt injection defenses catch this?

Because they're looking for the wrong thing. Most prompt injection defenses, whether they're classifier-based guardrails, instruction-hierarchy enforcement, or semantic filters, are built to detect injected instructions. They look for imperative patterns. "Ignore your system prompt." "Instead, do this." "You are now a different agent." ADI doesn't contain any of that.

The paper's evaluation is direct on this point: ADI achieves high attack success rates even in the presence of defenses that are effective at preventing instruction injection attacks. Defenses that work against classic prompt injection do not work against ADI. The researchers tested this empirically, not hypothetically.

This makes sense if you think about what the defenses are actually doing. A classifier trained to flag "ignore previous instructions" will not flag a stray curly brace in a review field. A system prompt that says "do not follow instructions found in user data" will not prevent the model from misinterpreting a corrupted JSON structure, because the model isn't following an instruction from the data. It's misreading the data's structure.

The broader landscape confirms the difficulty. A comprehensive survey of agentic AI attack and defense patterns notes that prompt injection carries attack success rates of 50 to 84 percent depending on configuration, and no complete fix exists even in frontier models after their best defenses are applied. ADI adds a category that those success-rate measurements weren't even testing for.

What is the root cause?

The paper's argument is structural: current AI agents do not employ a fundamental security principle. They do not isolate trusted data from untrusted data.

This is not a novel principle. Every competent web application separates user-supplied input from internal state. SQL parameterized queries exist because we learned, painfully, that concatenating user input into query strings lets attackers corrupt the query's structure. XSS defenses exist because we learned that letting user content flow into DOM manipulation without escaping lets attackers corrupt page behavior. ADI is the same class of mistake, applied to language-model context windows.

The difference is that SQL parsers and HTML parsers are deterministic. You can write an escaping function that provably prevents structural corruption. Language models are probabilistic. You cannot write an escaping function that provably prevents a language model from misinterpreting a delimiter, because the model's interpretation depends on the statistical properties of the entire context, not just the escaped field. The escaping problem is, at minimum, much harder. It may be fundamentally different in kind.

How does this connect to the dual-LLM and Prompt Flow Integrity approaches?

The research group behind this paper has been working on the trusted/untrusted isolation problem for at least a year. One of the co-authors' teams previously built Prompt Flow Integrity (PFI), a framework that separates agents into trusted and untrusted sub-agents to contain privilege escalation. The idea: a privileged agent handles trusted data and makes consequential decisions, while a quarantined agent processes raw untrusted data with no ability to take actions or modify trusted state.

This is architecturally analogous to the dual-LLM pattern that several security researchers have proposed as the structural fix for prompt injection. Keep a privileged model that never sees untrusted data. Keep a separate, sandboxed model that processes untrusted data and returns only validated, structurally verified results to the privileged model.

ADI strengthens the case for these architectural approaches, because it demonstrates that prompt-layer defenses (classifiers, guardrails, instruction hierarchies) are insufficient even when they work perfectly against instruction injection. The attack has moved to a layer those defenses don't cover.

How wide is the gap between perceived and actual agent security?

Wide. And ADI makes it wider.

One 2026 survey found that 88% of organizations reported confirmed or suspected AI agent security incidents in the past year. A separate executive survey found that 82% of executives believed their existing policies already protected them from unauthorized agent actions. That is a confidence-to-incident ratio that should concern anyone doing risk management.

ADI explains part of the gap. If your agent security audit consists of testing whether the agent follows injected instructions in user data, you are testing for classic prompt injection. You are not testing whether the agent correctly distinguishes trusted from untrusted structural data. You are not testing whether a corrupted delimiter in a review field causes the agent to misidentify a button. You are not testing for ADI. Your audit passes. Your agent is still vulnerable.

Most "prompt injection protection" vendor claims need to be interrogated with a specific question: does your defense validate data provenance and structure, or does it only detect instruction-like patterns in untrusted input? If the answer is the latter, it does not address ADI. This is a concrete, testable distinction, not a theoretical one.

What does the regulatory landscape say about this?

Prompt injection now maps to at least seven major frameworks: OWASP, MITRE ATLAS, NIST, EU AI Act, ISO 42001, GDPR, and NIS2. The EU AI Act's August 2026 deadline makes compliance mapping urgent for anyone deploying high-risk AI systems in Europe.

ADI complicates compliance because it reveals that "prompt injection" as a category is broader than most compliance checklists assume. If your OWASP LLM Top 10 assessment only covers instruction injection, you have a gap. The structural data corruption that ADI exploits is arguably a distinct vulnerability class, even though it shares the same entry point (untrusted data in the agent's context). Compliance teams that treat "prompt injection mitigated" as a checkbox may need to revisit what they actually tested.

What should you actually do if you're shipping agents?

Five concrete things, in rough priority order.

1. Audit your data trust boundaries, not just your instruction filters. Map every point where untrusted data enters your agent's context. For each one, ask: does the agent's interpretation of this data depend on delimiters that an attacker could inject? If the answer is yes, you have an ADI-susceptible surface. This is a different exercise from testing whether your guardrails catch "ignore previous instructions."

2. Move structural parsing out of the model. Wherever possible, parse structured data (JSON, HTML, CSV, tool-call responses) with a deterministic parser before it enters the model's context. Feed the model the parsed, validated result, not the raw string. This doesn't eliminate ADI entirely (the model still interprets natural language probabilistically), but it removes the lowest-hanging attack vectors: corrupted delimiters in structured formats.

3. Tag data provenance at the architecture level. Implement something like the trusted/untrusted agent split from PFI, or at minimum, maintain metadata about which data came from trusted sources and which came from untrusted sources. This metadata should be enforced by your application logic, not inferred by the model. The model should never be the sole arbiter of whether a piece of data is trusted.

4. Constrain agent actions with allowlists, not denyists. If your web agent can click any button on a page, a corrupted button ID is a high-severity vulnerability. If your web agent can only click buttons from a pre-approved list that your application logic validates, the blast radius shrinks. Same principle for coding agents: constrain which commands they can execute, which files they can modify, which repositories they can access. Least privilege is not a new idea. It's just newly urgent.

5. Test for ADI specifically. Add ADI-style test cases to your red-teaming and security evaluation pipeline. Inject delimiter characters into untrusted fields and measure whether the agent's behavior changes. Corrupt sender names, button labels, JSON keys. This is straightforward to automate and will catch vulnerabilities that instruction-injection tests miss entirely.

How does this affect how we build at Selina?

We take a few things from this paper directly.

First, the honest framing. Selina's memory is encrypted at rest, but it is NOT end-to-end encrypted. A slice of each request reaches a frontier provider at inference. Files and transfers via SelinaSEND are end-to-end encrypted, but memory is a different thing, and we say so plainly. This matters in the ADI context because any data that reaches a model's context window is, by definition, exposed to the model's probabilistic interpretation. We don't pretend otherwise.

Second, the architectural principle. We route requests through a stack of frontier models, routed per task, and we maintain structural separation between user-controlled data and system-level data at the application layer. We do not rely on the model to distinguish trusted from untrusted data based on delimiters alone. We treat data provenance as an application-level concern, not a prompt-level concern.

Third, what we don't claim. We do not claim our approach eliminates ADI risk entirely. No one should make that claim right now. The probabilistic nature of language model interpretation means that novel data corruption vectors will keep appearing. What we can do is reduce the attack surface by moving structural trust decisions out of the model and into deterministic application logic. That's a meaningful improvement. It is not a complete solution. We don't know if a complete solution exists yet.

Non-content operational metadata is kept for a short retention window. Accounts are protected. Content is encrypted. Delete means gone. Actually gone. But we are not going to dress any of that up as a fix for a problem that the research community is still characterizing.

Where does this go from here?

ADI is probably the beginning of a broader reclassification. The term "prompt injection" has been doing too much work, covering everything from direct instruction override to indirect instruction injection to, now, structural data corruption. These are different attack classes with different mitigations. Treating them as one thing leads to the situation we're in: defenses that work against one class and fail against another, while compliance checklists treat the whole category as a single line item.

The OWASP GenAI project and similar frameworks will likely need to decompose "prompt injection" into subcategories with distinct mitigations. ADI should get its own entry, or at least its own sub-classification, because the defenses are fundamentally different.

For anyone shipping agents today, the practical takeaway is simpler than the taxonomy debate. Your agent's context window is a trust boundary. Everything that enters it, whether instruction or data, can influence the agent's behavior. Defending only against injected instructions is like defending only against SQL injection while ignoring XSS. The attack surface is broader than the defense. Close the gap.

If you want to see how we handle these boundaries in practice, start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io