Claude Security Stops Waiting For A Scan: What Continuous Monitoring Changes For Defenders

Posted on by
Contents show
A dark editorial illustration of a wide horizontal stream of code lines flowing continuously past a single bright vertical marker, representing continuous monitoring in Claude Security

A scheduled scan is a photograph, and the argument for continuous monitoring is that the photograph is stale before anyone reads it. The code keeps moving after the shutter closes, and the findings list ages from the moment it is produced. Anthropic's answer to that problem is the latest version of Claude Security, which watches repositories as code changes, tracks which findings have actually been fixed, and uses a threat model of your own environment to decide what deserves attention.

The latest version of Claude Security is the subject of this article, and the short version is that a scanner you had to remember to run has become one that notices. Anthropic introduced Claude Security as Claude Code Security in a limited research preview on 20 February 2026, opened a public beta to Enterprise customers in April, and the current version now runs on Claude Mythos 5.1 with scheduled and continuous coverage. This article works through what Claude Security does today, what the new monitoring and fix-tracking model changes, where the evidence for its effectiveness comes from, and the practical limits in Anthropic's own documentation.

Everything below comes from Anthropic's own material: the launch announcement, the Help Center product documentation, the official getting-started guide and the product page. Nothing is drawn from third-party summaries.

What Claude Security is, and what it is not

The Help Center definition is careful: Claude Security is a capability built into Claude that scans codebases for security vulnerabilities and suggests targeted patches for human review. The launch announcement explains why Anthropic built it rather than pointing customers at existing tools.

Static analysis, the method behind most automated scanners, is rule-based. It matches code against known patterns, which catches exposed passwords and outdated encryption but misses the subtle, context-dependent problems, flaws in business logic or broken access control, that skilled human researchers find. Claude Security instead reads and reasons about code the way a researcher would: understanding how components interact, tracing how data moves through the application, and catching multi-component patterns that a pattern match cannot express.

Two design claims follow from that, and both are checkable in the product.

Every finding is verified before it reaches you. The launch announcement describes a multi-stage verification process in which Claude re-examines each result, attempting to prove or disprove its own findings and filter false positives. The product page calls this an adversarial verification pass. The Help Center adds that scans are stochastic by design: unlike a traditional static analyser, an agent adapts its analysis to each run, reasoning over code context rather than applying fixed pattern matches. That is what enables the depth, and it is also why the same repository can produce different findings on different runs.

Nothing is applied without human approval. The launch announcement states that developers always make the call, and the product page repeats it with a caution that Claude can make mistakes, so patches should always be reviewed before applying them, especially for critical systems. The product suggests; the team decides.

That second claim is the honest boundary of the product. Claude Security produces findings, confidence ratings, severity ratings and suggested patches, and the remediation session opens in Claude Code on the Web where a human reviews and applies. Anyone hoping for a fire-and-forget security robot will not find one here, and Anthropic is explicit that this is deliberate.

What the monitoring model changes

The earlier version of Claude Security was fundamentally pull-based: someone chose a repository, chose a scope, started a scan, and waited. The current model inverts that, and three changes carry the weight.

Scans follow the code. A project connects repositories through the Claude GitHub app, including GitHub Enterprise Server, or through an access token, with the branch and scope chosen per repository. The framework runs a deep baseline scan and then scans changes regularly, with frequency based on the risk and complexity of the change. The findings list stays close to the current state of the code rather than drifting away from it between scheduled runs.

A project can hold multiple repositories. That sounds like an organisational convenience, and it is more than that: the announcement notes it lets the scanner catch issues that live between services, giving the example of a backend that trusts input a client was supposed to validate. Cross-service flaws are the ones that a per-repository scan structure structurally misses, because no single repository contains the whole picture.

Fixes are tracked, not just findings. Most fixes happen outside the tool that found the issue. Claude Security checks open findings against the code that changed and marks them fixed when the fix lands, whether the fix was made in Claude Code or in a separate process. If the issue reappears later, the finding reopens automatically. That last behaviour is the quiet improvement in Claude Security: regressions are the failure mode that makes vulnerability lists untrustworthy, because a ticket marked done that silently reopens destroys confidence in the whole board.

For teams that live in tickets, the plumbing matters as much as the scanning. Findings can be exported as CSV or Markdown, pushed to Slack or Jira through webhooks, and dismissals carry forward so a triage decision made once stays visible. The getting-started guide also makes a point that most teams learn the hard way: keep the CSV exports, because they are the audit trail that shows what was scanned, when, and how the team responded.

The threat model: your environment changes the verdict

The most interesting new feature in Claude Security is not scanning at all. It is context.

Each project now has a knowledge base where the team describes how code is deployed, which security policies apply, and anything a new security engineer would need to know. Claude Security also generates a threat model from the code, which the team can review and edit. Subsequent scans use that threat model to decide what is worth flagging, and added context lets the scanner skip risks the environment already handles.

That is a significant change in how findings are judged, and the severity rules in the documentation show why. Severity is assigned per finding based on exploitability in your codebase, not on the category. The same category can land at different severities in different repositories. The published scale runs from High, exploitable by an unauthenticated remote attacker against a default deployment with no meaningful preconditions, through Medium, exploitable behind authentication or needing one or two realistic preconditions, to Low, which needs three or more preconditions, local-only access, or lacks a concrete demonstrated attack path.

A context-dependent severity means the same SQL injection behind authentication can be Medium in one Claude Security project and Low in another, depending on how the code is deployed and what the environment already mitigates. That is more honest than a category-based score, and it also puts a responsibility on the team: the threat model is editable, which means its quality is your quality. A threat model that documents compensating controls you do not actually have will suppress findings you should have seen. Review it like code, because it now behaves like code.

Each Claude Security finding also carries an explanation of how an attacker could reach the vulnerable code, with severity judged against the project's threat model, and findings can include a diagram of the attack path. The goal, per the announcement, is that teams fix what is actually reachable first.

The model, the pricing and the enterprise plumbing

Three operational facts decide whether this is usable for a given team, and all three come from Anthropic's documentation.

The scan model is fixed; the fix model is yours. Scans run on Claude Mythos 5.1 for Enterprise customers, and users receive findings without direct access to that model. Suggested patches open in Claude Code on the Web and can be implemented with whichever models the account has. The Claude Security plugin for Claude Code is different software: it uses whatever models the account has, and only the Claude Security product itself runs on the Mythos tier.

Cost is consumption, not a licence. The Help Center states that scans are charged at direct token cost only, with no additional platform fee. The getting-started guide adds the practical warnings: Extra Usage must be enabled for consumption billing to work, costs scale with the size and number of scans, spend limits should be set to match expected usage, and a separate spend limit can be configured for the feature after enablement. Scan time varies by repository and by what the agent does, so the bill is best modelled empirically on a small scoped directory before pointing it at a monorepo.

The requirements are real. Claude Security is in public beta for Enterprise plans. It requires Claude Code on the Web enabled, the Claude GitHub App installed with access to the repositories to scan, premium seats for each user who runs scans, and, for GitHub Enterprise Server, an instance already connected to Claude Code on the Web. Repositories outside GitHub and GitHub Enterprise Server are not supported today. Severity is not configurable. And there is no zero data retention arrangement by default: Anthropic may retain data where required by law or to address usage policy violations.

The announcement also includes a commercial sweetener for evaluation: organizations receive 25,000 dollars in free usage credits each month for two months, applying to usage through 31 December 2026. For a team that has been waiting for a reason to measure cost per repository, that window is the reason.

Where the effectiveness evidence comes from

A security product's claims deserve scrutiny, and Anthropic's own launch material is the primary evidence base.

The launch announcement for Claude Security reports that using Claude Opus 4.6, the team found over 500 vulnerabilities in production open-source codebases, bugs that had gone undetected for decades despite years of expert review, with triage and responsible disclosure under way with maintainers. It also describes the research lineage: the Frontier Red Team entering capture-the-flag competitions, a partnership with Pacific Northwest National Laboratory on defending critical infrastructure, and Anthropic using Claude to review its own code.

The current announcement adds adoption figures: thousands of organizations have used the product since the April beta and have found over a million vulnerabilities. That is a usage number rather than a validated-detection number, and the distinction matters. A million findings tells you the scanner is running; it does not tell you the false positive rate, which is the number a security team actually buys. Anthropic's answer to that question is structural rather than statistical: the adversarial verification pass, the confidence rating per finding, and the human review gate.

There is also a boundary argument here that regular readers will recognise. A scanning agent with write access to your repositories, your tickets and your deployment context needs enforcement that does not depend on the agent behaving, which is the same principle we covered in the Nvidia OpenShell article. The scope-of-use terms deserve attention too. The Help Center states that you may only scan code you or your company owns and hold all necessary rights to scan, and explicitly not third-party or open-source code beyond what is included in your own codebases. Pointing an agent-based scanner at someone else's repository is a terms violation, not a reconnaissance trick.

For context on the broader debate, the launch framing is that attackers will use AI to find exploitable weaknesses faster than ever, and defenders who move quickly can find the same weaknesses first. The same capability argument runs through our coverage of the agentic security research, and the deployment discipline is the one we set out in the production-grade agentic systems guide: evaluation belongs on your own code, with your own harness, before the claims transfer.

What to do with it this week

For a team that already runs Claude Code on the Web, the Claude Security enablement path is short: an organisation owner turns it on in settings, confirms the GitHub app and premium seats, sets a spend limit, and creates the first project. The getting-started guide recommends scoping large repositories to individual modules rather than whole monorepos, which raises determinism and focuses the agent.

Four practices will decide whether it helps.

Start with a scoped directory and one repository. The guide's own recommendation for large repositories, and the cheapest way to learn what the findings look like on code you know intimately.

Write the knowledge base before the first scheduled scan. The threat model edits future verdicts. Document the real deployment, the real compensating controls, and the internal context a new engineer would need, then review the generated threat model against reality before letting it shape severity.

Wire findings into the system where work happens. Webhooks into Slack or Jira, exports into the tracker the team already uses, dismissals recorded with reasons. A scanner whose findings live in its own dashboard becomes a second backlog nobody reads.

Keep the human gate. The product is built so that Claude Security patches require review and approval. The getting-started guide pairs scheduled scans with a named owner, and that pairing is the actual control: frequency without ownership produces a backlog, and a backlog is what people learn to ignore.

For teams weighing this against their existing setup, the honest comparison is not Claude Security versus a static analyser. It is a reasoning-based scanner with stochastic runs and consumption pricing versus rule-based coverage with deterministic runs and licence pricing, and the right answer depends on the codebase, the team's reviewer hours, and how much of the backlog is logic-level bugs the rules never matched.

Where the numbers stop

  • The million-vulnerability figure is a usage statistic from the vendor. It measures that scans ran and findings were produced, not their accuracy, and no independent false positive rate has been published in the material available to me.
  • The 500-plus open-source vulnerabilities claim comes from Anthropic's own report using Claude Opus 4.6. It is a striking number and a vendor measurement, with triage and disclosure still in progress at publication time.
  • Severity ratings depend on the project threat model, which the customer writes and edits. A scanner whose judgement depends on customer-supplied context inherits the quality of that context.
  • Scan runs are stochastic by design, per the Help Center, which means findings can differ between runs on the same code. Treat any single scan as a sample rather than a census.
  • In this run I read the launch announcement, the Help Center product documentation, the official getting-started guide and the product page. I did not read the full commercial terms behind the usage credits offer, and the credit amounts are quoted here as stated in the announcement.

FAQ

What is Claude Security?

Claude Security is a capability built into Claude that scans codebases for security vulnerabilities, verifies its own findings through an adversarial pass, and suggests targeted patches for human review. It is available in public beta for Claude Enterprise customers, runs scans on Claude Mythos 5.1, and now monitors repositories continuously as code changes rather than waiting for a scheduled scan.

How does Claude Security decide severity?

Severity is assigned per finding based on exploitability in your codebase, not on the vulnerability category. High means exploitable by an unauthenticated remote attacker against a default deployment with no meaningful preconditions. Medium means exploitable behind authentication or with one or two realistic preconditions. Low means three or more preconditions, local-only access, or no concrete demonstrated attack path. The judgement is shaped by the project threat model, which your team can review and edit.

What does Claude Security cost?

Scans are charged at direct token cost only, with no additional platform fee. Extra Usage must be enabled, costs scale with the size and number of scans, and a separate spend limit can be set for the feature. Anthropic is currently offering organizations 25,000 dollars in free usage credits per month for two months, applying to usage through 31 December 2026.

The short version

Claude Security has moved from a scanner you run to a monitor you connect. Repositories join a project through the GitHub app or an access token, a baseline scan is followed by change-based rescans, findings are marked fixed when the fix lands and reopen if the issue returns, and a customer-editable threat model decides what is worth flagging. Findings arrive with severity judged against your environment, an attack path explanation, and a suggested patch that opens in Claude Code on the Web for human approval. It is Enterprise-only, billed at token cost with no platform fee, powered by Claude Mythos 5.1 without requiring direct access to that model, and backed by a two-month credit offer through the end of the year. The caveats are in Anthropic's own documentation: runs are stochastic, the million-vulnerability figure is usage rather than accuracy, and the quality of the threat model you write will shape the verdicts you get.

Sources
Subscription Form