Claude Security Now Runs on Mythos 5. The Delivery Model Is the Actual Story.

On August 21, Anthropic announced that Claude Security scans now run on Claude Mythos 5 for all Enterprise customers. Read quickly, that lands as a routine version bump: the scanner got a better model, findings should improve, move on. Read carefully, it is something considerably more unusual, because Mythos is the model family Anthropic has explicitly and repeatedly declined to sell.

Since Project Glasswing launched on April 7, Mythos-class access has been restricted to a vetted set of defenders: eleven launch partners including AWS, Apple, Cisco, CrowdStrike, Google, JPMorganChase, the Linux Foundation, Microsoft, NVIDIA, and Palo Alto Networks, plus more than forty additional organizations that build or maintain critical software infrastructure, plus open-source maintainers reached through the Claude for Open Source program. Anthropic's own language on general availability was direct: it does not plan to make Mythos Preview generally available, while stating that the eventual goal is to let customers safely deploy Mythos-class models at scale. The stated blocker was safeguards, specifically the need to develop protections that detect and block the model's most dangerous outputs before wider release.

So the interesting question is not whether the scanner improved. It is how an organization that cannot buy this model is nonetheless running it against its codebase this week. The answer is the part worth understanding, because it describes a delivery pattern that is going to show up well beyond security tooling.

What the Tool Actually Does

Claude Security reads source code. That single sentence rules out a large share of what people assume when they hear the phrase AI security scanner. It is not testing a running system, not probing a staging environment, not sending traffic anywhere. It connects to a repository, reads the code the way a reviewer would, and reasons about how the pieces actually fit together rather than pattern-matching against a rule set. Anthropic describes the focus as high-severity vulnerabilities including memory corruption, injection flaws, authentication bypasses, and complex logic errors, which is a fair description of the category where semantic understanding beats syntax matching by the widest margin.

The second thing it does is argue with itself before it shows you anything. Findings pass through a validation stage that independently examines each one before it reaches an analyst, and what surfaces carries a confidence rating alongside the severity. This is the design decision that separates the tool from a generation of scanners whose practical failure mode was volume: a queue long enough that nobody works through it, with the genuinely dangerous items buried somewhere inside. The value proposition is not more findings. It is a shorter list you can actually believe.

What lands in front of a reviewer is structured as a case file rather than an alert. Each finding carries a title and a plain-language explanation of the vulnerability, the location down to the file and line, an impact statement covering what could go wrong if it is not addressed, reproduction steps, a recommended fix, a severity rating of high, medium, or low based on exploitability, and a CWE category. Findings can be dismissed with a documented reason, pushed to Slack or Jira through webhooks, or exported to CSV and Markdown for an audit trail. From there, a reviewer moves a finding into a Claude Code session that drafts the patch, and a human reviews the diff and decides whether it ships.

Capability Without Access

Here is the architecture that makes the August 21 announcement possible. Anthropic's stated concern about Mythos-class models is not that the capability is bad. It is that the capability is dual-use in the most literal sense: a model good enough to find a memory corruption bug in a widely deployed C library is, by construction, good enough to find that bug for someone with worse intentions. The safeguards problem is real and Anthropic has said publicly that it is not solved.

Claude Security resolves that tension by changing what gets delivered. A customer does not receive the model. A customer receives what the model produced: a specific finding, a specific patch, a specific alert. Anthropic's own framing of the risk calculus is that when users can only receive specific outputs, such as a patch for a vulnerability or a security alert, the risk profile drops considerably. The model stays behind a boundary. The output crosses it. Defenders get Mythos-level results without Mythos becoming available to anyone who might misuse it.

This is worth sitting with, because it inverts the shape of the vendor conversation that most enterprise AI procurement is built around. The usual question is which models am I getting access to, at what rate limit, under what data terms. Here the answer is that you are not getting model access at all, and that is the point rather than a limitation. What you are buying is a bounded output channel from a capability that is not otherwise purchasable. The evaluation criteria that follow from that are different: less about model selection and context windows, more about whether the outputs are good, whether the boundary holds, and what happens to your code on the way through.

Anthropic is extending the same pattern in two directions. Security partners are building Mythos 5 into products that defenders already run, so that Mythos-level outcomes arrive through existing tooling rather than a new console. And the Cyber Verification Program is expanding to give verified defenders access to defensive capabilities like vulnerability triaging and validation on Mythos-class models, along with reduced blocks on Opus and Sonnet-class models. Alongside both, a new Defender Advantage Fund is committing thirty-five million dollars in Claude credits to organizations helping open-source maintainers secure their software.

The Model Boundary Runs Through Your Own Workflow

There is a detail in Anthropic's documentation that is easy to read past and worth pulling out, because it changes how you should describe this tool internally. Mythos 5 runs the scan. It does not write the patch. When a finding moves into a Claude Code session for remediation, that session uses whatever models your account already provides. Two different models, at two genuinely different capability tiers, inside what looks from the outside like a single continuous workflow.

That boundary is defensible and probably correct: the scan is the read-only step where frontier capability pays off most, and the patch is where a human is reviewing a diff anyway. But it means the finding quality and the patch quality have different ceilings, and a security team should not assume that a high-confidence Mythos finding implies a high-confidence patch. They are separate claims produced by separate systems. Any documentation you write for a security review should say so plainly rather than describing the whole thing as Mythos-powered, which would be accurate for half of it and misleading for the other half.

The practical version of this: treat the finding as the strong artifact and the patch as a well-informed first draft. That framing survives contact with a skeptical reviewer. The alternative framing, where the tool finds and fixes vulnerabilities, does not survive the first patch that needs meaningful rework, and it will cost more credibility than it buys.

Where It Sits Next to the Stack You Already Run

The honest positioning is complement, not replacement, and the strongest evidence for that is what Anthropic's own partners are doing. CrowdStrike, Microsoft Security, Palo Alto Networks, SentinelOne, and Wiz have been embedding these capabilities into their products rather than being displaced by them. Vendors do not integrate a tool that makes them redundant.

The functional reason is the same one from the section above: this thing reads code. It does not exercise a running system, so dynamic testing, fuzzing, runtime monitoring, and everything downstream in the SOC keeps doing work that a source-code reader structurally cannot do. Nor does it replace the breadth coverage of an existing SAST deployment, which is scanning far more repositories on a far more predictable cadence than a beta product should be trusted with. What it adds is depth on a specific class of problem: the semantically complex vulnerability that rule-based tooling walks past, delivered with enough context and validation that someone actually acts on it.

For an organization that has already worked through a hardening track, the useful question is not whether to swap anything out. It is which repositories carry the risk that existing tooling is structurally worst at catching, and whether a depth pass on those specific repositories is worth running now, in beta, with the limits below understood.

The Limits Worth Stating Plainly

Claude Security is in public beta. The hosted product at claude.ai/security requires a Claude Enterprise plan and an organization owner to turn it on in organization settings, though the separate Claude Security plugin for Claude Code is in beta for all Claude Code users and runs scans from the terminal. Scans reach GitHub.com and GitHub Enterprise Server, and nothing else. Self-hosted Git that is not GitHub is not supported, and a GitHub Enterprise Server deployment needs an IP allowlist entry before anything works. If your organization enforces SSO, the GitHub connection needs SSO authorization too. There is no separate charge beyond standard token usage.

The limit that matters most is the one Anthropic states most clearly, and it should be quoted rather than paraphrased in any internal writeup: every patch must be reviewed and approved by a human before it can be implemented, and Anthropic's own documentation adds that Claude can make mistakes, so proposed patches should always be reviewed before being applied, especially for critical systems. That is not defensive boilerplate to skim past. It is the operating model. A team that positions this tool as automation that reduces security review is describing a product that does not exist and will lose the room the first time a security lead pushes back.

There is also a scoping consideration that is less a limitation than a discipline. A vulnerability scanner that reasons about how code fits together does better work on a bounded, coherent target than on an enormous monorepo where it has more surface to cover and the results are harder to interpret. Narrow the first scan to something whose risk profile you already understand well enough to judge the output against. The point of a first run is calibration, not coverage.

What to Do About It

Three things are worth doing in the next two weeks. First, if you are on Claude Enterprise, run one scan on one repository your team knows intimately, and read every finding against your own understanding of that code. This is the only way to calibrate how much the confidence ratings are worth in your context, and it costs an afternoon. A team that has never seen the output has no basis for the conversation that follows.

Second, write down the model boundary before anyone else describes the tool for you. Mythos 5 scans, your account's models patch, a human approves. Any security review packet that gets this wrong in either direction, overstating it as end-to-end frontier capability or understating it as just another scanner, is going to need correcting later at a worse moment.

Third, if platform choice is still open, note that this is an Anthropic-direct capability. The same caveat that applies to the Compliance API applies here: a deployment that landed on a cloud marketplace platform for data-residency or existing-relationship reasons should confirm what it inherits rather than assuming feature parity. That is not an argument against those platforms, which have real reasons to be chosen. It is an argument for checking rather than assuming, which is the cheapest thing on this list and the one most often skipped.

The broader point is worth carrying past this specific product. Anthropic has now shipped a working answer to a problem the whole industry is going to keep running into: what do you do with a capability that is too useful to withhold and too dangerous to hand over. The answer it landed on is to ship the output and keep the model. Expect to see that shape again.