Claude Security: Anthropic's New Vulnerability Scanner

What Anthropic Actually Shipped

Anthropic released the Claude Security plugin for Claude Code in public beta on July 22. It is not a new model and it is not a rebrand of an existing feature. It is a plugin that adds one command, `/claude-security`, and behind that one command sits a coordinated team of Claude agents whose only job is to find real vulnerabilities in your code and hand you a patch you can actually apply.

The install is a single line once you are inside a Claude Code session: `/plugin install claude-security@claude-plugins-official`. If the marketplace is not already registered, you add it first with `/plugin marketplace add anthropics/claude-plugins-official`, then run `/reload-plugins` to activate it without restarting the session. That is the whole setup. No separate dashboard, no new account.

The prerequisites matter more than usual here, because this is not a lightweight linter. You need Claude Code v2.1.154 or later, on a paid plan, because the scan runs on dynamic workflows, the same orchestration layer that lets Claude Code coordinate multiple agents on one task. Pro users turn that on from the Dynamic Workflows row in `/config`. You also need Python 3.9.6 or later reachable on your PATH as `python3`, which the plugin checks with a version warning if it can't find one new enough. The Python requirement is lighter than it sounds, the tooling only uses the standard library, so nothing extra gets installed on your machine. Git is required for scanning a diff or turning a finding into a patch, though a full scan of an unversioned directory still works without it.

I read through the documentation the same way I read through anything before I recommend it to anyone: looking for the parts that are easy to gloss over. The part that stood out is that every scan counts against your plan's usage limits, because it is genuinely running a multi-agent job, not a quick static pass. That is a real cost to budget for, not a footnote. It also means this is not something you run on every keystroke. It is something you run before a merge, before a release, or on a schedule you actually keep.

This launch sits alongside the existing security-guidance plugin, which reviews code as Claude writes it inside the same session, and `/security-review`, which runs a single pass on your current branch. Claude Security is the deeper, slower, more deliberate layer on top of both, and it is exactly the kind of plugin worth adding to the list in my roundup of Claude Code skills and plugins.

How the Multi-Agent Scan Actually Works

The mechanism is the part worth understanding before you trust a single finding. A scan is not one model reading your code once and guessing. It runs in phases: a team of agents first maps your architecture, then builds a threat model specific to what that architecture actually does, then hunts for vulnerabilities against that threat model, then independently reviews every candidate finding before anything reaches a report.

That last step is the one I care about most. A finding does not make it into your results just because one agent flagged it. It has to survive a three-voter adversarial panel, judged on reachability, impact, and defenses already in place, and it needs a 2-of-3 quorum to be reported at all. If the panel is not unanimous, the finding still gets reported, but its stated confidence is capped at medium instead of high. That is a meaningfully different design than most static analysis tools, which report every pattern match and leave you to triage the noise. Here the noise reduction is part of the product, not something bolted on after the fact.

Anthropic is upfront that scans are nondeterministic. Run the same scan twice on the same commit and you can get different findings, because the agents are reasoning about the code rather than matching it against a fixed rule set. That is the tradeoff for catching the kind of cross-file, business-logic vulnerability that pattern matching misses entirely, things like an authentication check that is present in one code path and silently absent in another. The documentation is honest about this instead of hiding it, which is the kind of detail that tells you a team actually used their own tool before shipping it.

Every scan writes its results into a timestamped `CLAUDE-SECURITY-/` folder in your repository, with a human-readable report, a machine-readable JSONL version, and a revision stamp tying the findings to the exact commit that was scanned. That folder ships with its own `.gitignore`, so a routine `git add` will not accidentally sweep a security report into your commit history. If you want to keep a report for an audit trail, you delete that one file and commit the directory on purpose.

Scan Codebase, Scan Changes, Suggest Patches

The `/claude-security` menu offers exactly three jobs, and the shape of them tells you how this is meant to fit into a real workflow rather than a one-off audit. The first is scanning the whole codebase, or a focused area of it if the repository is large, with the plugin stating each option's file count and relative cost up front so you are not guessing what you signed up for. The second is scanning only your changes, a branch's diff against its base, an open pull request, or a single commit, which is the version I expect most people will actually reach for day to day. That mode only looks at committed changes, so anything still sitting uncommitted needs a stash or a commit first, or a full scan instead.

The third job is where the plugin earns the "vulnerability scanner" label instead of just "vulnerability reporter." Pick Suggest Patches, choose which findings from the report you want addressed, and each one gets drafted in a scratch copy of your repository so your actual source files are never touched mid-process. Before a patch is handed to you, it goes through review by an agent that did not write it, which runs your existing tests against the change if you have them and reads the diff independently for anything new the fix might introduce. A patch only gets delivered when that reviewer can vouch for three things: it fixes the one finding, it does not introduce a new problem, and it leaves everything else about the code's behavior alone. If it cannot vouch for all three, you get a short explanation instead of a patch, which is a far better failure mode than a confident but wrong fix.

Nothing is ever applied automatically. Patches land as `.patch` files in the report's `patches/` folder, one per finding, and you apply each with `git apply` in its own pull request, reviewed and tested like any other change. That separation, findings you read, patches you choose, changes you apply yourself, is the detail that makes this feel like a tool built by people who have shipped software under real constraints, not a demo built to look impressive once.

Where This Fits Next to Everything Else You Already Run

The most useful part of the documentation, in my opinion, is that Anthropic does not pretend this replaces anything. They lay out a full stack: the security-guidance plugin catches common issues in the same session as Claude writes the code, `/security-review` gives you a single pass on your current branch, Claude Security is the on-demand deep scan across a repository or diff, Code Review adds multi-agent review at pull-request time on Team and Enterprise plans, and a separate managed Claude Security product does hosted scanning of connected repositories on the Enterprise plan. Your existing static analysis and dependency scanners stay in the picture too, doing the deterministic, language-specific checks that a reasoning-based tool is not trying to replace.

That layered framing matches how I already think about review generally, the same instinct I laid out when I wrote about setting up a proper `.claude/` folder for a project: the tooling works best as a stack of specific, honest checks, not one tool pretending to catch everything. No single pass catches everything, and treating one tool as the whole answer is how the gaps get missed. What Claude Security adds is the layer that reasons about your code the way a person with real security experience would, connecting a database call in one file to an unvalidated input three files away in a way that grep never will. Running it alongside the tools you already trust, not instead of them, is the actual pitch here, and it is a more honest pitch than most security tooling launches make.

The plugin also reaches further than the managed product can, since it runs locally inside your own session. That means it works on repositories hosted anywhere, GitLab, Bitbucket, a private server with no inbound network access, anywhere Claude Code itself can run. For a lot of smaller teams and solo developers, that is the difference between a security scanner they can actually use and one that only makes sense once you are big enough to need an enterprise contract.

Bottom Line

Claude Security is a genuinely new layer, not a repackaging of something that already existed. The design choices, the adversarial voting panel before a finding counts, the scratch-copy patch drafting, the refusal to auto-apply anything, all point toward a team that built this against real, messy codebases rather than clean demo repositories. The usage-limit cost and the nondeterminism are real tradeoffs worth knowing before you reach for it on every commit, not reasons to skip it.

I am adding this to my own review stack as the deep-scan pass before a release, sitting next to the reviews I already run rather than replacing any of them. If you already use Claude Code and you have not looked at your dependency tree or your auth code in a while, `/plugin install claude-security@claude-plugins-official` is a low-effort way to find out what you have been missing. Read the report before you trust it, apply patches one at a time, and treat it the way you would treat a very fast, very thorough colleague doing a first pass, not the last word.