MOSAIC Attack: Why 96% of AI Coding Agents Can Be Compromised Without a Single Malicious Prompt
The 96% Number That Should Worry Every Developer
96.59%.
That is not a typo. That is the success rate of the MOSAIC attack on AI coding agents—tested across 2,525 attempts against popular tools. Cursor, GitHub Copilot, and their peers failed the test almost every single time.
Here is the part that turns this from concerning to chilling: not a single attempt required prompt injection. No carefully crafted jailbreaks. No adversarial suffixes. No social engineering of the language model. The MOSAIC attack framework exploited the agents’ own command-line behavior under perfectly normal developer workflows.
If you use an AI agent that can run shell commands—and millions of developers now do—this research is about your daily workflow.
What Is the MOSAIC Attack on AI Coding Agents?
MOSAIC is a research framework published in July 2026 by a collaboration between Sun Yat-sen University, Shandong University, Peking University, and Hong Kong University of Science and Technology. The paper, available on arXiv as 2607.02857, was designed to answer a deceptively simple question: how secure are AI coding agents when they interact with real-world command-line interfaces?
The answer, it turns out, is “not very.”
The researchers built MOSAIC to systematically test how agents compose and execute shell commands in response to ordinary developer requests. Think of prompts like “set up this project,” “install the dependencies,” or “run the test suite.” These are the bread and butter of AI-assisted development. The researchers wanted to know whether an attacker could hijack that natural workflow without ever touching the prompt layer.
They could. In 96.59% of cases, they did.
The breadth of testing matters here. This was not a proof-of-concept against one agent with one weird edge case. This was a systematic campaign across multiple mainstream tools, under realistic conditions, with statistically meaningful volume.
Introducing CLI Command-Composition Risk (CCR)
The MOSAIC paper does more than expose vulnerabilities. It introduces a new attack category: CLI Command-Composition Risk (CCR).
CCR is distinct from everything the AI security world has been obsessing over for the past two years. Prompt injection, jailbreaking, model alignment attacks—these all target the language model itself. They try to trick the AI into saying or doing something harmful by manipulating its input text.
CCR does not care about the model’s weights or its training alignment. It targets the agent architecture—the glue code that translates the model’s intentions into shell commands, file operations, and external tool calls.
Here is the core insight: AI coding agents do not just write code. They chain commands. When you ask an agent to “set up the project,” it might run git clone, then cd into the directory, then npm install, then execute a build script. The agent is composing a sequence of CLI commands and executing them automatically.
CCR exploits that composition logic. An attacker crafts a situation where individually benign commands, when chained together by the agent, produce a malicious outcome. Each step looks harmless in isolation. The vulnerability lives in the composition, not the components.
Existing defenses do not catch this. Prompt filters scan for malicious instructions in user input—there are none in a CCR attack. Sandboxes restrict what the model can access—but the agent is voluntarily executing shell commands on your behalf. CCR slips through the gaps between model safety and system security.
How MOSAIC Works Under the Hood
To understand why CCR is so effective, it helps to walk through how a MOSAIC-style attack unfolds.
Step 1: The Setup
The attacker prepares a repository or environment that looks entirely legitimate. It might be a helpful utility, a starter template, or a patched dependency. There is nothing overtly malicious in the repository itself. It passes every static analysis and code review you would normally run.
Step 2: The Trigger
A developer asks their AI coding agent to work with this repository. The prompt is completely ordinary: “clone this repo and set it up,” or “install this dependency and run the tests.”
Step 3: The Composition
The agent begins its normal workflow. It clones the repository, inspects the files, identifies the setup steps, and starts composing shell commands. Here is where the trap springs.
Imagine a repository contains a configuration file or script with a seemingly innocent name. The agent, following its standard logic, might run:
1 | git clone https://github.com/example/safe-looking-project.git |
But what if setup.sh is not what it seems? Or what if an earlier command—say, setting an environment variable—modifies the behavior of a later command in a way the agent does not anticipate?
In a CCR attack, the attacker architects the repository so that the sequence of commands the agent naturally generates becomes a payload. One command sets up state. Another reads from an unexpected location. A third executes a disguised binary. The agent is following its normal ReAct loop, calling tools, observing outputs, and chaining the next action. It does not realize it is being herded.
Step 4: The Payload
Because the agent often runs with the developer’s own permissions, the composed command sequence can access credentials, exfiltrate code, modify system files, or establish persistence. The agent has effectively become a confused deputy—an authorized system tricked into performing unauthorized actions on the attacker’s behalf.
Here is a simplified but representative example of what a composed chain might look like from the agent’s perspective:
1 | # Step 1: Appears benign—setting a project path |
If the CDN is compromised—or if the URL is typo-squatted or swapped via DNS—the agent has just downloaded and executed attacker-controlled code. It never received a malicious prompt. It simply composed a reasonable sequence of commands that led to a bad outcome.
Which Tools and Agents Are Affected?
The MOSAIC researchers tested a range of mainstream AI coding agents. While the paper focuses on agents with CLI access—Cursor, GitHub Copilot’s agent mode, and similar tools—the underlying vulnerability is architectural.
Any agent that:
- Parses natural language into shell commands
- Autonomously chains multiple CLI operations
- Runs with user-level or elevated permissions
…is potentially exposed to CCR.
Cursor, in particular, has embraced autonomous agent workflows where the IDE can run terminal commands, read output, and iterate without constant human approval. For a deeper look at how Cursor’s file-write confirmations can be deceived, see our coverage of the GhostApproval symlink vulnerability, which specifically examined Cursor among six affected AI coding tools. GitHub Copilot’s agent mode and similar features in other editors follow the same pattern. The productivity gains are real. So is the attack surface.
The distinction between cloud-based and local execution also matters. Cloud-based agents might run in a sandboxed container, but they often still have access to secrets, environment variables, and network egress. Local agents run with your user’s permissions, which in many developer environments includes SSH keys, cloud provider credentials, and write access to production repositories.
The MOSAIC results suggest that architecture, not brand, is the risk factor. If your tool uses a ReAct-style loop with shell access, the composition logic is exploitable. This AI coding agent security vulnerability is not limited to one vendor or platform.
Why No Malicious Prompt Injection Makes This Scarier
For the past two years, AI security discourse has revolved around prompt injection. Can you trick ChatGPT into ignoring its instructions? Can you smuggle malicious text past a content filter? Can you jailbreak a model into generating harmful code?
These are important problems. But they are also understood problems. Vendors deploy input sanitization, output filtering, and alignment training. Users learn to recognize suspicious prompts. The security community has built tooling around detecting adversarial inputs.
CCR bypasses all of that.
The attacker does not need to trick the language model. They do not even need to interact with the AI at all. They simply need to exist in the agent’s supply chain—a repository, a dependency, a CDN endpoint—and let the agent compose the attack for them.
This has profound implications for CI/CD pipelines and automated workflows. Imagine a GitHub Actions runner that uses an AI agent to review pull requests and run tests. An attacker submits a benign-looking PR. The agent checks it out, runs the tests, and executes a composed payload. No malicious prompt was ever entered. The attacker never touched the AI interface.
The threat model shifts from “users tricking AI” to “AI tricking itself.”
Real-World Impact for Developers
If you are a developer who has embraced “vibe coding”—using AI agents to generate, refactor, and run code with minimal manual intervention—this research should prompt a hard look at your workflow.
Consider the everyday tasks where agents shine:
- Dependency installation: The agent reads a
package.json,requirements.txt, orCargo.tomland installs whatever is listed. A malicious or typo-squatted dependency name becomes a CCR trigger. - Environment setup: The agent clones a repository and runs setup scripts. Those scripts can do anything the agent’s user can do.
- Deployment automation: The agent builds, tests, and deploys. A composed chain could exfiltrate secrets during the “test” phase before deployment even happens.
The attacker’s goal is not necessarily to destroy your system. It is to use your agent as a proxy. Credential exfiltration, code theft, supply chain poisoning, and lateral movement are all on the table. Because the agent operates with your identity and your permissions, the blast radius is your entire development environment.
Speed is another factor. An AI agent can execute dozens of commands in the time it takes a human to review one. If the composed payload includes cleanup steps—deleting logs, masking tracks—the compromise might leave almost no forensic trace.
Supply chain risks extend beyond agents. See our coverage of malicious llms.txt documentation files feeding instructions to AI agents for a broader look at how trust in written instructions becomes an attack surface.
Mitigations and How to Protect Your Workflow
The MOSAIC paper is not just an alarm bell. It is a roadmap for what needs to change. Here is how developers can protect themselves today, and what vendors should be building tomorrow.
For Developers: Immediate Steps
1. Treat agent execution like CI/CD.
If you would not let a GitHub Actions workflow run arbitrary shell commands without review, do not let your AI agent do it either. Enable human-in-the-loop approval for any shell command execution, especially for unknown repositories or dependencies.
2. Sandbox aggressively.
Run AI agents in restricted environments: containers, virtual machines, or dedicated user accounts with minimal permissions. Never let an agent run with your primary user’s credentials, especially if that user has access to production systems, cloud APIs, or SSH keys.
3. Whitelist, do not blacklist.
Instead of trying to catch malicious commands, define what commands are allowed and reject everything else. If the agent only needs npm install and npm test, it does not need curl, wget, or bash.
4. Audit your supply chain.
CCR attacks often enter through dependencies, cloned repositories, or external scripts. Pin your dependencies. Verify repository sources. Be skeptical of starter templates and setup scripts, especially from unfamiliar authors.
5. Monitor agent logs.
If your agent produces a log of commands executed, review it. Look for unexpected sequences, especially environment variable changes followed by downloads or executions.
For more on securing automated workflows, treat AI agent execution the same way you would treat any other unattended CI/CD step: reviewed, sandboxed, and logged.
For Vendors: What the Community Should Demand
- Command-level permission models: Agents should request explicit approval for sensitive operations like network requests, file writes outside the project directory, and execution of downloaded scripts.
- Composition-aware analysis: Security tooling should analyze command sequences, not just individual commands. If
export FOO=barmakesnpm installbehave maliciously, the sequence should be flagged. - Isolated execution environments: Every agent session should run in a fresh, restricted container with no access to host credentials or persistent state.
- Transparent logging and rollback: Users should be able to see exactly what an agent did and undo it cleanly.
The Bigger Picture: Agent Security Is the Next Frontier
MOSAIC and CCR represent a pivot point in AI security research.
For years, the field has focused on model alignment: making language models refuse harmful requests, detect adversarial inputs, and stay within guardrails. That work remains essential. But as AI systems gain the ability to act—to run code, access files, and interact with external services—the vulnerabilities move downstream.
The agent architecture is the new frontier. ReAct loops, tool use, memory, and command composition are where the next class of exploits will live. Attackers will not need to break the model if they can break how the model uses its tools — the same lesson we drew from the trojanized AI agent skills that reached 1.7 million installs before anyone noticed.
This is not a reason to abandon AI coding agents. The productivity gains are genuine, and the technology is maturing rapidly. But it is a reason to stop treating them as fancy autocomplete and start treating them as privileged automation—with the security posture to match.
The 96.59% figure is memorable because it is shocking. It should also be temporary. The research community has done its job by identifying CCR. Now it is on vendors and developers to close the gap before attackers turn MOSAIC from a proof-of-concept into a playbook.
Trust your tools. Just do not trust them blindly.
References and further reading
Please let us know if you enjoyed this blog post. Share it with others to spread the knowledge! If you believe any images in this post infringe your copyright, please contact us promptly so we can remove them.