Your coding agent trusts metadata. That's the problem.

Okay. Let me start with the scenario that actually hurts.

Your coding agent reads a JSON file, a webpage’s DOM, or a GitHub issue. Somewhere in there, an attacker has slipped in a fake field that looks exactly like legitimate metadata — a resource ID, a commit origin, a “posted by the maintainer.” The agent doesn’t get tricked by an instruction. It gets tricked by data it believes is trustworthy.

That’s exactly what a paper published in early July 2026 on arXiv describes, around a technique called Agent Data Injection (ADI). And honestly, it’s more worrying than classic prompt injection, because it doesn’t even need the agent to execute an attacker-controlled task. It just needs the agent to believe a lie about where the data came from.

The delimiter doesn’t need to be exact

The technical flaw is called probabilistic delimiter injection. The idea: an LLM doesn’t parse a JSON structure or a DOM like a deterministic parser. It interprets it probabilistically. So an injected delimiter — say, an escaped quote that a real JSON parser would reject outright — can be enough to make the model believe it just read a valid structural boundary. The result: fake metadata shows up as authentic in the agent’s eyes, when a classic system would have rejected it at the door.

The researchers tested this on three coding agents — Claude Code, Codex, and Gemini CLI — and three web agents (Claude in Chrome, Antigravity, Nanobrowser). All vulnerable, to varying degrees.

Three concrete attacks, not lab scenarios

What makes the paper useful is that it doesn’t stay abstract. Three demonstrated attacks, directly transferable to a real agentic dev workflow:

• Remote Code Execution via forged metadata. The attacker fabricates a command origin that makes the agent believe the command comes from a repo maintainer. The agent executes it with the trust it would have granted a trusted human.
• Supply chain attack. The attacker fabricates an entire tool-call block — the kind of structure the agent uses to say “I checked the code, I’m merging.” Except it checked nothing at all. The malicious PR goes through.
• Arbitrary click on web agents: a fake UI element with an identifier that matches a real element, to make the agent click a sensitive button it never actually chose.

The common thread: in all three cases, the agent doesn’t “disobey.” It does exactly what it was trained to do — trust the context metadata — except that metadata is fake.

The numbers, as reported in the study

I’m not going to dress this up as my own measurements — these are the paper’s numbers. On JSON delimiter attacks, the success rate (ASR) ranges between 31.3% and 43.3% depending on the model — GPT-5.2 at 41.8%, Claude Opus 4.5 at 34.3%, Gemini 3 Flash at 43.3%. On web DOM, it climbs as high as 100% for some models.

More interesting: at the full-agent level (not just the bare LLM), on the AgentDojo benchmark, ADI hits 49.1% ASR at baseline — versus 0.2% for classic instruction injection on the same agent. In other words: current agents have already learned to be somewhat suspicious of suspicious instructions. They haven’t yet learned to be suspicious of metadata.

The review of 78 studies confirms this isn’t an isolated case

A second paper, a systematic review (SoK) synthesizing 78 studies published between 2021 and 2026 on the security of agentic coding assistants — explicitly naming Claude Code, GitHub Copilot, and Cursor — reaches a conclusion that should sting more than any single number: adaptive attacks exceed an 85% success rate against state-of-the-art defenses. And most of the 18 defense mechanisms analyzed in the review don’t even reach 50% mitigation against an attacker who adapts.

What does that mean in practice? That the defenses tested in the lab work against yesterday’s attack. Against an attacker who looks at your defense and adjusts their payload accordingly, they collapse.

What works a little, what doesn’t work at all

The ADI paper deserves credit for testing eight categories of defense, not just hyping one. Here’s what comes out of it, honestly.

What actually mitigates, at a real cost: strict-mode data flow tracking (data provenance tracing with tight policy) brings ASR down to 0%. But the agent’s benign usefulness drops by 50% in the same move. Agent sandboxing with precise policies brings residual ASR down to 22.2%, which is still non-negligible but cuts the risk in half.

What is basically useless: classic input guardrails, meant to filter suspicious content on input, leave ASR at 50% — essentially zero effect on ADI, even though they catch 34.9% of classic instruction injections. In other words, the guardrails we know well work on the previous generation of attack and are blind to the new one.

What works but breaks everything: randomization (attaching a random nonce to field names) drops JSON ASR to near zero. Except on web DOM, if the attacker correctly guesses the nonce, ASR climbs back up to 60-100%. And strict sanitization (stripping suspicious delimiters) drops ASR to 0-3%, but degrades the agent’s normal usefulness from 81-85% down to 68-72%. Plainly: you can secure the agent by making it half-useless.

What this actually changes in a real dev workflow

The marketing around agents talks about autonomy as a feature: the agent browses on its own, reads issues on its own, merges on its own. Every extra capability is sold as a productivity gain. Except every extra capability is also one more door for unverified, untrustworthy content.

Here’s what I’d actually take away for real use, not for a research report:

• Never grant merge autonomy to an agent without a human reviewing the actual diff, not the summary the agent produces of it. The paper’s “supply chain attack” scenario relies exactly on this: the agent claims to have verified, it verified nothing.
• Sandbox everything that executes commands. Agent sandboxing remains the only defense that showed a real, measured effect (22.2% residual ASR) without destroying usefulness, provided you have precise policies — not a vague sandbox with open network access.
• Allowlist sensitive commands, not instructions. ADI’s weak point is that the attacker forges an origin (“posted by the maintainer”), not a command per se. An allowlist that ignores the claimed provenance and relies solely on the nature of the command limits the damage.
• Treat all ingested content as untrusted by default — issues, PRs, webpages, third-party tool output. Not just the user prompt. That’s the principle most current architectures still don’t follow, according to both papers.
• Don’t wait for a magic guardrail. Classic input/output guardrails barely stop ADI at all. If your only safety net is an input content filter, you’re exposed.

My take

Coding agent security isn’t a detail we’ll fix later. It’s structurally behind the autonomy we’re handing these agents. The more an agent can browse, read, execute, and merge on its own, the bigger the attack surface — and the defenses that exist today, tested seriously, either hold up by breaking usefulness, or don’t hold up at all against an attacker who adapts.

That doesn’t mean you should throw agents out. It means you should stop selling autonomy as a feature without counting the cost of the surface it opens up. Human-in-the-loop on sensitive actions isn’t a compliance checkbox. At this point, it’s the only thing that actually works.

Sources

• Agent Data Injection Attacks — arXiv:2607.05120v1
• Prompt Injection Attacks on Agentic Coding Assistants: A Systematic Analysis of Vulnerabilities in Skills, Tools, and Protocol Ecosystems — arXiv:2601.17548