Claude Code Security Review GitHub Action: A Hardened Setup Guide (2026)

Anthropic's claude-code-security-review is one of the most widely adopted AI code-review tools on GitHub, with more than 6,000 stars since it appeared in August 2025. It does something useful: it reads each pull request's changes the way a security reviewer would, not the way a pattern matcher would, and comments on the lines that matter. Google's threat intelligence team recently argued that pre-release AI code review could eventually slow the growth in vulnerability disclosures. This is one practical way to do it.

It is also an AI agent running in CI with an API key and write access to your pull requests, reading content written by whoever opened the pull request. Anthropic says so plainly in its own documentation. This guide covers how to deploy it so the reviewer does not become the weakest step in the pipeline.

What the action does

1. PR analysis. When a pull request opens, Claude reads the diff to understand what changed. Only changed files are analyzed.
2. Contextual review. It examines the change in the context of the surrounding code and its purpose.
3. Finding generation. Issues are produced with an explanation, a severity rating and remediation guidance.
4. False-positive filtering. A second stage removes low-impact and noise-prone findings.
5. PR comments. Findings are posted as review comments on the specific lines.

The categories it targets are broad: injection of every common kind (SQL, command, LDAP, XPath, NoSQL, XXE), broken authentication and authorization, hardcoded secrets and sensitive data in logs, weak cryptography, race conditions and TOCTOU bugs, insecure configuration, vulnerable or typosquatted dependencies, code execution through deserialization, pickle or eval, and XSS. By default it filters out denial of service, rate limiting, memory or CPU exhaustion, generic input validation without proven impact, and open redirects.

The sentence to read before you deploy it

This action is not hardened against prompt injection attacks and should only be used to review trusted PRs.claude-code-security-review README

That is unusually candid, and it is correct. A pull request is attacker-controlled input: the code, the comments in it, the commit messages and the description. The reviewer reads all of it. Anthropic's mitigation is to turn on the repository setting that requires approval for all external contributors, so the workflow only runs after a maintainer has looked at the change. Do that first. The general mechanics are covered in indirect prompt injection explained.

A hardened workflow

The quick start in the README is a good base. The version below keeps its permissions and trigger, and changes three things: the action is pinned to a commit, the model is set explicitly, and the job has a timeout.

name: Security Review

permissions:
  pull-requests: write  # needed to leave PR comments
  contents: read

on:
  pull_request:          # not pull_request_target

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

      # Pin to a full commit SHA you have reviewed, not @main
      - uses: anthropics/claude-code-security-review@<full-40-char-commit-sha>
        with:
          comment-pr: true
          claude-api-key: ${{ secrets.CLAUDE_API_KEY }}
          claude-model: <current-model-id>
          claudecode-timeout: 20

1. Pin the action to a commit SHA

The README uses @main, and the repository publishes no tagged releases, so there is no version tag to pin to. A branch reference means the code that receives your API key can change without any change on your side. Pin to the full 40-character commit SHA and review the diff when you move it. The broader risk of trusting a reference instead of verifying content is the subject of our Plugin4Shell advisory.

2. Keep the pull_request trigger

On pull_request, workflows triggered from forks do not receive repository secrets, so the action simply cannot run there with your key. The tempting fix is pull_request_target, which runs in the context of the base repository with secrets available. Combined with a checkout of the pull request's head, that hands untrusted code and untrusted text a workflow holding your credentials. Use the approval gate for external contributors instead.

3. Use a dedicated key, and keep permissions minimal

The README notes the key must be enabled for both Claude API and Claude Code usage. Use a key created for this workflow alone, not a developer's personal key, so it can be rotated, monitored and attributed. Keep the job's permissions at pull-requests: write and contents: read. The action needs nothing more.

4. Set the model explicitly

The claude-model input defaults to claude-opus-4-1-20250805, chosen when the action was released. Set it to the model you actually intend to use, and record that choice, so a review result can be tied to the model that produced it.

5. Decide what the findings are allowed to block

The findings-count output makes it easy to fail a check. That is fine as an extra signal. It is not fine as the only security gate, because the plausible prompt-injection outcome is not a crash but a clean report. Keep human review and deterministic scanners on the path to merge.

Configuration reference

The two instruction inputs are where you encode your threat model. If open redirects matter in your login flows, or resource exhaustion matters for a public API, say so here rather than relying on the defaults. The repository also includes an evaluation framework for running the scanner against specific pull requests, which is worth using to calibrate before you trust it on a busy repository.

Why CI-resident agents need this care

At Black Hat USA 2026 on August 5, Novee Security showed that a GitHub issue opened by an account with no repository privileges could reach CI runner secrets in the vendors' own repositories for Claude Code, Gemini CLI and OpenAI Codex. Those were different workflows from this action, but the lessons transfer directly. In the Claude Code case, the final variant, CVE-2026-54316 (fixed in Claude Code 2.1.163), exfiltrated an API key through a pre-approved domain. In the Gemini CLI case, CVE-2026-12537, rated CVSS 10.0, came from automatically trusting repository configuration in headless mode; we covered it as the Gemini CLI CI RCE.

The same class of failure appears in the claude-code-action permission bypass and in Comment and Control, where agent-readable text in issues and comments became credential theft. An AI reviewer in CI is an agent in CI. Configure it like one.

How Anomity fits alongside AI code review

Anomity does not run in your pipeline, and this action does not see your endpoints. They cover different halves of the same problem. The action is scan-time: it judges code before it merges. Anomity is runtime and inventory: it sees which coding agents run on which machines and governs what they do, the distinction we drew in Claude Security and where scan-time vetting ends.

The Endpoint Sensor inventories coding agents, including Claude Code where developers run /security-review, and the MCP servers, plugins, hooks and CLIs attached to them. It finds secrets in those environments using 162 credential patterns, including Anthropic API keys that should have been CI-only, with values redacted on the endpoint. On Claude Code, Anomity decides allow, deny or log at the PreToolUse hook before a tool call runs, and records each decision in a 90-day audit trail. Cloud discovery covers the GitHub OAuth grants that AI applications hold against your repositories.

Use the action. Pin it, gate it, set its model, and do not let it be the only thing standing between a pull request and production. For the Claude Code side of the same workflow, see the Claude Code permissions and hooks hardening guide. To see the coding agents and AI credentials across your developer fleet, book a 30-minute demo.