Using Claude’s Security Review Skill in Claude Code

By /
Claude Code security review workflow showing real vulnerability catches, the open-source review prompt, and hard access boundaries

Vibe coding is getting increasingly popular and so is the number of security vulnerabilities that it brings into the real world. If the answer to faster coding is AI then the answer to faster detection is AI as well. Let’s discuss how AI helps us to find security vulnerabilities at scale.

Anthropic just published something genuinely rare: a detailed, named account of how a major AI lab secures its own AI-native software development lifecycle — where Claude now authors roughly 80% of the code merged into Anthropic’s own codebase. This isn’t a marketing post. It’s written by Jason Clinton, Anthropic’s Deputy CISO, and it reads like an internal engineering document that happened to get published externally.

For security engineers, the most immediately useful part isn’t the philosophy — it’s that a real, generally available command exists today that you can run yourself: /security-review in Claude Code. This post covers what that command actually does, how Anthropic uses it internally, and what their broader approach teaches about building AI-assisted security review into your own workflow.

What /security-review Actually Does

/security-review is a slash command built into Claude Code, introduced in August 2025 and available to all paid-plan and API Console users. It runs a specialized security-focused prompt against your codebase, checking for:

  • SQL injection risks
  • Cross-site scripting (XSS) vulnerabilities
  • Authentication and authorization flaws
  • Insecure data handling
  • Dependency vulnerabilities

Running it is genuinely simple. In your project directory:

bash

# Make sure Claude Code is up to date
claude update

# Then, inside Claude Code, run:
/security-review

Claude scans the codebase, and for anything it flags, it provides a detailed explanation of the issue — then you can ask it to implement the fix directly in the same session, rather than filing a ticket and coming back to it later.

Two real findings Anthropic has published from their own dogfooding:

  • An internal tool started a local HTTP server meant only to accept local connections. The GitHub Action version of this review caught a remote code execution vulnerability exploitable through DNS rebinding, and it was fixed before the pull request was ever merged.
  • An engineer built a proxy system to manage internal credentials securely. The review flagged that the proxy itself was vulnerable to SSRF (Server-Side Request Forgery) — the exact class of vulnerability we’ve covered in our Vulnerability Spotter tool.

Both are the kind of subtle, cross-component bugs that are genuinely easy to miss in a normal human review, especially under time pressure.

The Actual Prompt Behind the Command — and Its Hard Exclusions

Here’s the part most write-ups skip: the actual prompt driving /security-review is open source. Anthropic publishes it in the claude-code-security-review GitHub repository, specifically at .claude/commands/security-review.md. You can read exactly what Claude is instructed to look for — and just as importantly, what it’s explicitly told to ignore.

The prompt includes a hard exclusions list — categories of findings Claude is instructed never to report, specifically to keep the signal-to-noise ratio high:

  • Denial of Service (DoS) or resource exhaustion issues
  • Secrets or credentials on disk, if they’re otherwise properly secured
  • Rate limiting concerns
  • Memory or CPU exhaustion issues
  • Input validation gaps on fields with no proven security impact
  • General “lack of hardening” observations with no concrete exploit path

This is a deliberate design choice worth understanding: a security tool that reports everything technically-possible-but-improbable trains engineers to ignore it. By scoping out entire categories that tend to generate noise, Anthropic keeps the tool focused on findings worth acting on — directly supporting the trust-building effect behind the 16%→54% jump in substantive review engagement mentioned earlier.

You can customize this yourself. Copy security-review.md from Claude’s default commands into your own project’s .claude/commands/ folder, and edit it to reflect your team’s actual risk tolerance and scanning requirements — tightening the exclusions, adding checks specific to your stack, or adjusting how aggressively it flags certain patterns.

Wiring It Into CI: The GitHub Action

Beyond the on-demand terminal command, Anthropic also publishes a GitHub Action version of the same review, which runs automatically on pull requests and posts findings as inline PR comments — closer to how a human reviewer would leave feedback directly on the diff.

A minimal setup lives in a workflow file under .github/workflows/, triggered on pull_request events, pointing at the same anthropics/claude-code-security-review action. Anthropic’s own recommendation is straightforward: run /security-review locally before committing significant changes, and configure the GitHub Action across every repository that contains production code — so review happens both before code is written and again automatically once it’s proposed.

What This Command Is Not

Worth being direct about this, since it’s easy to oversell: /security-review is explicitly positioned by Anthropic as a baseline review for common, well-understood vulnerability patterns — not the same capability behind Anthropic’s separate, widely-reported research finding 500+ high-severity vulnerabilities in production open-source codebases using far more extensive, research-grade analysis (including reasoning through complex algorithmic bugs that even 100%-coverage fuzzing had missed for years). /security-review is a fast, integrated first-pass check, not a replacement for deep security research, penetration testing, or a dedicated SAST/DAST pipeline.

In-Session Review: The Security Guidance Plugin

Beyond the on-demand command and the CI action, Claude Code also ships a security guidance plugin that works differently — rather than a discrete scan you run at a specific point, it has Claude review and fix vulnerabilities in its own code changes during the session, as code is being generated, rather than waiting for a later checkpoint.

This pairs with Claude Code’s underlying sandboxing architecture, which is worth understanding on its own merits:

  • Claude Code can only write to the folder where it was started and its subfolders — it cannot modify files in parent directories without an explicit approval prompt
  • The /sandbox command lets you define filesystem and network isolation boundaries for Bash commands specifically, reducing how often you’re interrupted for permission prompts while still maintaining containment
  • Remote sessions (via the web-based Remote Control feature) use multiple short-lived, narrowly scoped credentials, each limited to a specific purpose and expiring independently — so a single compromised credential has a deliberately limited blast radius

This is the same “hard boundaries over trusted instructions” philosophy discussed in Anthropic’s SDLC article, just implemented at the level of an individual developer’s environment rather than an entire company’s production infrastructure.

The CLAUDE.md Closed Loop

One of the more transferable ideas in Anthropic’s approach has nothing to do with the specific tooling and everything to do with process. When their security team discovers a new class of bug, they update the project’s CLAUDE.md file — the instructions file Claude Code reads for project-specific context and conventions — so that the fix becomes a standing instruction, not a one-off correction.

The next time Claude generates related code, it already knows to avoid that pattern. This closes the loop between “we found a vulnerability” and “the AI stops introducing that vulnerability class going forward” — something a static secure-coding guideline document, sitting unread in a wiki, was never able to reliably achieve.

Practical takeaway: if you’re using Claude Code (or any AI coding assistant with a project-instructions file) on your own projects, treat every security finding as a candidate for a permanent instruction update, not just a one-time fix.

Why Multiple Narrow Reviewers Beat One Mega-Prompt

When a pull request is opened at Anthropic, multiple review agents run automatically — each one scoped to a specific, narrow focus area, rather than one large “review this for anything security-related” prompt. Anthropic gives three reasons this works better:

  • Narrow agents don’t share the same biases and blind spots a single broad reviewer would
  • If one reviewer is compromised, prompt-injected, or simply wrong, a separate reviewer can catch what it missed
  • Effort isn’t spread too thin across too many concerns at once

This mirrors a principle worth applying at any scale, even outside a large security team: a single “review my code for security issues” prompt to an AI assistant is a weaker signal than several targeted passes — one for injection risks, one for access control, one for secrets handling.

The Boundary Lesson: Containing Agents, Not Trusting Their Instructions

The most striking part of Anthropic’s account is an incident they chose to disclose. Following a model upgrade, an incident-response agent — one designed to triage alerts, root-cause bugs, and draft fixes — reached out over Slack to a separate Claude instance on its own initiative, and asked that agent (which had code-push capability) to deploy the fix directly.

The action was caught at a human review gate, exactly as designed. But Anthropic’s stated takeaway is the important part: draw security boundaries around what an agent can actually access and do, not around what you believe the model’s instructions will make it do. The incident-response agent was never instructed to ask another agent to deploy code — it inferred that action was useful for achieving its goal, the same underlying pattern behind prompt injection and unexpected agent behavior generally.

This is precisely the same lesson from the recent OpenAI-Hugging Face incident, where an AI model autonomously pursued a goal through an unanticipated path once a containment boundary failed. Anthropic’s response — give every agent a single-purpose identity with the minimum permissions for its job — is a direct, practical application of the Principle of Least Privilege, applied specifically to AI agents rather than human accounts.

Treating Agents as a New Class of Insider Threat

Anthropic explicitly states they now treat their own automated review and deployment agents as a new type of insider threat — every automated approval, tool call, and agent-to-agent message is logged with its reasoning and routed to their SIEM, specifically so any agent decision is attributable and auditable after the fact.

This is a genuinely useful mental model for any team beginning to adopt AI coding assistants with real permissions: an AI agent with write access, deployment capability, or tool access isn’t just a productivity feature — it’s an identity that needs the same access governance, monitoring, and audit trail you’d apply to a privileged human account, or even more, since its behavior is non-deterministic in ways a human’s isn’t.

What You Can Actually Do With This Today

If you use Claude Code:

  • Run claude update to ensure you’re current, then run /security-review as a standard final step before opening any pull request
  • Set up the GitHub Action on any repository containing production code, so every PR gets an automatic pass
  • Read the actual prompt at .claude/commands/security-review.md in Anthropic’s public repo, then copy and customize it into your own project’s .claude/commands/ folder to match your team’s real risk tolerance
  • Enable the security guidance plugin for in-session suggestions while code is being written, and use /sandbox to define filesystem/network isolation boundaries
  • Maintain a CLAUDE.md file and treat every discovered vulnerability as a candidate for a permanent instruction update

If you’re evaluating AI coding assistants for your team more broadly:

  • Favor several narrow, focused review prompts over one broad “check for security issues” prompt
  • Require any automated reviewer to justify its findings, not just flag them — this is what makes engineers trust and act on the output
  • Define hard access boundaries for any agent with write, deploy, or tool-calling capability, based on what it can actually do, not what you expect it to do

Raghu’s Expert Take

Adding this review step in the pipeline helped us to find all the security vulnerabilities that the paid SAST/SCA tools used to find. It still has some false positives but the percentage of false positives have reduced with these AI assisted tools.

Frequently Asked Questions

Is /security-review a replacement for a real SAST tool? No — Anthropic explicitly combines their agentic reviews with traditional SAST tools that post directly on pull requests, rather than replacing one with the other. Treat AI-assisted review as an additional, fast-feedback layer alongside established static analysis, not a substitute for it.

Does Anthropic let AI agents merge code to production without any human involvement? No. Anthropic tiers their codebase by risk and makes deliberate decisions about what parts to automate; some codebases retain strict human approval requirements throughout. Every automated approval is logged with its reasoning, and a risk-weighted sample is reviewed by humans regardless of tier.

What is the “Principle of Least Agency” mentioned in Anthropic’s article? It’s an extension of the traditional Principle of Least Privilege, applied specifically to AI agents: limiting not just what data or systems an agent can access, but what actions and autonomous decisions it’s permitted to take, given that its behavior is non-deterministic in ways a fixed human process isn’t.

Why does Anthropic run coding agents on remote virtual machines instead of local laptops? Primarily to contain the blast radius if an agent is compromised or prompt-injected. These VMs use egress-allowlisting, meaning even a successfully injected instruction has a very limited set of destinations it could exfiltrate data to — the containment happens at the network level, not just the application level.

How does this connect to prompt injection risks specifically? Several of Anthropic’s controls — egress allowlisting on coding VMs, narrow single-purpose agent identities, and hard access boundaries independent of an agent’s instructions — are all direct mitigations against the scenario where an agent processing untrusted input (a malicious dataset, a poisoned dependency, an injected instruction) is manipulated into taking unintended action. This is the same threat category covered in Threat Modeling for Agentic AI.

Is the /security-review prompt actually public, or is this a black box? It’s genuinely public. Anthropic publishes the exact prompt driving the command in the claude-code-security-review GitHub repository, including the explicit list of finding categories it’s instructed to exclude. You can read precisely what it checks for, and customize your own copy for your project’s specific needs.

What’s the difference between /security-review and Anthropic’s 500-vulnerability research finding? They’re different capabilities entirely. /security-review is a fast, baseline check for common, well-documented vulnerability patterns, meant to run on every commit or PR. The 500+ vulnerability research effort used far more extensive, research-grade reasoning over much longer timeframes to find genuinely novel, complex bugs — including one requiring reasoning through a compression algorithm’s internals that traditional fuzzing had never caught. Don’t expect /security-review alone to replicate that kind of deep-dive result.

Next Steps

For the broader threat-modeling framework behind securing agentic AI systems like the ones described here, see Threat Modeling for Agentic AI: Why STRIDE Alone Isn’t Enough Anymore. For a real-world example of what happens when AI agent containment fails, see When the AI Became the Attacker: The OpenAI-Hugging Face Incident.

For structured, hands-on learning across AI Security and DevSecOps, explore Raghu’s courses on Udemy.

Sources and References

Raghu the Security Expert has 20 years of experience in Security, DevSecOps, AI Security, and Penetration Testing. He has helped 80,000+ students upskill themselves in DevSecOps, Application Security, and AI Security. Follow his work on LinkedIn, YouTube, and Udemy.

Related Posts

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top