Claude Security plugin: vulnerability scanning inside the coding agent, not after the commit

Anthropic released the Claude Security plugin in beta on July 23. It adds AI vulnerability scanning directly inside Claude Code: from the terminal you scan recent changes or the whole repository, it runs on the same Claude inference you are already paying for, and it targets high-severity bugs before they ship. What it changes is where security scanning sits in the workflow, and that shift is worth more thought than the feature list.

What shipped

• Scan scope: recent changes (the diff you are about to commit) or the full repo.
• Runtime: the same Claude model and session that is writing the code; no separate service, no second pipeline.
• Target: high-severity vulnerabilities, pre-ship.
• Status: beta, distributed as a Claude Code plugin.

The economics are the interesting part. A conventional SAST step is a separate pipeline with its own runtime, its own rule set and its own findings queue. Here the model already has the diff and the surrounding files loaded in context because it just wrote them, so the marginal cost of a scan is one more inference call, not a second toolchain.

From gate to loop

Static analysis after the commit is a gate: code goes in, findings come out, someone triages them later. A scan inside the agent loop is different in kind. The agent wrote the change, scans it, sees the finding, and can fix it in the same session before a human ever sees the PR. That collapses the distance between introducing a bug and removing it from days to seconds, and the fix is made by the thing with the most context about why the code looks the way it does.

A security finding that arrives inside the same session that wrote the code is worth ten that arrive in a dashboard next Tuesday.

It also changes who owns the result. With a SAST gate, security owns the tool and engineering owns the backlog. With a scan in the loop, the engineer running the agent owns both, which is better for velocity and worse for anyone who needs an audit trail proving a scan happened.

The trade-off nobody should skip

A rule-based scanner is deterministic: the same code produces the same findings, and a missed vulnerability class is a missing rule you can add. A model-based scanner is not. Its quality is the quality of the model plus the prompt, and there is no configuration file you edit to make it catch the thing it missed. As Anthropic's own framing implies, false positives and false negatives are handled by evaluation, not by settings.

So the operating question for any team adopting this is: what is the false-negative rate on our code? You cannot read that off a datasheet. You have to measure it.

How to evaluate it before you trust it

• Build a small corpus of known-vulnerable commits from your own history, 20-40 is enough to start, spanning the classes you care about: injection, auth bypass, secrets, unsafe deserialisation.
• Run the plugin against each and record detected versus missed per class. That is your false-negative baseline.
• Run it against 20-40 clean commits of similar size and record the false positives. That is your noise cost.
• Re-run the same corpus after every model or plugin update; the scanner changes when the model does, silently.
• Keep your deterministic SAST in CI for the classes where the model's miss rate is not acceptable, and use the in-loop scan as the fast first pass.
• Log every scan invocation and result somewhere outside the session so compliance has a record.

The same discipline applies on the adversarial side. If you already run red-team exercises against your LLM features, add the scanner as a target: try to write code the model will approve that a human reviewer would not.

The honest gap

This is a beta and Anthropic has not published detection rates, comparisons against established SAST tools, or which vulnerability classes it was evaluated on. Until someone runs it against a public vulnerable-code corpus and reports numbers, the only defensible way to deploy it is alongside your existing scanner, not instead of it, with your own false-negative measurement as the gate for changing that.