Anthropic shipped a Claude Security plugin for Claude Code. It runs a team of agents over your repository, hunts for vulnerabilities, and writes a report.

“AI finds bugs in your code” is a claim you should be suspicious of. So instead of reading the announcement, I read the plugin’s source. The interesting part is not the scanning. It is that the plugin does not let its own model decide how much to trust the results.

Installing It

/plugin install claude-security@claude-plugins-official
/reload-plugins

If Claude Code says the marketplace is missing, add it first:

/plugin marketplace add anthropics/claude-plugins-official

Then /claude-security opens the menu. The version I read is 0.10.0.

It needs Python 3.9 or newer on your PATH. Scanning a diff or suggesting patches also needs a git checkout — a whole-repository scan works without one.

The Three Jobs

JobWhat it looks at
Scan codebaseThe whole repository, or a scoped part of it
Scan changesYour branch’s diff, a pull request’s diff, or one commit
Suggest patchesAn existing report’s findings, turned into patch files

Scan changes is the one you will use most. Pointing it at a PR diff is far cheaper than re-scanning everything, and it fits where review already happens.

What a Scan Leaves Behind

Every scan writes a timestamped CLAUDE-SECURITY-<timestamp>/ directory containing exactly three files:

  • CLAUDE-SECURITY-RESULTS.md — the readable report: each finding with impact, exploit scenario, preconditions, severity, confidence, and a recommendation
  • CLAUDE-SECURITY-RESULTS.jsonl — the same findings, one JSON object per line
  • CLAUDE-SECURITY-REVISION-<sha12>.json — a revision stamp: which commit was scanned, at what effort, severity counts, and how thoroughly the run was verified

That third file is the one to care about. It ties a report to the exact code it describes. The filename gets a -dirty suffix when uncommitted changes were part of the scanned tree — so you can always tell whether a report describes committed code or your working mess.

The directory ships with its own .gitignore. A careless git add . will not sweep a security report into a commit. If you want it in history, delete that one file and commit it normally.

The Part That Matters: The Model Doesn’t Grade Itself

Here is the problem with any AI security scanner. The model finds something, calls it “high confidence,” and you have no way to know whether that confidence means anything.

Claude Security handles this in a way you can check. Every candidate finding goes to independent verifiers whose job is to disprove it, working from the code rather than from the report of it. They are told to call it a false positive unless they can confirm a real path to exploitation. What survives is what you read.

That much is a design claim. This is the part I could verify — from scripts/render_report.py:

def vote_confidence_ceiling(rounds: object) -> str | None:
    """The vote-backed confidence ceiling for one finding, or None.

    A unanimous panel yields `high`; a keep quorum below unanimity yields
    `medium`. None means no usable vote record.
    """

And then, when each finding is assembled:

confidence = confidence_value(item.get("confidence"))
ceiling = vote_confidence_ceiling(rounds_by_id.get(finding_id))
if ceiling is not None and CONFIDENCE_RANK[confidence] > CONFIDENCE_RANK[ceiling]:
    confidence = ceiling

Read that carefully. The model states a confidence. Python then computes what the verification votes actually support, and if the model claimed more than the votes justify, it gets clamped down. Not asked to reconsider. Overwritten.

The same file computes the run’s overall verification status. It is marked verified only when the vote record proves the panel ran for every finding in the report. Otherwise the stamp says unverified and names the reason — for example, that votes.json was missing from the run directory.

This is the same idea as OpenAI publishing Lean certificates for its math proofs, at a much smaller scale. The output ships with a machine-checked claim about its own rigor, so you are not trusting the model’s self-assessment. A report’s own account of how carefully it was verified is a thing you can audit.

Where It Runs — Read This Before Scanning Anything

The plugin is direct about its trust model, and you should be too.

A scan runs inside your Claude Code session, under your permissions. It adds no isolation of its own. The repository’s .git/config, its .claude/ settings and hooks, and its CLAUDE.md all apply exactly as they would in any other session.

That is fine for code you control. It is the wrong tool for code you don’t.

“If you are scanning a repository that you do not trust, such as a third-party dependency or an unfamiliar repository, we suggest running the whole session inside sandbox-runtime.”

This is the trusted-code model: the question it answers is which bugs are in this code, not is this code trying something. If you point it at a random repo from the internet, you are running an agent with your permissions over hostile input.

On that note, the plugin treats everything in the repository — code, comments, and any CLAUDE.md — as evidence rather than instruction. Text addressed to the scan is noted, not obeyed. That is a sensible default, and the README says plainly that it is not a defense against a hostile repository. Take it at its word.

If last week’s Anthropic evaluation incidents taught anything, it is that an agent’s real boundary is the environment you put it in, not the instructions you give it. Same lesson here.

How Patches Work

Suggest patches turns confirmed findings into patch files. Two things about it are well designed.

Your working tree is never touched. Each fix is developed in a scratch copy of the repository. Your checkout and index stay clean.

A patch is only written if reviewers can vouch for three things:

  1. The change addresses that one finding
  2. It introduces no new vulnerability
  3. It leaves behaviour otherwise unchanged — and a change to which inputs the code accepts counts as a behaviour change

If reviewers cannot vouch for all three, you get a short note explaining why instead of a patch. When the patched code has no tests, the patch says so, so you know the claim rests on review rather than on a passing test run.

Patches land as F<n>.patch files. You apply them yourself:

git apply CLAUDE-SECURITY-<timestamp>/patches/F1.patch

Nothing is applied, committed, or pushed for you.

The Honest Limits

The plugin states these itself, which is a good sign:

  • Scans are nondeterministic. Two scans of the same code can surface different findings. Running them regularly builds coverage; one clean scan proves little.
  • It complements SAST, dependency scanning, and code review — it does not replace them. It reasons about code the way a human researcher does, which means it finds a different class of bug than a pattern matcher, and misses things a pattern matcher catches.
  • A whole-repository scan must account for the whole repository. Every top-level directory is either scanned or explicitly set aside with a reason, and that accounting is checked before the search starts. Whatever was skipped is named in the report’s Coverage section — so a clean result tells you what was actually examined.

Worth Using?

Yes, on repositories you own, pointed at diffs rather than everything.

The reason is not that AI finds more bugs. It is that this tool is unusually honest about what it does not know. The confidence numbers are clamped by a vote count computed in Python. The report says what it skipped. The revision stamp says whether your working tree was dirty. Patches refuse to exist when reviewers cannot vouch for them.

Most security tooling asks you to trust a score. This one hands you the receipts.

Sources: Claude Security and the public beta announcement · Claude Code docs · Anthropic’s announcement · plugin source v0.10.0 from anthropics/claude-plugins-official, read directly on August 4, 2026.