Agent Data Injection: SQL injection, different decade

A preprint out of Seoul National University, the University of Illinois Urbana-Champaign, and Largosoft describes something the authors call Agent Data Injection. The mechanism is uncomfortably familiar: an attacker plants punctuation — escaped quotes, curly quotes, dollar signs — inside a field the AI agent is supposed to treat as pure data, and the language model, parsing probabilistically rather than strictly, treats that punctuation as a real structural delimiter. The agent then keeps doing the job you asked it to do, only the “structure” it thinks it’s following is now one the attacker wrote.

If that sounds like something you’ve read before, you have. Twice. Maybe three times.

What the paper actually shows

In the web-agent demonstrations, a single planted product review reuses the target page’s “Buy Now” button ID inside curly quotes. The agent — the authors ran it against Claude in Chrome, Google Antigravity, and Nanobrowser — reads the ID as a real element it’s been told to click, and clicks it. In the coding-assistant demonstrations, run against Claude Code, OpenAI Codex, and Google Gemini CLI, a GitHub comment styled to look as though it came from the repository maintainer gets the agent to run the attacker’s command instead of the maintainer’s. A faked check record convinces an agent to approve a pull request that shouldn’t be approved.

None of these attacks corrupt the agent’s instructions. They corrupt the agent’s facts — the strings the agent was told to trust as inert data — and then the agent carries on with your original task, only now with the attacker’s facts substituted for the ones it started with. Lead author Woohyuk Choi, working with Prof. Byoungyoung Lee, told The Hacker News they’ve “not been informed of any fix, whether shipped or planned.” The paper is a preprint from July 6; no CVE has been issued.

The mitigation menu

The paper’s defenses read, at a distance, like the SQL-injection playbook adjusted for probability instead of parse trees.

• Random, unguessable element IDs instead of sequential counters drop attack success from about 49% to 29%. Not a fix. A reduction.
• Full provenance tracking — knowing which bytes came from the user and which came from a fetched review — eliminates the attack, and also breaks 67% of the agent’s task completions. Correct answer, wrong axis.
• Stripping punctuation from untrusted data works for the demonstrated attacks and breaks legitimate link and path parsing right alongside them.
• Structured output that cleanly separates trusted from untrusted regions is the closest thing to a real answer here, and it requires the model, the agent framework, and every tool the agent talks to to agree on where the boundary lives.

That’s the pattern, and it’s the pattern from every previous version of this problem. When you accept untrusted input into a context that will later be parsed as structure, you get injection. When you try to strip the input, you lose functionality. When you try to fix the parser, you find out the parser is doing what it was designed to do. The real fix is the trust boundary, and the trust boundary is the hard part.

The same mistake, different decade

We’ve been here before. SQL injection was the mistake of letting untrusted strings enter a context that a database engine would later parse as query structure. XSS was the same mistake in a browser. Template injection was the same mistake in whichever templating language you liked. Log injection. Command injection. Deserialization. Each time, the response was some combination of parameterized inputs, output encoding, sandboxes, and — eventually — a widespread agreement about where the boundary between code and data lived.

Language models don’t have that boundary. That’s most of what makes them useful, and it’s most of what makes them dangerous. A well-scoped agent handed a mostly-trusted context can do a great deal of legitimate work; the same agent handed a context with one hostile review inside it will do the attacker’s work with the same enthusiasm. Choi’s paper is a careful catalog of that fact, situated alongside prior work like EchoLeak and Invariant Labs’ May 2025 GitHub disclosure. It is not — and this is the part I keep circling back to — a novel discovery so much as a reminder, delivered by a very careful team, that the discipline of separating code from data is a thirty-year-old lesson the industry keeps re-learning under new names.

It is also the fourth or fifth such reminder this month. Manifold Security’s Claude for Chrome trust-boundary work came from a different direction and found the same shape of hole. So did the PNG-embedded prompt injection against CodeRabbit and Bugbot. So did the friendly-fire PoC against Claude Code and Codex review. Different researchers, different agents, the same class of finding: the model treats the wrong string as authoritative, and there is no clean architectural fix on offer yet.

Right now, the AI-agent version of that lesson has no CVE, no vendor patch, and no widely-adopted defense pattern. Provenance and structured outputs will probably get us most of the way there eventually. In the meantime, the agents will keep parsing untrusted structure as if it were trusted structure, and defenders will keep being told this is a nuance of how language models “understand” text. It isn’t a nuance. It’s an old bug in new clothes.