◀︎ // Home
Section 03 // Coding Agents
The Enterprise's Highest-Risk Deployment
Bottom line for leadership:
Coding agents are the highest-risk AI you run. In testing, 36% of successful attacks reached remote code execution on the developer's machine, the same machine that holds your source code and cloud keys.
Do this: sandbox coding agents and disable auto-execution of agent-generated commands before you expand rollout.
Why coding agents are the highest-risk AI deployment
In STAR Labs testing, 36% of successful attacks on coding agents reached remote code execution, the highest rate of any agent type and orders of magnitude above traditional CVE-driven RCE. The exposure is structural: three properties make coding agents uniquely vulnerable.
Direct execution
They run shell commands, modify files, and install packages by design. The "decide, then execute" loop is the product. No agent output safely skips the execution step.
Trusted reader
They read every artifact a developer would: READMEs, comments, dependency docs, config files, shell-init scripts, bug reports. Each one is a LAVA delivery channel.
Local privilege
They live on developer workstations with SSH keys, cloud credentials, .env files, and source. A compromise reaches the developer's entire identity.
The three outcomes that define the risk
36%
Remote code execution
Attacker-controlled code runs in the agent's own runtime. The most common way a coding-agent engagement ends, and the reason this tier ranks highest.
Data exfiltration
Source and secrets leak through the agent's own tool calls. To endpoint detection it looks like an authenticated developer using a normal tool.
Sandbox escape
The agent breaks out of its sandbox to the host. Boundaries fall to dotfile poisoning, shell-parser differentials, and validator-chain gaps.
The canonical attack chain
Case study: the fake Claude Code campaign
Coding agents face a second threat beyond poisoned repositories. Attackers impersonate the tool itself to steal the credentials developers use to install and run it.
88
cloned domains
10+
hosting platforms
6
impersonated products
Paid ads
bought to rank above the real tool
Products cloned
Hosted across
In STAR Labs testing, 36% of successful attacks on coding agents reached remote code execution, the highest rate of any agent type and orders of magnitude above traditional CVE-driven RCE. The exposure is structural: three properties make coding agents uniquely vulnerable.
What it steals
First infostealer built to harvest AI coding-assistant credentials: Cline API keys, Continue.dev config, Snowflake SSH tokens, plus browser and crypto-wallet theft.
How it hides · ACRStealer
They read every artifact a developer would: READMEs, comments, dependency docs, config files, shell-init scripts, bug reports. Each one is a LAVA delivery channel.
C2 · unkillable
Command-and-control runs through a Binance Smart Chain smart contract. No domain to seize, no server to shut off.
Other high-severity patterns
Malicious packages
Agents trust the name in the manifest. A typosquat (numpy vs numpyy) lands attacker code in the working directory once the agent reads the install instruction.
Untrusted rules files
.cursorrules and .claude/CLAUDE.md load as system-level instructions. A cloned repo can silently rewrite how the agent behaves, with no warning to the user.
Network-primitive exfiltration
With curl and wget in the tool set, a compromised agent ships .aws/credentials or .ssh/id_rsa out in one command that looks like normal dev activity.
Model-endpoint override
Env vars or config can redirect the agent's LLM calls to an attacker endpoint. Every prompt, snippet, and credential the agent reads then flows to the attacker.
RAG & codebase poisoning
Poisoned commits or comments in an indexed repo persist across users and sessions, steering future agent decisions without anyone noticing the source.
Destructive commands
Full shell and database access means rm -rf or DROP TABLE runs if the agent is persuaded to. PocketOS: a Cursor agent wiped a production database and its backup in under nine seconds. No recovery path through detection.
What defenders need to do
Break Step 1
Data entry
Treat all content the agent reads as untrusted, including internal repos. Sandbox unfamiliar repos on first clone. Block untrusted rules files.
Break Step 2
Model interpretation
Runtime detection of LAVA patterns inside the context window. A second agent watches the first agent's context for injection the model itself cannot catch.
Break Step 3
Tool execution
Allowlist permitted tools. Block network-egress tools by default. Approve risky shell commands. Sign and pin MCP server binaries.
Break Step 4
Persistence or escape
Write-protect shell-init files. Run the agent inside a workspace boundary it cannot extend. Triage sandbox-escape attempts as critical incidents.
Break Step 5
Application outcome
Require human approval for irreversible actions. Monitor egress for exfiltration. Keep off-volume backups so destruction has a recovery path.
The cross-cutting control
Least privilege. An agent granted broader access than the task needs expands the blast radius of every other failure. Minimizing permissions before deployment catches more attacks than detecting them after, and runtime is where most of these controls actually live.
Common Questions
Why are coding agents the highest-risk AI deployment?
In STAR Labs testing, 36% of successful attacks against coding agents reached remote code execution — higher than any other agent type. They execute shell commands directly, read every developer artifact (each a LAVA delivery channel), and run on endpoints holding SSH keys, cloud credentials, and source code.
How does a coding-agent attack actually work?
Most follow a five-step chain: a poisoned README or rules file enters at the data layer, the model reads it as instruction, the tool layer executes shell commands, the payload persists via shell-init files, and the application layer delivers impact — a reverse shell, stolen credentials, or a backdoored pull request.
How do you secure coding agents like Cursor, Claude Code, and Copilot?
Sandbox coding agents, disable auto-execution of agent-generated commands, treat all repo and dependency content as untrusted, block writes to shell-init files, sign and pin MCP binaries, and require human approval for irreversible actions. Runtime monitoring catches the injection the model itself cannot.
Get the Full Report
Read everything here, free. Enter your email and we'll send the full PDF, including the complete defender playbook.






