Anthropic has released "Claude Security," a beta plugin for its Claude Code developer tool that uses AI to scan code for vulnerabilities. Just type /claude-security in the terminal, and a set of agents inspects your entire repository or a set of changes, then bundles the issues it finds into candidate patch files. It is built to fold security checks into your normal workflow, from a quick look before a commit to a full audit of an entire codebase, without breaking your development flow.
Three jobs you can call from the terminal
Claude Security runs inside a Claude Code session that is already open. Typing /claude-security opens a menu with three jobs.
"Scan codebase" inspects the whole repository, or a scoped subset of it. "Scan changes" reviews only a branch's diff, a pull request's diff, or a single commit. "Suggest patches" turns the issues raised by a scan into .patch files. Because it uses the same Claude inference you already run, there is no need to switch to a separate scanner.
Installation takes two commands from Anthropic's official marketplace:
/plugin install claude-security@claude-plugins-official
/reload-plugins
If the marketplace is not found, run /plugin marketplace add anthropics/claude-plugins-official first. The plugin's source is public in the claude-plugins-official repository, and the version at the time of writing is 0.10.0.
A six-phase, multi-agent inspection
The scan itself is built as a dynamic workflow that spreads work across multiple subagents, in six phases. "Inventory" partitions the repository into components; "Threat model" maps each component's entry points, sinks, and trust boundaries; "Research" investigates each one; "Sweep" fills in what was missed; "Panel" verifies candidates from three angles; and "Adversarial," used only at the highest effort level, re-attacks the survivors.
Research runs across four categories: injection-and-input, auth-and-access, memory-and-unsafe, and crypto-and-secrets. For components written entirely in memory-safe languages such as Python or TypeScript, the memory lens is dropped, leaving three angles.
The scale of a run is adjustable across four tiers: low, medium, high, and max. The cap on components rises from 12 at low and medium to 24 at high and max, and the number of researchers grows from one to two at high and above. For a small diff, the process condenses to a single-researcher setup that stays proportionate to the target. Agents are assigned models by role: Opus orchestrates, while Sonnet handles repository mapping and read-only exploration. Scan agents are restricted to read-only tools.
Findings are verified before they are reported
What stands out about Claude Security is how strict its bar for the report is. A candidate issue does not make it into the report just because it was found. Three independent verifiers weigh in on REACHABILITY, IMPACT, and DEFENSES, each judging whether the issue is real or a false positive and pointing to the decisive line. An issue is kept only when two of the three agree, and if three votes are not returned, it is not kept at all. A unanimous three-vote result is required to raise the confidence ceiling to "high," while a two-to-one result caps it at "medium."
This tally is counted in code by the component that writes the report, not asserted by the model that produced the findings. A run is stamped "verified" only when the vote record confirms that verification ran for every finding; otherwise it is recorded as "unverified" with a reason. That turns the report's own claim of rigor into something you can check rather than take on trust.
Each scan writes three artifacts into a timestamped folder: a human-readable report, a list in JSON with one finding per line, and a revision stamp noting which commit was scanned at what effort level. Each entry in the report carries an identifier, a severity, a confidence level, a CWE number, the exact line of the issue, and an assumed exploit scenario. The folder ships with its own .gitignore so a stray git add cannot sweep the report into a commit.
Patches are only suggestions; a human decides whether to apply them
Fix patches are built in a throwaway clone of the repository, so your working tree and index are never touched. An agent separate from the one that wrote the patch reviews the diff and runs the project's own tests.
A patch is written only when the verifier can state with confidence that it fixes that one issue, introduces no new vulnerability, and leaves all other behavior unchanged. A change to which inputs the code accepts also counts as a behavior change, and any change that weakens security while claiming to fix it, such as loosening an auth check or disabling a test, is rejected automatically. When those conditions cannot be met, you get a short note explaining why instead of a patch. Generated patches are not applied automatically; developers apply them by hand with git apply, and Anthropic recommends taking in each patch through its own pull request.
Requirements and points to watch
Use requires a paid plan and Claude Code v2.1.154 or later, with dynamic workflows enabled in the settings. You also need Python 3.9.6 or later callable as python3, plus Git for change scans and patching. Linux, macOS, and Windows are supported, and scans count against your plan's token limits.
Because the scan runs within your session under your own permissions, it provides no isolation of its own. Committed settings and hooks still apply, so Anthropic advises sandboxing unfamiliar code by other means before scanning it. Results are not identical every time, and the tool is positioned as a complement to, not a replacement for, traditional static analysis, dependency scanning, and human review.
Summary
Claude Security is a vulnerability-scanning plugin that runs a six-phase, multi-agent inspection inside a Claude Code session and reports only the issues that clear a three-angle verification. The tally is computed in code, and whether a run was verified is kept on record. Fixes go only as far as suggested patches, and a human always decides whether to apply them. The ease of folding it into everyday development from the terminal, together with a design that lets you check the report's rigor after the fact, looks set to be what sets it apart from other tools.
