--- title: "Claude Code Security Review GitHub Action: A Hardened Setup Guide (2026)" description: "Anthropic's AI security review action is useful and, in its own words, not hardened against prompt injection. How to deploy it without adding a hole." url: "https://anomity.ai/blog/claude-code-security-review-github-action-guide/" source: html --- On this page - What the action does - The sentence to read before you deploy it - A hardened workflow - 1. Pin the action to a commit SHA - 2. Keep the pull_request trigger - 3. Use a dedicated key, and keep permissions minimal - 4. Set the model explicitly - 5. Decide what the findings are allowed to block - Configuration reference - Why CI-resident agents need this care - How Anomity fits alongside AI code review - Frequently asked questions [← Back to blog](https://anomity.ai/blog/) - Home - Blog - Claude Code Security Review GitHub Action: A Hardened Setup Guide (2026) ![Anomity robot illustrating Claude Code Security Review GitHub Action: A Hardened Setup Guide (2026)] Guide # Claude Code Security Review GitHub Action: A Hardened Setup Guide (2026) Anomity Research Anomity Research · Oct 2, 2026 · 6 min read Share: Copied TL;DR - claude-code-security-review is Anthropic's open-source GitHub Action (MIT licensed) that has Claude review the diff of each pull request for security issues and comment on the affected lines. The same analysis ships in Claude Code as the /security-review slash command. - It covers injection, authentication and authorization flaws, hardcoded secrets, weak cryptography, deserialization and eval execution, XSS and more, and filters out by default denial of service, rate limiting, resource exhaustion and open redirects. - Anthropic's README is direct: the action is not hardened against prompt injection attacks and should only be used to review trusted PRs . It recommends requiring maintainer approval before workflows run for external contributors. - The quick start references the action as @main , and the repository publishes no tagged releases . Pin to a full commit SHA instead, so a change upstream does not silently change what runs with your API key. - The default model is claude-opus-4-1-20250805 . Set claude-model explicitly rather than inheriting a default chosen in 2025. - Keep it on the pull_request trigger. Moving to pull_request_target to make forks work hands untrusted code a workflow with your secrets, which is the pattern behind Novee's Black Hat 2026 findings against the vendors' own coding-agent workflows. - Treat findings as one input to review, not a merge gate on its own . A reviewer that can be prompt-injected can be told to report nothing. 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](https://anomity.ai/blog/gtig-ai-software-vulnerabilities-agent-frameworks-2026/) 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 - PR analysis. When a pull request opens, Claude reads the diff to understand what changed. Only changed files are analyzed. - Contextual review. It examines the change in the context of the surrounding code and its purpose. - Finding generation. Issues are produced with an explanation, a severity rating and remediation guidance. - False-positive filtering. A second stage removes low-impact and noise-prone findings. - 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](https://anomity.ai/blog/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@ with: comment-pr: true claude-api-key: ${{ secrets.CLAUDE_API_KEY }} claude-model: 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](https://anomity.ai/blog/plugin4shell-coding-agent-plugin-sha-pinning-bypass/). ### 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 Input Default Notes claude-api-key None (required) Must be enabled for Claude API and Claude Code usage comment-pr true Posts findings as PR review comments upload-results true Uploads results as workflow artifacts exclude-directories None Comma-separated; use for vendored or generated code claude-model claude-opus-4-1-20250805 Set explicitly claudecode-timeout 20 Minutes run-every-commit false Skips the cache check; the README warns it may increase false positives false-positive-filtering-instructions None Path to custom filtering instructions custom-security-scan-instructions None Path to instructions appended to the audit prompt 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](https://anomity.ai/blog/gemini-cli-run-gemini-cli-cvss-10-ci-rce-ghsa-wpqr-6v78-jr5g/). The same class of failure appears in [the claude-code-action permission bypass](https://anomity.ai/blog/claude-code-github-action-bot-actor-bypass/) and in [Comment and Control](https://anomity.ai/blog/comment-and-control-multi-agent-prompt-injection-credential-theft/), 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](https://anomity.ai/blog/claude-security-scan-time-vs-runtime-governance/). 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](https://anomity.ai/blog/claude-code-permissions-hooks-hardening-guide/). To see the coding agents and AI credentials across your developer fleet, [book a 30-minute demo](https://anomity.ai/#early-access). Share: Copied ## Frequently asked questions What is claude-code-security-review? It is a GitHub Action published by Anthropic that runs Claude Code against the changes in a pull request to look for security vulnerabilities. It is diff-aware, so on a pull request it analyzes only the changed files, and it posts findings as review comments on the specific lines involved, with an explanation, a severity and remediation guidance. A false-positive filtering stage removes low-impact findings before they are posted. It is MIT licensed and language agnostic. How is it different from the /security-review command in Claude Code? They share the same analysis. The GitHub Action runs it automatically on pull requests in CI. The /security-review slash command, which ships with Claude Code by default, runs it on demand against a developer's pending changes on their own machine. You can customize the command by copying the security-review.md file from the repository into your project's .claude/commands/ folder and editing it, for example to add organization-specific false-positive guidance. Is it safe to run on pull requests from forks? Not without a gate. Anthropic's own README states that the action is not hardened against prompt injection and should only review trusted pull requests. A pull request is attacker-controlled text and code, and the model reads both. Anthropic recommends enabling the repository setting that requires approval for all external contributors, so the workflow runs only after a maintainer has looked at the change. Do not switch the trigger to pull_request_target to make fork pull requests work, because that runs the workflow with your repository's secrets in reach of untrusted content. Why pin the action to a commit SHA? Because the action runs with your Anthropic API key and with write access to pull-request comments. The quick start references @main, which means the code that runs can change whenever the branch does, and the repository publishes no tagged releases to pin to instead. A full 40-character commit SHA fixes the code to a version you have looked at. Review the diff when you move the pin forward, the same way you would for any dependency that handles a secret. What does the default false-positive filtering exclude? Per the README, it excludes denial-of-service issues, rate-limiting concerns, memory and CPU exhaustion, generic input validation without proven impact, and open redirects. That is a reasonable default for reducing noise. It is also a policy decision: if open redirects matter in your authentication flows, or resource exhaustion matters for a public API, adjust the filtering instructions rather than assuming the tool has you covered. Can we use the findings count as a required check? You can, as long as it is not the only security control on the path to merge. The action exposes a findings-count output, so failing a check when it is above zero is easy. The risk runs the other way: because the reviewer is not hardened against prompt injection, a pull request can contain text aimed at the model, and the plausible failure is a clean report on a change that is not clean. Keep human review and deterministic scanners in place, and treat the AI review as an additional reader, not a replacement for one. How does Anomity fit alongside this action? Anomity does not run in your CI pipeline, and this action does not see your endpoints, so they cover different halves. The action reviews code before it merges. Anomity's Endpoint Sensor inventories the coding agents running on developer machines, including Claude Code where /security-review runs, along with their MCP servers, plugins, hooks and the secrets in their environments, including stray Anthropic API keys. On Claude Code, Anomity decides allow, deny or log at the PreToolUse hook before a tool call runs. Cloud discovery covers the GitHub OAuth grants held by AI applications. Scan-time review and runtime governance answer different questions, and you need both. ## Related [Guide ### NVIDIA OpenShell: A Security Team's Guide to the Agent Sandbox and Its Defaults (2026) How NVIDIA OpenShell sandboxes AI agents, what its policy engine enforces, and the defaults to change before you rely on it: audit mode, Landlock, logs. Anomity Research · Oct 2, 2026 · 6 min](https://anomity.ai/blog/nvidia-openshell-agent-sandbox-security-guide/) [Guide ### Enterprise-Managed MCP Connectors: What IdP-Governed Authorization Covers, and What It Does Not (2026) Enterprise-managed MCP connectors went GA on 24 August 2026 across ten connectors. What IdP-governed authorization covers, and what it cannot see. Anomity Research · Aug 27, 2026 · 9 min](https://anomity.ai/blog/anthropic-enterprise-managed-mcp-connectors-idp-governance/) [Guide ### How MCP Servers Expose Enterprise Secrets: Five Paths and the CVEs Behind Them MCP servers are where agent credentials actually live. Five exposure paths - plaintext config, sprawl, injection, over-permissioning, and the server supply chain - with the CVEs that prove each one. Anomity Research · Aug 17, 2026 · 9 min](https://anomity.ai/blog/mcp-server-secrets-exposure-enterprise-credentials/) ## Structured data ```json { "@context": "https://schema.org", "@type": "Article", "headline": "Claude Code Security Review GitHub Action: A Hardened Setup Guide (2026)", "description": "Anthropic's AI security review action is useful and, in its own words, not hardened against prompt injection. How to deploy it without adding a hole.", "datePublished": "2026-10-02", "dateModified": "2026-10-02", "author": { "@type": "Organization", "name": "Anomity", "url": "https://anomity.ai/", "sameAs": [ "https://www.linkedin.com/company/anomity", "https://github.com/Anomity-ai", "https://www.wikidata.org/wiki/Q140763940" ] }, "publisher": { "@type": "Organization", "name": "Anomity", "url": "https://anomity.ai/", "sameAs": [ "https://www.linkedin.com/company/anomity", "https://github.com/Anomity-ai", "https://www.wikidata.org/wiki/Q140763940" ], "logo": { "@type": "ImageObject", "url": "https://anomity.ai/icon-512.png" } }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://anomity.ai/blog/claude-code-security-review-github-action-guide/" }, "image": { "@type": "ImageObject", "url": "https://anomity.ai/assets/blog/covers/coding-agents.jpg", "width": 1200, "height": 630 }, "articleSection": "Guide", "url": "https://anomity.ai/blog/claude-code-security-review-github-action-guide/", "keywords": "claude-code-security-review GitHub Action, Claude Code, claude-code-security-review, GitHub Actions, AI Code Review, CI/CD Security, Prompt Injection, AppSec, /security-review" } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "What is claude-code-security-review?", "acceptedAnswer": { "@type": "Answer", "text": "It is a GitHub Action published by Anthropic that runs Claude Code against the changes in a pull request to look for security vulnerabilities. It is diff-aware, so on a pull request it analyzes only the changed files, and it posts findings as review comments on the specific lines involved, with an explanation, a severity and remediation guidance. A false-positive filtering stage removes low-impact findings before they are posted. It is MIT licensed and language agnostic." } }, { "@type": "Question", "name": "How is it different from the /security-review command in Claude Code?", "acceptedAnswer": { "@type": "Answer", "text": "They share the same analysis. The GitHub Action runs it automatically on pull requests in CI. The /security-review slash command, which ships with Claude Code by default, runs it on demand against a developer's pending changes on their own machine. You can customize the command by copying the security-review.md file from the repository into your project's .claude/commands/ folder and editing it, for example to add organization-specific false-positive guidance." } }, { "@type": "Question", "name": "Is it safe to run on pull requests from forks?", "acceptedAnswer": { "@type": "Answer", "text": "Not without a gate. Anthropic's own README states that the action is not hardened against prompt injection and should only review trusted pull requests. A pull request is attacker-controlled text and code, and the model reads both. Anthropic recommends enabling the repository setting that requires approval for all external contributors, so the workflow runs only after a maintainer has looked at the change. Do not switch the trigger to pull_request_target to make fork pull requests work, because that runs the workflow with your repository's secrets in reach of untrusted content." } }, { "@type": "Question", "name": "Why pin the action to a commit SHA?", "acceptedAnswer": { "@type": "Answer", "text": "Because the action runs with your Anthropic API key and with write access to pull-request comments. The quick start references @main, which means the code that runs can change whenever the branch does, and the repository publishes no tagged releases to pin to instead. A full 40-character commit SHA fixes the code to a version you have looked at. Review the diff when you move the pin forward, the same way you would for any dependency that handles a secret." } }, { "@type": "Question", "name": "What does the default false-positive filtering exclude?", "acceptedAnswer": { "@type": "Answer", "text": "Per the README, it excludes denial-of-service issues, rate-limiting concerns, memory and CPU exhaustion, generic input validation without proven impact, and open redirects. That is a reasonable default for reducing noise. It is also a policy decision: if open redirects matter in your authentication flows, or resource exhaustion matters for a public API, adjust the filtering instructions rather than assuming the tool has you covered." } }, { "@type": "Question", "name": "Can we use the findings count as a required check?", "acceptedAnswer": { "@type": "Answer", "text": "You can, as long as it is not the only security control on the path to merge. The action exposes a findings-count output, so failing a check when it is above zero is easy. The risk runs the other way: because the reviewer is not hardened against prompt injection, a pull request can contain text aimed at the model, and the plausible failure is a clean report on a change that is not clean. Keep human review and deterministic scanners in place, and treat the AI review as an additional reader, not a replacement for one." } }, { "@type": "Question", "name": "How does Anomity fit alongside this action?", "acceptedAnswer": { "@type": "Answer", "text": "Anomity does not run in your CI pipeline, and this action does not see your endpoints, so they cover different halves. The action reviews code before it merges. Anomity's Endpoint Sensor inventories the coding agents running on developer machines, including Claude Code where /security-review runs, along with their MCP servers, plugins, hooks and the secrets in their environments, including stray Anthropic API keys. On Claude Code, Anomity decides allow, deny or log at the PreToolUse hook before a tool call runs. Cloud discovery covers the GitHub OAuth grants held by AI applications. Scan-time review and runtime governance answer different questions, and you need both." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://anomity.ai/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://anomity.ai/blog/" }, { "@type": "ListItem", "position": 3, "name": "Claude Code Security Review GitHub Action: A Hardened Setup Guide (2026)", "item": "https://anomity.ai/blog/claude-code-security-review-github-action-guide/" } ] } ```