Anthropic has introduced the Claude Security plugin for Claude Code in beta. Claude Code is Anthropic's terminal-based agentic coding assistant, and the plugin extends it into security analysis territory traditionally occupied by dedicated static application security testing (SAST) tools. The plugin executes a multi-agent vulnerability scan of a repository directly within an existing Claude Code session and converts selected findings into patch files that the user reviews and applies manually. Anthropic highlighted the tool's flexibility at launch, noting that it can perform either a comprehensive scan across an entire codebase or inspect changes from the terminal immediately before a commit.

What the Plugin Adds

The plugin introduces a single command, /claude-security, which presents a menu of three jobs, according to the official documentation:

• Scan codebase — the entire repository or a scoped subset of it
• Scan changes — a branch's diff, a pull request's diff, or an individual commit
• Suggest patches — convert a report's findings into .patch files

Installation requires two commands from the official Anthropic marketplace. If the marketplace is not found, run /plugin marketplace add anthropics/claude-plugins-official first. The plugin source is publicly available 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 distributes work across subagents. The script defines six phases:

1. Inventory: partition the repository into components. Every top-level directory must be either scanned or explicitly skipped with a reason.
2. Threat model: one modeler per component, producing entry points, sinks, trust boundaries, and files a researcher must read in full.
3. Research: one researcher per component × category cell.
4. Sweep: gap-fill over areas the matrix did not cover.
5. Panel: three-lens adversarial verification, one voter per lens.
6. Adversarial (max effort only): re-panel marginal keeps, then red-team every survivor.

Research operates against four fixed categories: injection-and-input, auth-and-access, memory-and-unsafe, and crypto-and-secrets. The memory-and-unsafe lens is omitted for components written entirely in memory-safe languages, meaning a pure Python or TypeScript component receives three lenses instead of four.

The operational scale of a run is governed 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 at lower tiers, increasing 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 rather than deploying the full matrix. This ensures the evaluation remains strictly proportionate to the target while maintaining the same 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. 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

False positives have long been a persistent challenge in automated vulnerability detection, often forcing security teams to triage noisy reports. The plugin's architecture addresses this by requiring that a candidate finding does not enter the report merely because a researcher identified it. It is included only after surviving a panel.

Each candidate is evaluated by 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 cannot be kept at all.

The panel result also caps the finding's stated confidence. A unanimous 3/3 panel permits 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 marked unverified with a stated reason. This makes the report's own account of its rigor something that can be checked rather than taken on trust.

What a Scan Writes to Disk

Every scan creates a timestamped CLAUDE-SECURITY-<timestamp>/ directory inside 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. The use of CWE (Common Weakness Enumeration) identifiers aligns findings with the widely adopted MITRE classification standard, making results interoperable with existing vulnerability tracking and remediation workflows.
• CLAUDE-SECURITY-RESULTS.jsonl — the same findings, one JSON object per line.
• CLAUDE-SECURITY-REVISION-.json — the revision stamp: which commit was scanned, at what effort, the severity counts, and how thoroughly the run was verified. The filename includes -dirty when uncommitted changes were part of the scanned tree.

That directory is the only change a scan makes to the checkout, and it ships with its own .gitignore so a stray git add cannot sweep a report into a commit. Removing that .gitignore enables committing 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, ensuring the 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 confidently assert all three of the following: the change addresses that specific 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 modification that weakens security while claiming to fix it, such as a loosened authentication check or a disabled test, is automatically rejected. When the verifier cannot vouch for all three criteria, a short note explaining why is provided instead of a patch.

Patches are placed in the report's patches/ folder as F<n>.patch. Nothing is applied automatically. The 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 recommends applying each patch 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 requires Python 3.9.6 or later on the system 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 the plan's token limits.

Running in the user's session under their 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; Anthropic advises using sandbox-runtime to sandbox unfamiliar codebases.

Additionally, scans are nondeterministic and do not replace traditional static analysis, dependency scanning, or code reviews. The plugin enters a landscape that includes established tools such as Semgrep, Snyk, and SonarQube, but differentiates itself through its multi-agent pipeline that performs semantic analysis of code paths rather than relying primarily on pattern-matching rules. As a beta product at version 0.10.0, its scope, accuracy, and feature set may evolve.

Sources: Claude Security plugin documentation, Claude Security product page, Plugin source, claude-plugins-official, @claudeai announcement, and Claude Security public beta blog