Anthropic has released the Claude Security plugin for Claude Code in beta. The plugin runs a multi-agent vulnerability scan of a repository from inside an existing Claude Code session, then turns the findings you select into patch files that you review and apply yourself. Anthropic emphasized the tool’s versatility upon announcement, highlighting its capability to either run a comprehensive scan across the full codebase or inspect changes from the terminal right before a commit.
What plugin adds
The plugin adds a single command, /claude-security, which opens a menu of three jobs, per the official documentation:
- Scan codebase — the whole repository or a scoped subset of it
- Scan changes — a branch’s diff, a pull request’s diff, or a single commit
- Suggest patches — turn a report’s findings into .patch files
Installation is two commands from the official Anthropic marketplace:
/plugin install claude-security@claude-plugins-official
/reload-pluginsIf the marketplace is not found, run /plugin marketplace add anthropics/claude-plugins-official first. The plugin source is public in the claude-plugins-official repository, currently at version 0.10.0.
How the scan pipeline is structured
The scan is implemented as a dynamic workflow — a JavaScript orchestration script that fans work out across subagents. The script declares six phases:
- Inventory: partition the repository into components. Every top-level directory must be either scanned or explicitly skipped with a reason.
- Threat model: one modeler per component, producing entry points, sinks, trust boundaries, and files a researcher must read in full.
- Research: one researcher per component × category cell.
- Sweep: gap-fill over what the matrix did not cover.
- Panel: three-lens adversarial verification, one voter per lens.
- Adversarial: max effort only: re-panel marginal keeps, then red-team every survivor.
Research runs against four fixed categories: injection-and-input, auth-and-access, memory-and-unsafe, and crypto-and-secrets. The memory-and-unsafe lens is dropped for components written entirely in memory-safe languages, so a pure Python or TypeScript component gets three lenses instead of four.
The operational scale of a run is dictated by four distinct effort tiers: low, medium, high, and max. Depending on the selected tier, specific thresholds are enforced: the maximum number of components is capped at 12 for low and medium tiers, expanding to 24 for high and max tiers; matrix cells are assigned 1 researcher, which increases to 2 at the high and max levels; and the number of gap-fill sweeps scales from 0 at low, to 1 at medium, up to 2 for high and max. When dealing with a limited scope or a small diff, the process condenses into a single-researcher configuration instead of deploying the entire matrix. This ensures the evaluation remains strictly proportionate to the target while maintaining the identical verification standard.
The system employs model-tiered agents: the orchestrator runs on Opus, while the repository cartographer and read-only code explorer run on Sonnet. Furthermore, the session model is inherited by researchers and verifiers, and scan agents are restricted exclusively to read-only tools.
How a finding earns its place in the report
This is the part worth understanding closely. A candidate finding does not go into the report because a researcher found it. It goes in only after surviving a panel.
Each candidate is handed to three independent verifiers, one per lens: REACHABILITY, IMPACT, and DEFENSES. Each returns a structured verdict of TRUE_POSITIVE or FALSE_POSITIVE with one or two lines naming the decisive file:line. The keep quorum is 2 of 3. If fewer than three voters return, the candidate is not keepable at all.
The panel result also caps the finding’s stated confidence. A unanimous 3/3 panel allows a confidence ceiling of high; a 2/3 quorum caps it at medium. A finding cannot claim more confidence than its verification earned.
Critically, the tally is computed in Python by the report renderer, not asserted by the model that produced the findings. The revision stamp’s verification.status is set to verified only when the vote record proves the panel ran for every finding in the report; otherwise it is unverified with a stated reason. That makes the report’s own account of its rigor something you can check rather than something you take on trust.
What a scan writes to disk
Every scan writes a timestamped CLAUDE-SECURITY-<timestamp>/ directory into the repository containing three artifacts:
- CLAUDE-SECURITY-RESULTS.md — the human-readable report. Each finding carries an ID such as F1, plus severity (HIGH/MEDIUM/LOW), confidence, CWE ID, the exact sink line, impact, exploit scenario, preconditions, and a recommendation.
- CLAUDE-SECURITY-RESULTS.jsonl — the same findings, one JSON object per line.
- CLAUDE-SECURITY-REVISION-<commit>.json — the revision stamp: which commit was scanned, at what effort, the severity counts, and how thoroughly the run was verified. The filename carries -dirty when uncommitted changes were part of the scanned tree.
That directory is the only change a scan makes to your checkout, and it ships with its own .gitignore so a stray git add cannot sweep a report into a commit. Deleting that one .gitignore lets you commit the report for an audit trail.
Patches, and the three claims each one must earn
The fix job develops each patch in a scratch clone of the repository, so your working tree and index are never touched. An agent independent of the one that wrote the patch then reviews the staged diff and runs the project’s own test suite against the change.
A patch file is written only if the verifier can state all three of these with confidence: the change addresses that one finding, it introduces no new vulnerability, and behavior is otherwise unchanged — where a change to which inputs the code accepts counts as a behavior change. Any change that weakens security while claiming to fix it, such as a loosened auth check or a disabled test, is an automatic reject. When the verifier cannot vouch for all three, you get a short note explaining why instead of a patch.
Patches land in the report’s patches/ folder as F<n>.patch. Nothing is applied automatically:
git apply CLAUDE-SECURITY-<timestamp>/patches/F1.patchThe patch note explicitly indicates if no repository test covers the modified code, clarifying that the verification relies on code review rather than test execution. Anthropic suggests that each patch should be applied using an individual pull request.
Requirements, cost, and the trust model
The plugin requires a paid plan with Claude Code v2.1.154 or later, with dynamic workflows enabled in /config. It also needs Python 3.9.6 or later on your PATH as python3 (using only the standard library) and Git for change scans and patching. Linux, macOS, and Windows are supported, and scans count against your plan’s token limits.
Running in your session under your permissions, the scan adds no isolation of its own, meaning committed .claude/ settings, hooks, and CLAUDE.md still apply. While it treats repository content as data rather than instructions, this is not a defense against hostile repositories; use sandbox-runtime to sandbox unfamiliar codebases.
Additionally, scans are nondeterministic and do not replace traditional static analysis, dependency scanning, or code reviews.
Where it sits in the stack
| Stage | Tool | What it covers |
|---|---|---|
| In session | Security guidance plugin | Common vulnerabilities in code Claude writes, fixed in the same session |
| On demand, single pass | /security-review | One-time security pass on the current branch |
| On demand, deep scan | Claude Security plugin | Multi-agent scan of a repository or diff, independently reviewed findings and patches |
| On pull request | Code Review (Team, Enterprise) | Multi-agent correctness and security review with full codebase context |
| Managed | Claude Security (Enterprise) | Hosted scanning that monitors connected repositories |
| In CI | Your existing SAST and dependency scanners | Language-specific rules, supply-chain checks, policy enforcement |
Key Takeaways
- The Claude Security plugin runs a six-phase multi-agent scan locally in a Claude Code session, installed with /plugin install claude-security@claude-plugins-official.
- Findings reach the report only after a 3-voter adversarial panel (REACHABILITY, IMPACT, DEFENSES) clears a 2-of-3 quorum; a non-unanimous panel caps stated confidence at medium.
- The verification tally is computed in code by the report renderer, not asserted by the model, and stamped into a per-commit revision file.
- Patches are built in a scratch clone, independently verified against three claims, and never applied automatically.
- The scan adds no isolation of its own — sandbox the session before scanning code you do not control.
Sources: Claude Security plugin documentation, Claude Security product page, Plugin source, claude-plugins-official, @claudeai announcement and Claude Security public beta blog