{"slug": "mosaic-attack-ai-coding-agents-fail-96-of-the-time", "title": "MOSAIC Attack: AI Coding Agents Fail 96% of the Time", "summary": "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.", "body_md": "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.\n\n## The Attack That Doesn’t Look Like an Attack\n\nPrompt 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.\n\nHere’s the structural problem: when a coding agent runs `git clone`\n\n, then `npm install`\n\n, then `npm run build`\n\n, each command writes and reads from shared state — environment variables, `.git/hooks`\n\n, `node_modules`\n\n, 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.\n\nMOSAIC 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.\n\n## What the Numbers Actually Mean\n\n96.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.\n\nThe 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.\n\nFor 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.\n\n## Concrete Attack: What It Looks Like in Practice\n\nThe simplest version: an attacker publishes a repository with a poisoned `postinstall`\n\nscript buried in `package.json`\n\n. A developer asks their coding agent to audit the project. The agent clones the repo, runs `npm install`\n\nto understand the dependency graph, and the postinstall hook fires during `npm run build`\n\n— silently exfiltrating `AWS_SECRET_ACCESS_KEY`\n\nfrom the environment. The agent never ran anything it wouldn’t normally run.\n\nMore sophisticated versions target git hooks. `git clone`\n\nwrites the `.git/hooks`\n\ndirectory. A subsequent `git commit`\n\nor `git push`\n\nthe 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.\n\nCI/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.\n\n## Why Sandboxing Doesn’t Solve This\n\nEvery 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.\n\nThe 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.\n\nAs [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.\n\nThe honest assessment: vendors are patching individual CVEs. CCR isn’t a CVE. It’s an architecture problem.\n\n## What to Do Now\n\nNo patch is coming for the structural issue. These mitigations reduce risk:\n\n**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.\n\nThe [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.\n\nCoding 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.", "url": "https://wpnews.pro/news/mosaic-attack-ai-coding-agents-fail-96-of-the-time", "canonical_source": "https://byteiota.com/mosaic-cli-attack-coding-agents/", "published_at": "2026-07-17 20:21:31+00:00", "updated_at": "2026-07-17 20:32:40.455725+00:00", "lang": "en", "topics": ["ai-safety", "ai-agents", "ai-research"], "entities": ["Seoul National University", "UIUC", "Largosoft", "Anthropic", "OpenAI", "Google", "Moonshot", "Zhipu"], "alternates": {"html": "https://wpnews.pro/news/mosaic-attack-ai-coding-agents-fail-96-of-the-time", "markdown": "https://wpnews.pro/news/mosaic-attack-ai-coding-agents-fail-96-of-the-time.md", "text": "https://wpnews.pro/news/mosaic-attack-ai-coding-agents-fail-96-of-the-time.txt", "jsonld": "https://wpnews.pro/news/mosaic-attack-ai-coding-agents-fail-96-of-the-time.jsonld"}}