How Claude Security Actually Works: Reading the Pipeline From Its Own Source

Anthropic's product page for Claude Security runs about six hundred words and does not contain a single number.

I checked twice, because I assumed I was missing something.

The page tells you Claude "reasons through your code like a skilled security researcher," that it "traces data flows, and catches vulnerabilities that pattern matching tools miss." What it never tells you is how often that works.

No detection rate. No false positive rate. Nothing you could hold anyone to.

The only digit on the whole page belongs to a testimonial carousel counter.

Normally that would be the story. Vendor ships security tool, declines to say how well it performs, and the sensible move is to wait for someone independent to measure it.

Except the Claude Code version ships its entire orchestration as readable source.

Not a whitepaper describing the architecture. The actual scan pipeline, in a public repo, with every cap and retry delay sitting there as a numeric literal.

So the marketing surface has no numbers and the engineering surface has nothing but.

I spent an afternoon reading it. What is in there is more interesting than anything the landing page claims, and it changed how I think about shipping this class of tool.

The naming needs untangling first, because almost every wrong claim I have read about this launch comes from conflating two of these six.

Claude Security, managed. Lives at claude.ai/security, in the web app, not the CLI.

You point it at a connected GitHub repository, start a scan, read findings in a dashboard. Clicking through to fix one opens a Claude Code on the Web session scoped to that finding.

Public beta, Enterprise only, announced April 30 2026. It used to be called Claude Code Security, which is part of why the naming is a mess.

The Claude Security plugin. Version 0.10.0, installed with /plugin install claude-security@claude-plugins-official, invoked as /claude-security.

Still beta. Its source is public, which is the only reason this issue can say anything concrete.

/security-review. A built in slash command since August 6 2025.

One pass over the diff between your branch and origin's default branch. Needs an origin remote, single agent. People keep citing this as if it were the new thing.

The GitHub Action at anthropics/claude-code-security-review, also August 2025.

This is the only CI surface Anthropic ships, and it matters later for reasons that have nothing to do with CI.

The security-guidance plugin, version 2.0.6. The one that runs without being asked.

Code Review, at pull request time. Research preview, Team and Enterprise only, unavailable under Zero Data Retention.

Anthropic publishes this layering themselves, as a six row table in the plugin docs, which is more honest than most vendors manage.

The last row is the one I would point at. For continuous integration, their recommendation is your existing static analysis and dependency scanners.

They are not selling you a CI product.

Half the commentary I have seen assumes they are.

Everything below comes from the plugin rather than the hosted product, and that is a deliberate limit.

The managed version's internals are unpublished. Anthropic describes it as running an "adversarial verification pass," and their blog calls it a "multi stage validation pipeline," which are phrases that could mean almost anything.

I am not going to pretend the two share an architecture when only one of them is readable.

The plugin's orchestration lives in plugins/claude-security/workflows/scan.js in the public anthropics/claude-plugins-official repo. Minified, but legible once you sit with it.

A run writes a directory into your repo named CLAUDE-SECURITY-<timestamp>/ holding three files.

CLAUDE-SECURITY-RESULTS.md carries the findings. Each has an ID like F1, an impact statement, an exploit scenario, its preconditions, and a severity and confidence that are both just HIGH, MEDIUM or LOW.

No score out of ten, which I appreciate. A decimal on a judgement like this is false precision.

The same findings come out as JSONL alongside it.

Then a revision stamp, CLAUDE-SECURITY-REVISION-<sha12>.json, recording the commit scanned, the effort level, severity counts and verification thoroughness.

-dirty gets appended to that filename when uncommitted changes were in the tree. Outside git entirely it reads UNVERSIONED.

That detail is what made me trust the rest.

A report cannot quietly claim to describe a commit it does not describe. Someone thought about the colleague who runs a scan with a half finished refactor in their tree and pastes the results into a ticket.

The directory also ships its own .gitignore, so a careless git add -A cannot sweep a list of your live vulnerabilities into a commit.

Six phases, four effort tiers.

Tiers are low, medium, high and max, defaulting to medium. Most of the interesting behaviour is a ternary on that tier, which is why the constants below come in pairs.

Inventory partitions the repo into components.

The rule it enforces is that every top level directory is either scanned or explicitly skipped with a stated reason, and that accounting is checked before any searching starts.

The component cap is ee = Y ? 24 : 12. Repos of five files or three hundred lines and under skip the ceremony entirely.

Threat model runs one modeler per component, emitting entry points and sinks as file:line references rather than prose.

That choice propagates through the whole pipeline and it is the right one. A location can be checked. A paragraph cannot.

Research is where the parallelism lives. The work is a matrix of component against category, and there are four category lenses:

Researchers per cell is Z = Y ? 2 : 1, so one normally and two at high effort. Underneath those four lenses sits a vocabulary of 41 finding slugs, with off list slugs permitted only as a last resort.

At low effort a single researcher covers every category at once.

That collapses the matrix into one pass and is a much weaker run than the tier name suggests. If you try this on a repo you care about, do not start there.

Sweep gap fills whatever the matrix missed, te = W ? 0 : Y ? 2 : 1 passes of it.

Then two constants that shape what you will ever see.

The candidate cap is re = 400. The verification cap is a plain slice(0, 45).

Only the top 45 deduplicated candidates are ever verified. Everything below that is discovered, counted, and never looked at again.

So the report you read has passed through a fixed size funnel twice before a single verifier saw it.

The run says so, at least. It stamps the number it skipped into the report as unreviewed_candidate_sites.

I cannot think of another scanner I have used that volunteers the size of its own blind spot.

Six subagents, declared in the plugin's allowed-tools.

The frontmatter tells you where Anthropic decided to spend money, and it reads as a design document.

scan-inventory runs on Sonnet at medium effort with only Read, Glob and Grep. Partitioning a repo is bookkeeping and does not need a frontier model.

scan-researcher and scan-verifier both inherit the session model and both run at xhigh. Both can call explore as a subagent of their own.

Cheap model for the map, most expensive setting available for finding and for judging.

I have made the opposite call before, on the theory that the expensive model should do the orchestration. It was wrong for exactly the reason this layout implies.

The hard part is not deciding where to look. It is deciding whether what you found is real.

All of the above is on demand. You type a command and wait several minutes.

The security-guidance plugin is the half most people will end up living with, because it fires on its own, in three layers of increasing cost.

The first is regex, throwing pattern warnings as you edit. Roughly as clever as a linter and about as fast.

It has room for 50 custom rules, and it skips any pattern that risks catastrophic backtracking. That is the sort of guard you only write after a regex has taken production down once.

The second is a model reading your diff on the Stop hook, so after Claude finishes rather than while it works.

The limits read like someone watching a bill. 30 files, 3 consecutive reviews, 20 per rolling hour, diffs capped around 8 KB.

The third is an agentic commit reviewer that can look around the repository instead of only at the diff, configurable through SECURITY_REVIEW_MODEL and SG_AGENTIC_MODEL and defaulting to Opus.

On first run it quietly builds a virtual environment under ~/.claude/security/ and installs the Claude Agent SDK. Worth knowing before it happens on a machine you did not expect it to.

There is one documented gap I would put on a sticky note.

Shell escaping. The docs say the diff review does not reliably catch it.

Which is precisely the class of bug where you would hope a regex layer and a reasoning layer would cover for each other.

Anthropic's phrasing about that gap has stuck with me: a missed vulnerability there is a quality issue, not a plugin vulnerability. That is the correct frame for every tool in this piece, and the one most security vendors work hard to blur.

The product page's "adversarial verification pass," singular, is a jury of three in the plugin.

One voter per lens, and the lenses are reachability, impact and defenses.

Each returns a structured verdict of exactly TRUE_POSITIVE or FALSE_POSITIVE, plus a line or two naming the decisive file:line.

A finding survives only on a two of three majority.

What I did not expect was the failure handling.

Voters die, calls time out, and the code retries twice with jittered backoff at we = [8e3, 25e3]. If fewer than three come back, the check is 3 !== o.voters and the finding is discarded as not keepable.

A dead voter removes the finding.

Verification in this pipeline can only ever subtract, and it can never wave something through because the infrastructure wobbled.

The other decision is the one I would steal outright.

The run's verification tally is, in Anthropic's phrasing, computed in code rather than asserted by the model that produced the findings. Confidence is clamped in code.

The report line is a literal <n>/3 lens verifiers confirmed, filled in by arithmetic the orchestrator performed, not by a sentence a model wrote about its own diligence.

Every evaluation harness I have built or inherited has failed at that exact seam.

You ask the model to summarise how carefully it checked, the summary is generous, and the generosity is invisible because it arrives in the same confident register as everything else.

Moving the count out of the prompt and into the orchestrator costs almost nothing and removes a whole category of self report bias.

Three votes drawn from one base model are not three opinions.

They share training data and they share failure modes, so a vulnerability class the model systematically misreads will be systematically misread three times over.

Two of three agreement among correlated voters is not the statistical comfort the shape of it implies. The prompt concedes as much without resolving it.

There is no published inter voter agreement data, which is the number I actually want.

How often do the three lenses disagree?

If the answer is rarely, the panel is theatre with a cost attached. If it is often, it is doing real work. Nobody outside Anthropic can tell you.

Put that together with the slice(0, 45) and something uncomfortable falls out.

A short report is partly an artifact of suppression rather than a statement about your code. It tells you the panel kept nothing, out of at most 45 candidates it examined, out of at most 400 it found, out of however many exist.

A clean Claude Security run is not a clean codebase.

The plugin's own docs put the principle more elegantly than I can: an unknown count is never small.

Here is the part I did not go looking for.

Anthropic shipped a security reviewer eighteen months ago, as that August 2025 GitHub Action, and the code is still public.

Its false positive filter sits in claudecode/claude_api_client.py, under a source comment that reads "Claude API client for false positive filtering." Look at what it does when the filtering call fails.

Maximum confidence, assigned on error.

The 2025 design failed open. A broken verification call did not shrink your report, it inflated it, and every transient API failure quietly promoted an unchecked candidate to a ten out of ten finding.

The 2026 plugin discards a finding whose voter fails to return.

Identical problem, opposite default, same vendor, a year and a half apart.

There is a smaller tell in the old code too.

Its filter matched on prose, combined_text = f"{title} {description}".lower(), so the triage layer was reading the model's own summary of the finding rather than the code the finding pointed at.

The 2026 voters return a file:line and are aimed at the source.

I do not think Anthropic published a retrospective on any of this. You just read it out of two repositories eighteen months apart, and the direction of travel is unmistakable.

Trust the model less. Move the arithmetic into code. Make the failure path subtract.

Everything in this section is Anthropic's own documentation, which is the only reason I will state it as flatly as I am about to.

It is not isolated.

The plugin adds no sandbox of its own, runs in your session under your permissions, and the scanned repository's .git/config, its .claude/ settings and hooks, and its CLAUDE.md all apply as they normally would.

Repository text is treated as data under review, so instructions addressed to the scan get noted rather than obeyed. Anthropic still says plainly that this is not a defense against a hostile repository.

If you are scanning code you did not write, run the whole session inside sandbox-runtime.

It does not commit.

Patches are drafted in a scratch copy of the repo, never your working tree. Output lands at patches/F<n>.patch and you apply it yourself with git apply.

No commits, no pushes, no pull requests opened on your behalf.

The patch contract is tighter than I expected. A patch is only emitted when an independent verifier will vouch for three things at once.

That it addresses that specific finding. That it introduces no new vulnerability. That it leaves behaviour otherwise unchanged.

Their definition of unchanged includes the input surface, so a fix that narrows which inputs the code accepts counts as a behaviour change and gets held back with a note instead.

It is not deterministic, and the docs say so. Two runs over the same commit can return different findings.

And nobody has published how well it works.

No precision, no recall, no false positive rate, no benchmark, from Anthropic or anyone independent. I looked hard, including through the academic vulnerability detection literature.

Any accuracy number you see attached to Claude Security was invented somewhere between the source and your feed.

There is one Anthropic security result with real numbers on it, and it gets attached to the wrong product constantly.

In February 2026 their Frontier Red Team published a campaign that found more than 500 high severity vulnerabilities across open source projects.

That was Opus 4.6, driven by the team, with heavy human validation, and their writeup is refreshingly candid about the friction and about hand writing patches themselves.

It demonstrates what the models can do. It measures nothing about the product.

The same caution applies to the framing everyone reaches for first, that AI now writes so much code that AI has to review it.

I went looking for the evidence and it is thinner than the confidence around it.

The one peer reviewed anchor I found is Cotroneo, Improta and Liguori, accepted to IEEE ISSRE 2025, across more than half a million samples. It does report that generated code carries more high risk security vulnerabilities.

It also reports that human written code carries greater structural complexity and more maintainability problems.

So the honest reading is different defect profiles, not one side losing.

The multiplier for vulnerability density that circulates in every post about this traces back only to content marketing. I could not reach a primary source for it and I would not repeat it.

Determinism settles the placement question before any capability argument gets a turn.

A merge gate has to give the same answer twice. This does not.

So it cannot be the thing that blocks your pull requests, and Anthropic never suggests otherwise. Their layering table hands the CI row to your existing scanners, which is the vendor telling you to keep Semgrep, keep CodeQL, keep Dependabot.

Where a model reviewer plausibly earns its keep is the class of bug a rules engine structurally cannot express.

Authorization logic that is wrong rather than absent. A business rule violated across four files with no single line to flag. A check that exists, passes review, and runs after the thing it was supposed to guard.

Plausibly, though.

The case rests on reasoning about how the technique works, not on anyone having measured it, and I would rather say that than dress an intuition up as a finding.

One correction on cost while I am here.

The fifteen to twenty five dollar figure circulating is a documentation estimate for Code Review, a different product, billed through usage credits, on a page that describes its own dashboard figures as estimates.

It is not a Claude Security price. What is published is twenty dollars per seat plus usage at API rates, with Claude Security marked beta.

So my read is a deep, occasional, human triggered pass sitting beside your existing scanners rather than replacing any of them. Run it before a release or after a risky refactor, and never wire it to a branch protection rule.

Strip out the security subject matter and there are three decisions in this code I would copy into anything where a model judges output.

Keep the tally in code and out of the prompt, because a model asked to report its own thoroughness will report favourably and will sound the same doing it.

Make the failure path subtract, so a judge that dies discards the candidate instead of approving it. That is the single line of difference between the 2025 Action and the 2026 plugin, and it is worth more than any prompt engineering either contains.

And write down what you did not examine, because a coverage ledger is what makes a short report readable instead of reassuring.

On how to evaluate this generation of tool, I have landed somewhere slightly awkward.

Judge it as an instrument whose method you can audit, not as a detector whose numbers you can trust.

There are no numbers to trust. There is an unusually legible method built around not believing the model.

I would rather have that than a benchmark score I could not reproduce, and I did not expect to feel that way when I opened the repo.

What would change my mind is somebody running it against a corpus with known ground truth and publishing the precision. Until then everyone arguing about whether it works, in either direction, is arguing from vibes.

Claude Security product page. The marketing surface, six hundred words, no numbers.

Claude Security plugin docs. The six row layering table and the trust model, in Anthropic's own words.

anthropics/claude-plugins-official. The orchestration source. Read plugins/claude-security/workflows/scan.js.

anthropics/claude-code-security-review. The 2025 Action, still public, still failing open.

If this made a tool you were about to trust look more interesting and less finished, send it to whoever on your team is about to turn it on.