How to use Claude Security for security review: complete guide from installation, scanning, to patch remediation

Claude Security actually comes in two versions: a plugin version and an Enterprise managed (hosted) version, and their features and thresholds differ greatly. This article organizes the installation steps, scanning workflow, the operating principle of a six-stage multi-agent system, how to read the report and patch files, and the usage limitations listed by the official. (Background: Anthropic opens a beta for the Claude Security plugin, which can use AI agents to scan and generate update files.) (Additional background: Anthropic open-sources an AI security workflow: a seven-stage automated process to find vulnerabilities, verify them, and generate patches.)

Table of contents

Toggle

• What is Claude Security? What’s the difference between the plugin version and the Enterprise managed version?
• What do you need to prepare before using the plugin version? System and version requirements at a glance
• How to install Claude Security? Two commands
• How to scan after installation? Standard six-step workflow
• Only want to scan changed code? How to do change scanning and large repos
• How does scanning work behind the scenes? Breakdown of the six-stage multi-agent pipeline
• How to read the scan report? What’s inside the CLAUDE-SECURITY directory
• How are patch files generated? Full process from discovery to patch
• How to enable and use the Claude Security Enterprise managed version?
• What features and integrations does Claude Security have? What the official says

Recently, if you Google “Claude Security how to use,” there’s a good chance the official documentation contains two names that are almost identical, but the things are completely different: one is installed in your own Claude Code, and the other is something you can only access with an Enterprise plan.

This article answers in order: how the two differ, what you need to prepare, how to install and scan, how to choose if you only want to scan changed code, how it works behind the scenes, how to read reports and patch files, how to enable the Enterprise version, what the official highlights as key features, what limitations it has, and how it should be split up with your existing security tools. After reading, you should be able to run it once at /claude-security right away.

What is Claude Security? What’s the difference between the plugin version and the Enterprise managed version?

Claude Security (Claude code security scanning) is actually two products.

Plugin version: (plugin) install it into Claude Code, run locally in your own session; paid plans are enough to use it, and scanning counts toward your plan usage. Managed version: (managed product) hosted by Anthropic, continuously monitors the GitHub repo you connect; only available for the Claude Enterprise plan, with operations at claude.ai/security.

In short: the plugin version is “you scan it yourself,” and the managed version is “Anthropic monitors it for you.” For example: if the code is on GitLab, Bitbucket, or your company network blocks outbound connections, the plugin version can still reach it because it runs on your machine; the managed version currently only connects to GitHub—what you get in exchange is scheduling and continuous monitoring. Most individual developers will encounter the plugin version first; the barrier is only your paid plan plus two commands.

What do you need to prepare before using the plugin version? System and version requirements at a glance

The official documentation lists several requirements:

• Claude Code version: v2.1.154 or higher, and you need a paid plan. Scanning uses dynamic workflows; for the Pro plan, enable it in the /config menu
• Python: Python 3.9.6 or higher must be on your PATH; the command is python3. You can verify with python3 --version. The plugin uses only the standard library
• Operating system: Linux, macOS, and Windows are all supported
• git: needed for change scanning and patch files; it does not support other version control systems. Full-repo scanning is not restricted

The easiest thing to trip over is the Python version and PATH—more details and troubleshooting in the “Limitations” section below. After confirming, you can move on to installation.

How to install Claude Security? Two commands

Plugin installation is straightforward: in Claude Code, run two commands:

2. /plugin install claude-security@claude-plugins-official
3. If it reports that it cannot find the marketplace, first run /plugin marketplace add anthropics/claude-plugins-official, then try again

After installing, run /reload-plugins for it to take effect in the current session; you don’t need to restart. Removal is also easy: disable/uninstall from the /plugin menu, or run claude plugin uninstall claude-security in the terminal. After it’s installed, the next step is how to actually use it to scan code.

How to scan after installation? Standard six-step workflow

The plugin adds only one command: /claude-security, which brings up three options: scan the entire codebase, scan a set of changes, and generate patch files. The standard flow has six steps:

2. Run /claude-security and choose Scan codebase
3. The plugin first reads the repo, then presents options: scan the whole repo or focus on a specific area. Each option shows the number of files and the relative cost. If you’re unsure, answer “I don’t know” so it picks a default based on the repo size
4. Confirm the execution. The system will prompt that it may take time and use a lot of tokens, and you should keep Claude Code open
5. During scanning, it reports when each stage begins; details are in /workflows
6. Read the report
7. Run /claude-security again and choose Suggest patches

You can also pass parameters like /claude-security scan my branch, or say “scan commit abc1234” in plain language. The official recommendation is to run in auto mode, so the agent doesn’t need permission at every step.

Only want to scan changed code? How to do change scanning and large repos

If there are commits on the branch that don’t exist on the base, the menu will offer an option to scan only that diff. You can also scan a currently open PR, or a single commit. Note that change scanning only looks at already committed content. If you’re editing in progress, commit or stash first, otherwise the scan will read your working directory and effectively do a full repo scan. Change scanning requires a git repo; for directories without version control, you can still run full repo scanning.

The only step that connects to the network is identifying the PR you currently have open. It’s provided only if your session already has GitHub CLI permissions and gh is logged in. For large repos, it’s recommended to scan one chunk at a time and choose a focused scope, such as the API layer or authentication code. The report’s coverage section will state which checks were performed and which weren’t, and you can scan another section anytime.

How does scanning work behind the scenes? Breakdown of the six-stage multi-agent pipeline

The official description says it’s a set of Claude agents that first draw up the architecture, build a threat model, then hunt for vulnerabilities; every finding must be reviewed by an independent verifier agent before it’s included in the report. After Tech media MarkTechPost dissected the plugin configuration, it was restored into a six-stage flow:

• Inventory: break the repo into components
• Threat Model: mark entry points, sinks, and trust boundaries for each component
• Research: assign a researcher agent for each component to run a matrix of four vulnerability categories
• Sweep: cover dead corners not included by the matrix
• Panel: three independent verifiers review from the angles of reachability, impact, and defenses
• Adversarial: run an additional maximum-strength re-test on edge cases

The four vulnerability matrices are injection and input, authentication and access, memory and unsafe operations, and encryption and confidentiality. Memory-safety languages like Python and TypeScript skip the memory-focused dimension. For a finding to make it into the report, it must get 2 out of 3 votes among the three verifiers. All three passing votes are marked high confidence; a maximum of two votes caps it at medium. In effort tiering, low to medium levels have at most 12 components, with 1 researcher per cell; high to highest levels have 24 components, with 2 researchers per cell. Opus serves as overall commander, while Sonnet handles mapping and code mining.

How to read the scan report? What’s inside the CLAUDE-SECURITY directory

Each scan result is written into a timestamped CLAUDE-SECURITY-/ directory inside the repo:

• CLAUDE-SECURITY-RESULTS.md: a human-readable report. Each finding has an ID (e.g., F1), impact, attack scenario, severity, confidence, and suggestions
• CLAUDE-SECURITY-RESULTS.jsonl: the same content in machine-readable form; one JSON per line
• CLAUDE-SECURITY-REVISION-.json: a revision record, tracking which commit was scanned, what effort tier was used, and whether there were uncommitted changes. Scans without version control will be labeled UNVERSIONED

This directory is the only thing modified for your checkout by the scan, and it comes with a .gitignore—accidentally doing git add won’t pull the report into your commit. If you want to keep it as an audit trail, delete that .gitignore and submit as usual.

How are patch files generated? Full process from discovery to patch

From /claude-security, choose Suggest patches, or directly say “fix finding F3”. Patches are built for committed code. The report must still describe the code you currently have. Findings whose related code has changed will be skipped with a note; the plugin will recommend re-scanning rather than blindly patching outdated results.

For each patch, the plugin drafts it in a cached copy of the repo; the original files are left completely untouched until you apply changes yourself. Before delivery, another agent reviews it: if there are tests, it runs them, and it also reads the diff to check whether anything new was introduced. Only if the reviewer can guarantee all three—fixing that finding, not introducing new vulnerabilities, and keeping other behaviors unchanged—will a patch be produced. If any guarantee can’t be met, what you get is a short note explaining why no patch is provided. Patches are placed in the patches/ folder: one finding per F.patch. The apply command is git apply CLAUDE-SECURITY-/patches/F1.patch. The official rule is that patches are never auto-applied; it’s recommended to open a PR for a patch. For code without tests, the patch note will explicitly say that “this review did not run tests.”

How to enable and use the Claude Security Enterprise managed version?

The threshold is higher than the plugin version: you need a Claude Enterprise account, enable Claude Code on the Web, enable Extra Usage and set a spending cap, install the Anthropic GitHub App and authorize the target repos; scanners require premium seats (standard seats typically do not include Claude Code on the Web).

Enablement workflow: confirm Extra Usage is on and the spending cap is reasonable; confirm the GitHub App is installed and has repo permissions; confirm members all have premium seats; administrators enable the feature in claude.ai/admin-settings/claude-security; then go to claude.ai/security, select a repo (for large repos, it’s recommended to first limit to a directory or branch); start scanning, then after completion, review findings. Findings will show vulnerability type, severity, file names and line numbers. Clicking “Open a remediation session” opens a focused session for that issue; false positives can be rejected with a reason.

The official recommendation is: create one Project per team, run it on a fixed weekly schedule, choose scan intensity Regular or Extended, export findings as CSV or Markdown, set webhooks and connect them to Slack and Jira, limit monorepos to subdirectories, and use custom admin roles for RBAC.

What features and integrations does Claude Security have? What the official says

On the product page, Anthropic claims “Claude reasons through your code like a skilled security researcher,” arguing it can understand context, track cross-file data flows, and catch complex multi-component vulnerabilities that tools based on rule matching are easier to miss. The official also claims every finding goes through adversarial verification, arguing that real issues will be reported more and false positives will be fewer.

These are all self-claims by the official. Anthropic has not published false positive rates, accuracy rates, or benchmarking numbers to support these claims, so it’s worth paying attention when evaluating whether to adopt. The high-severity types it emphasizes include memory corruption, injection flaws, authentication bypasses, and logic errors that require cross-file context to spot. More specific integrations: webhooks can push findings to Slack and Jira; reports can be exported as CSV or Markdown; scans can be scheduled and scoped by directories; and rejection history continues across runs.