Claude Security Is in Public Beta: What “Scan to Fix” Claims, and What It Does Not

Anthropic’s security product is now a public beta for Claude Enterprise, and its one-line pitch is a sequence rather than an adjective: from scan to fix, done seamlessly. The mechanics beneath that line are stated plainly on the product page — Claude scans your codebase with Claude Mythos, validates findings, and suggests patches you can review and approve. Three verbs, one model name, and a scope limit that is easy to skim past: this is a beta, and it is written for Enterprise customers rather than for anyone who happens to have a repository.

The interesting question was never whether a language model can find a vulnerability. Models have been doing that for a while, sometimes well enough to embarrass the humans who wrote the code. The interesting question is what happens between the moment a finding appears and the moment it is closed, because that gap is where security backlogs live: a queue of plausible problems, sorted by nobody, assigned to everyone, closed by chance. Anthropic’s answer is a pipeline with four stages, and each stage makes a claim that can be examined on its own.

What “public beta for Claude Enterprise” means

The availability line is unusually blunt, and worth quoting rather than paraphrasing: available in public beta for Claude Enterprise. Two buttons sit underneath it — contact sales, and read the tutorial. Neither is a sign-up form. In practice that means the buyer is a company that already has an Enterprise agreement and a security team with enough standing to ask for a new scanner, rather than an individual engineer who wants to point something at a side project.

There is a second, lighter way in. The Claude Security plugin for Claude Code is in beta. It is a different piece of software with a different deployment story — scan, validate and patch inside Claude Code while keeping code in your environment — and it is the version that matters to a team whose obstacle is not budget but a rule about where source code is allowed to go.

The scan does not stop

The first documented behaviour is the deep first scan: Claude runs it once over a codebase, and then keeps scanning as the code changes. It is a small sentence with a large operational consequence. A one-off scan is a photograph. Codebases are not photographs; they are weather. A finding that was accurate on the day of the audit and has been half-fixed by three subsequent merges is worse than no finding at all, because it consumes attention from the people who have to re-read it.

Continuous scanning is also the part of the product that is hardest to fake. It requires the scanner to understand which changes matter, which is a different skill from finding a vulnerability in a static tree. The page does not describe how that prioritisation works, and this article will not guess at it.

The one axis where the claim is specific

Anthropic claims that Claude Security traces data flows across files and repositories to find vulnerabilities that pattern-matching scanners might not detect. That is the most checkable claim in the whole product description, because it names a mechanism rather than an outcome.

Pattern matching, as the name suggests, looks for a known-bad shape: a function call with a tainted argument, a string concatenated into a query, a known unsafe API. It is fast, it is cheap, and it is why traditional scanners are famous for two things at once — catching the same class of bug everywhere it appears, and burying the team in findings that turn out to be unreachable. The alternative is to follow a value from where it enters the system to where it is used, across the boundaries between files and services. That is where the real bugs hide, and it is also where the analysis gets expensive, because the tool has to hold more context than fits in a single function.

Note the hedge in the sentence, though. Might not detect. That is the correct word to use when a vendor has no benchmark to point at, and it is also the reason this claim should be tested against your own codebase rather than accepted as a property of the product.

Adversarial verification, and a threat model you can edit

The second stage is the one that speaks to the false-positive problem every security team knows. Every finding passes adversarial verification before it reaches the team. Something tries to break the finding before a human sees it: to show that the input cannot actually reach the sink, or that the path is guarded upstream, or that the code in question is dead.

The second half of that same sentence is quietly the most interesting design decision on the page. A threat model your team can edit decides what is worth flagging. Practically, that puts the definition of relevance in the customer’s hands. A scanner that decides severity on its own is always slightly wrong, because severity is contextual: an unauthenticated endpoint in an internal admin tool is a different problem from the same endpoint on the public internet, and no vendor can know which one it is looking at. Letting the threat model be edited is the honest admission of that.

It also creates work. A threat model that nobody maintains becomes a filter that hides the things nobody thought of, which is the opposite of what a scanner is for. The teams that get value from this will be the ones that treat the threat model as a living document with an owner, the same way they treat the runbooks.

A patch is the unit of output

Every finding includes a recommended patch for the team to review and approve, and Claude marks the finding fixed once the fix ships. Two claims sit inside that sentence and they deserve separating.

The first is that the output of a scan is a change, not a ticket. This is the difference between telling an engineer that their code has a problem and telling them what the corrected code looks like. It compresses the least enjoyable part of security work — understanding someone else’s code well enough to fix it without breaking the thing it does — and it compresses it for the person who understands the code least. That is also the risk: a patch that looks correct and passes review because the reviewer was tired is a new bug with a green checkmark.

The second claim is about closure. Claude marks a finding fixed once the fix ships, so findings close instead of piling up. Backlog is not a failure of detection. It is a failure of bookkeeping: the same vulnerability is reported seven times across seven scans, and the queue grows faster than anyone can drain it. Tracking a finding to the commit that resolves it is the mechanism that makes a continuous scanner bearable rather than demoralising.

Anthropic is explicit that the human stays in the loop, with every patch requiring review and approval. Anyone deploying this should take that as the load-bearing sentence rather than the disclaimer at the bottom.

Two releases, one direction

Claude Security did not arrive in isolation. Anthropic shipped Code Review as generally available on 15 October 2026, and Claude Security’s continuous scanning plus fix tracking arrived on 21 October 2026 in public beta for Claude Enterprise. Read together, the two say something about direction: review is moving from a gate that a change passes through at the end to a process that runs alongside the change as it is written. The days between those two dates are short enough that the products should be evaluated as one story about where security work is going, not two unrelated releases.

What is not published, and the number that would settle it

The list of unknowns here is longer than the list of claims, and that is normal for a public beta rather than a scandal. How much of a codebase a scan covers is not published. Scan duration is not published. False-positive rates are not published. Detection benchmarks are not published. There is no independent evaluation. Per-seat pricing is not published, and neither is the list of supported languages.

Of those, the missing detection benchmark is the one that changes a buying decision. Without it, “catches what pattern-matching scanners miss” is a directional claim that cannot be compared to the scanner already in the budget. The supported-language list is the second: a polyglot repository is the normal case in a company of any size, and a scanner that is excellent in three languages and absent in the other five is a scanner that produces a misleading picture of the risk surface.

None of this means the product does not work. It means the evaluation has to be done by the buyer, with the buyer’s own code, and that a demo will not do it.

How to evaluate it anyway

If your team is going to try it, the useful experiment is not a fresh repository with a deliberately planted weakness. It is a repository that already has a history: a service that had an incident last year, a library with a known vulnerability that took two weeks to close, a module everyone is slightly afraid of. Point the scan at that and compare what it finds with the findings your team already wrote down. Recall on known problems is measurable even when a vendor has not published a benchmark, because the ground truth is in your own incident tracker.

Second, watch the threat model. If the first thing your team does is switch off most of the categories to get the queue down, you have learned that the default model does not match the risk your team actually carries, and you should fix the model rather than the filter. Third, measure the step that matters: how long it takes from a finding appearing to a patch being merged. That number is yours, it is comparable across tools, and it is the one the product is actually claiming to move.

Where a router sits, and where it does not

The boundary is worth stating plainly. Claude Security is an Anthropic application. We do not host it, we do not sell it, and we cannot tell you what it did or did not find in your repository. The scanner runs on Claude Mythos, and we make no claim to host that model.

What we do is run models. One OpenAI-compatible endpoint, one key, more than 200 models behind it, provider list price passed through with no markup added, and automatic failover across providers when one of them wobbles. Claude Opus 5.5 is on that catalogue at $4.00 per million input tokens and $20.00 per million output tokens, with a 1M-token context and cache reads at $0.20 per million. That is a fact about our catalogue, not a claim about the scanner.

Where it becomes relevant is the part of a security programme that is not a scanner: the internal tool that summarises a thousand findings into something a human can triage, the agent that drafts the advisory, the review step a team wants to build around its own rules. Those are ordinary model calls, and a router is a reasonable way to make them without hard-coding a vendor. The routing DSL matters when one step wants a small model for volume and the next wants a careful one for judgement; automatic failover matters when the call sits inside a pipeline that runs at three in the morning and nobody is watching.

What the beta is actually asking you to trust

Strip away the framing and the product makes three bets. That a model reasoning over code finds things pattern matching does not. That an adversarial second pass is enough to keep the noise down. That a finding is only finished when a patch ships and the queue closes behind it. The third bet is the least glamorous and the most likely to be right, because it is a statement about process rather than about intelligence.

The first bet is the one to test. Anthropic has published the mechanism — data-flow tracing across files and repositories — and has published no number that shows how well it works. That is not a reason to dismiss the product. It is a reason to run it against a repository whose history you already know, and to judge it on the findings you can verify rather than the ones that look impressive in a demonstration.