"Claude Code security review" usually means one of three things: running the built-in /security-review command in your terminal, adding Anthropic's security review GitHub Action to your pull requests, or simply asking Claude Code (or another AI coding agent) to audit a piece of code. All three are useful. None of them is a complete security program, and all of them send your code to a model provider.

This guide covers what Anthropic actually offers, what these reviews are good and bad at, what happens to your code, the specific risks of AI-generated code and a practical workflow that combines an AI agent review with a dedicated scanner and tests.

What Anthropic offers for security review

The /security-review command

Claude Code ships a /security-review slash command. You run it from the terminal before committing, and Claude analyzes your pending changes for security issues, explaining each finding with a severity and a suggested fix. According to Anthropic's help center, it looks for problems such as SQL injection, cross-site scripting, authentication and authorization flaws, insecure data handling and dependency vulnerabilities, and it is available to Claude Code users on individual paid plans (Pro or Max) and on pay-as-you-go API Console accounts.

The command is defined as a Markdown prompt. If the defaults do not fit your stack, you can copy security-review.md from Anthropic's repository into your project's .claude/commands/ folder and edit it, for example to tell it about your authorization helpers or to skip categories you already cover elsewhere.

The GitHub Action

Anthropic publishes an open-source action, anthropics/claude-code-security-review, that runs the same kind of analysis on pull requests. It triggers on pull_request events, reviews the diff, and posts findings as review comments on the affected lines. The main inputs are a required claude-api-key, the model to use, exclude-directories, a timeout and a path to custom-security-scan-instructions. It also applies a false positive filter that by default drops categories such as denial of service, rate limiting, resource exhaustion, generic input validation without proven impact and open redirects.

One warning in the README deserves attention: the action "is not hardened against prompt injection attacks and should only be used to review trusted PRs". Anthropic recommends enabling "Require approval for all external contributors" so the workflow only runs after a maintainer has looked at the PR. On a public repository, that setting is not optional.

Claude Code Security

In February 2026 Anthropic announced Claude Code Security, a separate capability that scans whole codebases and suggests patches for human review. It launched as a limited research preview for Enterprise and Team customers. Anthropic describes a multi-stage process in which Claude re-examines its own results to filter false positives and attaches severity and confidence ratings, and it is explicit that nothing is applied without human approval. Anthropic also reported finding over 500 vulnerabilities in production open-source codebases with Claude Opus 4.6 during its research.

What AI security review does well

  • It reads intent, not only syntax. A model can notice that one controller scopes queries by the current user and its sibling does not, which is how IDOR vulnerabilities usually look. Rule engines struggle with that.
  • It explains. Findings come with a narrative of how the bug is exploited and a proposed fix, which helps developers who are not security specialists.
  • It is cheap to run early. A command before commit catches problems when the author still has full context.
  • It is flexible. You can point it at framework conventions, internal libraries or a threat model through custom instructions.

Limits you should plan around

  • Scope and context. The command and the action focus on the changes under review. A diff can look safe while the real problem sits in a middleware, a policy or a helper that is not in the diff. Context windows are large, but a model still reasons over what it is given.
  • Non-determinism. Two runs on the same code can produce different findings. That is fine for a reviewer, awkward for a compliance gate that must be repeatable.
  • False positives and false negatives. Filtering reduces noise, and excluded categories (such as DoS or open redirects) will not be reported even when they matter to you. A clean review is not proof that the code is safe.
  • Prompt injection. Code, comments, docs and issue text are all input to the model. A malicious PR can try to talk the reviewer out of reporting something, which is exactly why Anthropic limits the action to trusted PRs.
  • Coverage outside your code. Dependency CVEs, secrets buried in git history and cloud misconfiguration need data and tooling that a diff review does not replace.

Anthropic's own guidance matches this: automated security reviews "should complement, not replace" existing security practices and manual code reviews.

What happens to your code

Claude Code runs on your machine, but to talk to the model it sends prompts, code context and outputs over the network (TLS 1.2 or higher). What happens next depends on the account, according to Anthropic's data usage documentation:

  • Commercial accounts (Team, Enterprise, API): standard 30-day retention, and Anthropic does not train models on code or prompts sent under commercial terms unless the customer opts in.
  • Consumer accounts (Free, Pro, Max): 30-day retention if you do not allow training; 5 years if you allow your data to be used to improve models.
  • Zero data retention is available to qualified Claude for Enterprise accounts, enabled per organization.
  • Cloud providers: Claude Code can also run against Amazon Bedrock, Google Cloud and Microsoft Foundry, where the provider's controls apply.

For many teams this is perfectly acceptable. It becomes a problem when:

  • client contracts or NDAs restrict which subprocessors may see source code;
  • the repository is your core intellectual property (a trading engine, a proprietary model, a detection rule set);
  • regulation or an audit requires you to prove where code was processed and for how long;
  • the repository contains secrets or regulated data in fixtures, which then travel with the context.

The alternative is a model you host yourself, so the code never leaves infrastructure you control. We cover the trade-offs in self-hosted AI for code security.

Security risks of AI-generated code

AI coding agents write a lot of code quickly, and the bugs they introduce are not exotic. They are the classics, produced at a higher rate and reviewed less carefully:

  • Missing authorization. The endpoint works in the demo, so nobody notices that it loads objects by ID without checking the owner. Broken access control tops the OWASP Top 10 2025.
  • Injection. String-built SQL, shell commands and templates still appear, especially in "quick" admin scripts. See SQL injection.
  • Secrets in code. Keys pasted into config files to make something run, then committed.
  • Dependencies. Outdated versions from the model's training data, or package names that do not exist and that an attacker can register (sometimes called slopsquatting).
  • Permissive defaults. Wildcard CORS, debug mode on, broad CI tokens, containers running as root.
  • Agent permissions. An agent that can run shell commands, read the web and push code is itself an attack surface if it reads untrusted content.

A practical workflow: AI review plus scanner plus tests

  1. Before commit: run /security-review (or your agent's equivalent) on the change. Fix what is real, note what you disagree with.
  2. On every pull request: run the AI review action on trusted PRs, plus deterministic checks for dependencies and secrets. A dedicated AI code review or scanner that looks at the whole repository catches what a diff review cannot see.
  3. Authorization tests: for every endpoint that takes an ID, add a test where a second account tries to read and modify the first account's data. Tests are deterministic; they are what keeps a fixed bug fixed.
  4. Periodic full-repository scans to find vulnerabilities in code that accumulated across many small changes, and an API security scanner for your endpoints.
  5. Human review for high-risk areas: auth, payments, multi-tenancy, crypto. A structured secure code review still beats any tool on business logic.
  6. External testing when the stakes justify it: a penetration test or AI-assisted pentesting against a running environment.

Where Nurbak fits

Nurbak is built for the step that diff reviews do not cover: you connect GitHub and scan a whole repository. The analysis runs on Nurbak's own self-hosted AI model, so it does not send your code to OpenAI or Anthropic. It reports exploitable vulnerabilities, including IDOR/BOLA and missing authorization, with file and line, plus dependency CVEs and secrets in git history, with a 0 to 100 score and plain-language explanations.

To be precise about Claude: the optional auto-fix is different. If you ask Nurbak to open a Pull Request with the fix and a security regression test, that fix is generated with Claude, only with your explicit consent, and the consent is recorded in an audit trail. The free scan shows the 3 most important findings in full, and plans start at USD 79/month. Details on the AI code review page.

Bottom line

Claude Code's security review tools are a good first line: fast, explanatory and easy to adopt, especially /security-review before commit and the GitHub Action on trusted pull requests. Treat them as a reviewer, not as a gate. Pair them with full-repository scanning, dependency and secret checks, authorization tests and periodic human or pentest review, and decide deliberately which code may leave your infrastructure.

Related reading