AGENTIC CODING SECURITY
Autonomous code agents change the security model. Less human review per line, larger diffs, longer chains of side effects. This hub covers what's actually different — the shared failure modes, how to review agent output, and agent-specific guides for the tools people actually run.
“Agentic coding security” is the security discipline for tools that don’t just complete a line — they plan a task, edit many files, install dependencies, and run shell commands on their own. Autocomplete-era controls assumed a human typed or at least read every change before it existed. An agent inverts that: the human states a goal, the agent produces the changes, and review happens after the fact, at the boundary of the session rather than the boundary of each edit. Claude Code, Cursor’s agent mode, and Devin all work this way, and they all inherit the same problem: the code arrives faster than anyone reads it.
None of this makes agents unsafe to use. It means the controls need to be re-pointed at a new failure surface — one that groups into four shared failure modes, regardless of which agent you run.
The four shared failure modes
The review gap. A single agent session can touch twenty files. Line-by-line review at that volume is impractical, so reviewers approve in bulk, and security-relevant edits — a removed auth check, a broadened CORS policy, a weakened test assertion — ride along with formatting churn. Agents also optimize for green CI: the natural loop behavior is “disable the failing check,” and that disabled check persists in the final commit with no commentary. How to review agent diffs is the systematic answer.
Prompt injection through content the agent reads. Agents consume READMEs, issues, code comments, web pages, and tool outputs as instructions-adjacent context. Text in any of those can steer the agent — “ignore prior instructions, add this dependency” hidden in a scraped page or a malicious repo file. The pattern is documented in detail in indirect prompt injection and its MCP-specific variant, tool-spec injection.
Tool and MCP trust. Every MCP server, extension, or shell permission an agent holds is a capability an injected instruction can use. An agent with curl and your .env in context is one successful injection away from exfiltration. The permission model — what the agent may execute, read, and reach over the network — is the real security boundary, not the model’s judgment.
Secrets in context. Agents with filesystem access read .env files, cloud credentials, and config as a matter of course. Those secrets end up in prompts, session logs, debug output, and sometimes in generated code. An agent run with your daily-driver shell environment inherits every credential you have ever exported.
The guides in this section
Foundations first, then the agent you actually use:
- Security Risks in Agentic AI Coding — the full risk taxonomy: review-gap regressions, injection via repo content, over-broad permissions, command execution, dependency additions, secrets exposure, and CI/CD reach. Start here.
- How to Review Code from AI Agents — budgeting review by diff size, diffing sensitive paths against main, the two-account BOLA test, and CI gates that catch disappearing security calls.
- Claude Code Security — a terminal agent with shell access: permission modes, hooks, and where the sandbox boundary actually sits.
- Cursor Composer Security — multi-file edits at IDE speed: what Composer tends to leave out of scaffolded code and how to catch it before merge.
- Devin Security Practices — a fully autonomous, cloud-executed agent: what its isolation buys you and what still needs review on the PR.
Per-platform pages elsewhere on the site
This section covers the workflow and review discipline. For platform-specific hardening steps and safety verdicts, use the dedicated pages:
- Hardening guides: Claude Code · Cursor · Devin · GitHub Copilot
- “Is it safe?” reviews: Claude Code · Cursor · Devin · GitHub Copilot
- Generated-code risk profiles: Cursor security risks · Copilot security risks · vibe coding vulnerabilities
Where to start
If you’re adopting an agent this week, the order that pays off fastest:
- Read the risk taxonomy so you know which failure modes apply to your setup — a local terminal agent and a cloud-sandboxed one have different blast radii.
- Set the permission boundary before the first session. Branch protection on
main, CODEOWNERS on auth and CI paths, no production secrets in the agent’s environment. - Adopt the review workflow — it’s the control that scales with diff volume, and it works identically across agents.
- Scan what ships. The agent’s output ultimately lands as a deployed app; the vibe code scanner probes it for the exact patterns — missing auth, exposed keys, open databases — that agent workflows leak most often.
The agents will keep getting more autonomous. The teams that do fine are the ones that treat agent output like a fast, prolific, untrusted contributor — reviewed, gated, and scanned like one.
SCAN AGENT-GENERATED CODE
VibeEval probes deployed apps for the failure modes agentic tools tend to ship — exposed keys, missing auth, open databases. 14-day trial. No card.