Securing your coding agent: the five layers, and which tools actually block anything

Your coding agent reads files, runs commands and installs things on your behalf. Most of the popular "AI security" tools for it only give advice. Here is how to stack the ones that actually stop something, and where the advisers fit.

The idea is simple. Anything that runs inside the agent can be argued with, because a prompt injection can talk the model out of it. So decisions that must hold live outside the agent: in the operating system, in a hook, or in CI. Star counts below were checked on GitHub on 24 October 2026, and they say little about which tools enforce anything: Cloudflare's audit skill has more stars than every blocking tool here combined, from 14 commits.

1. Contain: decide what the agent can reach

If everything else fails, a sandbox still decides which files the agent can read or write and which hosts it can connect to.

• Anthropic Sandbox Runtime (4.4) is the engine behind Claude Code's /sandbox. It uses the operating system's own sandbox, needs no container, and is free. It allows writes inside your project on purpose, so it won't stop a hard reset.
• NVIDIA OpenShell (4.1) is heavier: a sandbox per agent, credentials the agent never sees, and policy changes checked before they apply. It suits agents you leave running unattended.

Pick one per workload. Running both on the same agent only gives you two rule sets to debug.

2. Guard: block dangerous actions before they run

• CC Safety Net (4.0) refuses force-pushes, hard resets, rm -rf on dangerous targets and reads of your keys, and can't be fooled by wrapping the command in bash -c. It covers the gap the sandbox leaves open.
• security-guidance (4.2), Anthropic's Claude Code plugin, reviews every edit, turn and commit with a fresh model call. It advises and never blocks, so treat it as an early warning rather than a lock.

3. Review: let the agent hunt for bugs

This is where agents are genuinely good, as long as nothing depends on them catching everything.

• Trail of Bits Skills (4.4) packages a security firm's audit methods; the best skills drive CodeQL and Semgrep rather than trusting the model's judgement.
• Cloudflare Security Audit Skill (3.9) has a second agent try to disprove every finding. Cloudflare says one run finds about half of what repeated runs find, so run it more than once.

4. Vet: check what you install

Every skill, plugin and MCP server is code and instructions your agent will trust. That makes them a supply chain.

• Cisco Skill Scanner (3.7) scans skills before your agent reads them, and publishes its own catch rates, which are modest.
• Snyk Agent Scan (3.8) finds every MCP server and skill already installed on a machine. It sends tool descriptions to Snyk for analysis.
• ToolHive (4.1) runs each MCP server in its own locked-down container, so a bad one can do less.

5. Gate: the check the agent can't touch

AI-written code should face the same merge gate as human code. A model can be talked out of a finding; a failed CI job can't.

• Semgrep (4.3) as a required status check, with its MCP server or Guardian plugin so the agent sees the same rules while it works.
• On Semgrep's free tier, add OSV-Scanner for vulnerable dependencies and Gitleaks for leaked secrets. Both are free and open source.

If you only adopt three

Turn on the built-in sandbox, install the security-guidance plugin, and make Semgrep a required CI check. That is one thing that enforces, one that warns early, and one gate the agent can't skip.

The catch: security tools are tools too. Hooks run with your permissions every time the agent acts, scanners send data to vendors, and installers pull @latest. A malicious "security" hook is more dangerous than a malicious skill, because its job makes people trust it. Pin versions, prefer the vendor's own repository over forks, and try new hooks inside a sandbox first.

What none of them solve

• Prompt injection. Nothing detects it reliably. Containment comes first because the best you can do is limit the damage.
• Leaks to allowed hosts. An allowlist decides where the agent can connect, not what it sends. If GitHub is allowed, a public gist is allowed. Plant a fake key in a throwaway repo and fail CI if it ever shows up in outgoing traffic.
• Authorisation logic. Whether customer A can read customer B's data is a question scanners rarely answer and AI reviewers answer inconsistently. Keep a person on auth code.
• Rubber-stamp approvals. Someone clicking approve on dozens of agent changes a day is not a control. Send only the risky ones to people, and give them time.

Our take: finding problems can live inside the agent. Preventing dangerous actions has to live outside it, and approving code for production belongs outside the coding session altogether. Install the sandbox before the security skill.