MOSAIC Attack: AI Coding Agents Fail 96% of the Time

A new research framework called MOSAIC has demonstrated that AI coding agents can be compromised 96.59% of the time by exploiting shared operating-system state from legitimate CLI commands, without using prompt injection. The attack, detailed in a paper by researchers from Seoul National University, UIUC, and Largosoft, targets real tools under normal developer workflows and has not been patched by vendors.

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 https://arxiv.org/abs/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 https://arxiv.org/abs/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 https://www.securityweek.com/decades-old-bash-tricks-expose-ai-coding-agents-to-supply-chain-attacks/ , 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 https://www.microsoft.com/en-us/security/blog/2026/05/07/prompts-become-shells-rce-vulnerabilities-ai-agent-frameworks/ : “the attacker doesn’t need to escape the sandbox — the agent’s own tool-use is the execution path.” TrustFall https://adversa.ai/blog/trustfall-coding-agent-security-flaw-rce-claude-cursor-gemini-cli-copilot/ , 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 https://arxiv.org/abs/2607.02857 is worth reading in full if you’re responsible for CI/CD security or team tooling decisions. The companion benchmark https://arxiv.org/abs/2605.03952 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.