A research framework called MOSAIC successfully compromised AI coding agents in 96.59% of 2,525 attempts — against real tools, under normal developer workflows, without injecting a single malicious instruction. The paper (arXiv:2607.02857), published this month by researchers from Seoul National University, UIUC, and Largosoft, introduces a new attack category called CLI command-composition risk (CCR). It is not prompt injection. Existing defenses don’t detect it. Vendors haven’t patched it.
The Attack That Doesn’t Look Like an Attack #
Prompt injection works by embedding fake instructions in data so the model treats attacker text as developer commands. CCR doesn’t touch that mechanism at all. Instead, it exploits the shared operating-system state that accumulates as a coding agent runs ordinary CLI commands.
Here’s the structural problem: when a coding agent runs git clone
, then npm install
, then npm run build
, each command writes and reads from shared state — environment variables, .git/hooks
, node_modules
, lifecycle scripts. Individually, every step is legitimate. Together, they form a producer-consumer chain that an attacker can pre-load with a payload. The agent composes the attack itself, using the tools it’s supposed to use.
MOSAIC automates this. It distills real CVEs and published PoCs into reusable attack summaries, composes them into exploit paths, then instantiates them as realistic developer workflows. The target agent never sees anything that looks like an attack. It just does its job.
What the Numbers Actually Mean #
96.59% across 2,525 trials and five real-world CLI coding agents isn’t a cherry-picked benchmark — it’s a systematic evaluation across five different LLM backends including GPT-5.6 and Claude Sonnet 5. The model didn’t matter. The agent type didn’t matter much either.
The companion benchmark, MOSAIC-Bench (arXiv:2605.03952), sharpens the picture: nine production coding agents from Anthropic, OpenAI, Google, Moonshot, Zhipu, and Minimax completed staged attack chains at 53–86% end-to-end success rates. Across all runs, the agents refused only twice. Two refusals, nine agents, hundreds of attack sequences. Every other attempt succeeded.
For context: Adversa AI’s GuardFall research, which tested Bash shell tricks instead of composed CVE chains, found 10 of 11 open-source agents vulnerable. These are not edge cases. This is the default state of the ecosystem.
Concrete Attack: What It Looks Like in Practice #
The simplest version: an attacker publishes a repository with a poisoned postinstall
script buried in package.json
. A developer asks their coding agent to audit the project. The agent clones the repo, runs npm install
to understand the dependency graph, and the postinstall hook fires during npm run build
— silently exfiltrating AWS_SECRET_ACCESS_KEY
from the environment. The agent never ran anything it wouldn’t normally run.
More sophisticated versions target git hooks. git clone
writes the .git/hooks
directory. A subsequent git commit
or git push
the agent makes triggers attacker-controlled code. The producer-consumer chain here is: clone (writes hooks) → commit (executes hooks). Both operations are routine. Neither individually flags any defense.
CI/CD pipelines are the worst-case exposure. In auto-mode, coding agents run without human review of individual commands. The attack surface is everything the pipeline touches.
Why Sandboxing Doesn’t Solve This #
Every major vendor has shipped sandbox features in 2026. Anthropic added restricted permission modes to Claude Code. OpenAI runs Codex in isolated environments. Google Cloud Run Sandboxes went GA earlier this month. None of this addresses CCR.
The problem: sandboxing restricts what the agent can access, not what the agent can be made to do within its scope. Environment variables propagate inside the sandbox. Package lifecycle hooks run inside the sandbox. Git hooks run inside the sandbox. The attacker’s payload executes entirely within the agent’s legitimate operating area. There’s nothing for the sandbox to block.
As Microsoft’s security team put it: “the attacker doesn’t need to escape the sandbox — the agent’s own tool-use is the execution path.” TrustFall, disclosed last month, showed that Claude Code, Cursor, Gemini CLI, and Copilot all auto-execute project-defined MCP server configs on folder trust — before the sandbox even initializes.
The honest assessment: vendors are patching individual CVEs. CCR isn’t a CVE. It’s an architecture problem.
What to Do Now #
No patch is coming for the structural issue. These mitigations reduce risk:
Ephemeral environments: Each agent task should get a fresh VM with no prior state. Modal, Daytona, and E2B all offer this. Without shared state, CCR chains can’t form.Strip credentials from the environment: Never run a coding agent with long-lived cloud credentials in scope. Use short-lived tokens, instance roles, or Workload Identity Federation. If the postinstall hook fires, there’s nothing valuable to exfiltrate.Allowlists over denylists: Define explicitly which commands the agent may run. Denylist evasion is trivial with shell tricks. Allowlist evasion requires the attacker to know your policy.Audit command logs: Log every agent command invocation with the originating task and environmental context. Flag sequences where a read-only operation precedes an unexpected write.Treat agent CI runs as untrusted execution: Apply the same skepticism to agent-assisted CI jobs as you would to any third-party code running in your pipeline.
The MOSAIC paper is worth reading in full if you’re responsible for CI/CD security or team tooling decisions. The companion benchmark has the data on which specific agent categories are most exposed.
Coding agents are not going away — the productivity gains are real. But running them with developer-level trust in shared environments is the equivalent of giving a contractor a master key and leaving them unsupervised. Most contractors are fine. The one that isn’t will cost you everything.