Claude Code Security Review for Production Teams

The Verdict: Use It As Early Security Signal, Not A Gate

Claude Code security review is useful when it finds issues early, noisy when it becomes another unowned comment stream, and dangerous if a team treats it as a merge authority. The official support guidance is blunt: automated security reviews should complement, not replace, existing security practices and manual code reviews.

That means the production decision is not "turn it on everywhere." The decision is where its findings enter the engineering system.

For most teams, the right place is before the final merge path:

• A developer runs /security-review locally before committing a significant auth, payment, data, or API change.
• A draft PR receives AI security comments while the author is still shaping the change.
• CI still runs static application security testing (SAST), dependency scanning, secret scanning, unit tests, integration tests, and policy checks.
• A human reviewer still owns the approval, especially for auth, access control, data exposure, and business-logic risk.

The value is semantic review. Claude can reason about how a change behaves in context, not only whether a static pattern matched. That is helpful for security issues like broken authorization checks, risky data flow, or an injection path hidden behind application logic. It is not a replacement for deterministic controls. A deterministic scanner should still catch known dependency CVEs. A required reviewer should still decide whether a privilege boundary is acceptable. CI should still fail the build when policy is violated.

Use it like an experienced reviewer who can leave useful comments, not like a release gate.

What Claude Code Security Review Actually Does

Claude Code now has two practical security-review surfaces: the local /security-review command and the public GitHub Action. The local command is for on-demand terminal review before committing code. The GitHub Action is for automatic pull request comments after a PR opens.

The support page describes the same core vulnerability categories for both: SQL injection risks, cross-site scripting vulnerabilities, authentication and authorization flaws, insecure data handling, and dependency vulnerabilities. The GitHub repository adds the implementation shape: diff-aware scanning for PRs, PR comments, contextual understanding, language agnostic review, and false positive filtering.

That scope is strong enough to add signal to a team workflow, but narrow enough that expectations matter. Security review is not a universal audit. It does not prove the system is safe. It does not replace threat modeling. It does not validate that your production permissions, secrets, network paths, or approval queues are correctly configured. It can spot a risky change, explain why it matters, and suggest a fix path while the code is still cheap to change.

The availability line also matters for rollout planning. The support page says automated security reviews are available for Claude Code users on Pro or Max and for individual users or enterprises with pay-as-you-go API Console accounts. Anthropic also announced Claude Code Security on February 20, 2026 as a limited research preview for Enterprise and Team customers, with expedited access for open-source maintainers. Do not conflate those. The local slash command and GitHub Action are the everyday workflow surfaces; the web security product is a separate preview with its own access path.

The Production Rollout Pattern

The production pattern is a staged review system: local review for author feedback, PR review for team visibility, CI for deterministic gates, and human approval for merge authority. Each stage has a different owner and a different failure mode.

The merge rule should be simple: Claude Code can comment, suggest, and patch when a developer asks it to. It cannot approve its own security finding. It cannot bypass branch protection. It cannot turn a failed scanner into a pass. It cannot merge code that no human owned.

That line matters because security review often fails socially before it fails technically. A team turns on a new reviewer, gets a pile of comments, and quietly trains itself to skim them. The better rollout is narrower: start with the repositories where a false negative is expensive, define which classes of findings require response, and route the comments into the same PR review habit engineers already use.

For Claude Code team rollout mechanics beyond security review, the same control logic applies to hooks and repo policy. The companion piece on Claude Code hooks for production teams is the right place to design those guardrails.

Wire The PR Workflow Like A Reviewer, Not An Approver

The GitHub Action should be configured like a reviewer that leaves findings, not like automation with release authority. The public repository quick start sets pull-requests: write, contents: read, triggers on pull_request, checks out the pull request head with fetch-depth: 2, and calls anthropics/claude-code-security-review@main with comment-pr: true and a Claude API key from secrets.

A production skeleton looks like this:

name: Claude Security Review

permissions:
  pull-requests: write
  contents: read

on:
  pull_request:

jobs:
  security-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha || github.sha }}
          fetch-depth: 2

      - uses: anthropics/claude-code-security-review@main
        with:
          comment-pr: true
          claude-api-key: ${{ secrets.CLAUDE_API_KEY }}
          claudecode-timeout: 20
          run-every-commit: false

The defaults are a useful signal for how Anthropic expects the action to be used. The action requires claude-api-key. comment-pr defaults to true, upload-results defaults to true, claudecode-timeout defaults to 20 minutes, and run-every-commit defaults to false. It also returns findings-count and results-file, which you can archive or export into your review telemetry.

Do not skip the repository warning. The public action says it is not hardened against prompt injection attacks and recommends reviewing only trusted PRs, with approval required for all external contributors. That should change how public repositories wire it:

• For public forks, require maintainer approval before running workflows that expose secrets.
• Do not pass production secrets into review jobs.
• Keep the action in comment mode.
• Treat findings from untrusted code as untrusted input until a maintainer reviews the PR.
• Store outputs for audit, but do not use the output file as a merge pass unless a human policy owner signs off.

If your team already uses Claude Code GitHub Actions, keep the distinction clean. anthropics/claude-code-action@v1 can run custom prompts and skills, and its v1 configuration uses prompt and claude_args. That is useful for broader workflow automation. The security-review action is purpose-built for security findings. Do not replace a specialized security review with a generic "review this PR" prompt unless you have tested it against your own findings set.

Put Claude Code Permissions Around The Review

The security review is only as credible as the permissions around it. Claude Code is read-only by default and asks for explicit permission before editing files, running tests, or executing commands. That baseline should stay visible during rollout: reviewers need to know whether Claude only inspected code, proposed a patch, or actually changed files after a developer approved the action.

Claude Code also has a write boundary: it can only write to the folder where it was started and its subfolders unless explicit permission is granted for parent directories. That matters for monorepos and generated-code directories. Start Claude Code from the repository root when you want the whole project in scope. Start it from a narrower package when a team wants a smaller blast radius.

The permission system should be paired with hooks. Hooks are user-defined shell commands, HTTP endpoints, or LLM prompts that fire at lifecycle points in Claude Code. The important events for this rollout are:

The hooks documentation shows the shape directly: a PreToolUse hook can deny a Bash call by returning permissionDecision: "deny" and a reason. For security review, the first production hook set is small:

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "Security review cannot run destructive shell commands"
  }
}

Use hooks to block destructive shell commands, unexpected network fetches, settings changes, and edits outside the intended package. Claude Code already blocks risky commands that fetch arbitrary web content, including curl and wget, by default. Your hooks should encode the repo-specific controls the default cannot know: which migration commands are allowed, which directories are generated, which secrets paths are forbidden, and which files need human review before edits.

The deeper rollout cost is not the action minutes. It is the policy work: repo settings, team defaults, approved commands, training, and audit. That is why Claude Code cost planning belongs with rollout design, not after it. The Claude Code pricing rollout piece covers that planning layer.

What It Catches, What It Misses, And What To Log

Claude Code security review is strongest when the bug depends on code meaning. The listed categories are exactly where semantic review can help: SQL injection risks, XSS, authentication and authorization flaws, insecure data handling, and dependency vulnerabilities. The GitHub repository also lists broader classes such as business logic flaws, race conditions, insecure defaults, permissive CORS, vulnerable dependencies, deserialization risk, and hardcoded secrets.

The miss pattern is just as important. AI review can miss issues because the needed context is outside the diff, the exploit depends on runtime configuration, the workflow includes untrusted PR content, or the finding sounds plausible but is wrong. It can also produce low-value comments that train reviewers to ignore it. The public action tries to reduce that with false positive filtering and custom filtering instructions, but your team still owns the final call.

The practical control is a finding ledger. For every security-review comment that survives initial author triage, capture:

• PR URL and commit SHA.
• Finding category.
• Claude-provided severity if present.
• Human disposition: fixed, accepted risk, false positive, duplicate, escalated.
• Reviewer name or team.
• Linked fix commit or issue.
• Whether CI also caught the issue.

That ledger turns the tool from a comment stream into an engineering signal. If Claude repeatedly finds auth bugs before SAST does, keep it early in the flow. If it mostly duplicates dependency scanner output, narrow its instructions. If one repository gets noisy findings, customize .claude/commands/security-review.md or the action's false positive filtering instructions for that codebase.

Data policy belongs in the rollout too. Anthropic's data usage docs say commercial users on Team and Enterprise plans, API, third-party platforms, and Claude Gov are not used to train generative models with code or prompts sent to Claude Code under commercial terms unless the customer chooses to provide data for model improvement. The telemetry page also says operational telemetry logs latency, reliability, and usage patterns, not code or file paths, and can be disabled with DISABLE_TELEMETRY. If your compliance posture needs stricter controls, document those settings before the workflow becomes normal.

The Decision Rule

Use Claude Code security review when your team needs earlier semantic feedback on production code, especially for auth, data handling, API boundaries, and framework-specific business logic. Keep it out of the final approval path unless the output is mediated by a human reviewer and backed by deterministic CI.

The rule flips against it when the PR is untrusted, the workflow needs secrets to run, the repository cannot tolerate prompt-injection risk, or the team has not defined who owns findings. In those cases, start local only. Let developers run /security-review on their machine, keep CI unchanged, and do not install the PR action until the ownership model is clear.

A good rollout does not ask "can Claude find vulnerabilities?" It asks:

• Which repositories get local review first?
• Which PRs are trusted enough for the GitHub Action?
• Which findings require response before merge?
• Which commands and edits are blocked by hooks?
• Which logs prove a human made the security decision?

That is the difference between useful AI review and another unchecked automation path.