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.
