No More Pressing Scan: Claude Security Now Watches Code Continuously and Tracks Fixes to Completion

From "press scan" to "always watching the code"

On October 21, 2026, Anthropic updated Claude Security: the security tool for Claude Enterprise customers, still in public beta, moved from scans a person has to start to continuous monitoring. The new flow runs one deep baseline scan, then keeps rescanning changed code as commits land; findings are tracked until the fix ships, and if the same issue comes back later, the finding reopens automatically. In Anthropic's own framing, the tool no longer waits for someone to press scan. It follows the code. That sounds like a small change, but it alters the relationship between a security tool and the pace of development: from "check once in a while" to "know as soon as the code moves."

The timing matters because it sits at the meeting point of two trends. On one side, agents write code faster, and commits arrive more often and in larger batches, so a point-in-time report is stale before anyone has finished reading it. On the other side, security scanning is shifting from "finding vulnerabilities" to "managing them through their whole life": confirming fixes, preventing regressions, and syncing conclusions into the tools a team already uses is where the real time goes. This update covers exactly that second half: continuous scanning, fix tracking, threat models, an API and MCP connector, webhooks, and role-based access control. No single item is revolutionary. Together, they turn a checking action into a standing service.

What actually changed

Start with the scanning mechanism. A team creates a project, connects repositories through Claude's GitHub app (including GitHub Enterprise Server) or with an access token for GitLab and other Git providers, chooses a branch and scope for each, and Claude runs a deep baseline scan, then scans changes regularly based on their risk and complexity. There is no fixed schedule: the official wording is risk- and complexity-based, not calendar-based. A project can hold multiple repositories, which matters for microservice teams, because many genuinely dangerous problems live between services rather than inside one of them — a backend silently trusting input that a client was supposed to validate first is hard to see from a single-repository scan.

Next is fix tracking, the part of this update with the biggest effect on daily work. The old flow produced a list, the team fixed things, and the list's status depended on someone checking by hand. That is how you get "actually fixed but still listed" and "thought fixed but regressed" at the same time. Now Claude Security checks open findings against changed code: when the fix lands, the finding is marked fixed, whether the fix was made in Claude Code or in a completely separate process; if the scanner later finds the same issue again, the finding reopens on its own. The value is not a few saved clicks. It is a trustworthy source for the word "fixed": no longer a tick in somebody's spreadsheet, but a conclusion drawn from comparing code before and after.

Third is how team knowledge enters the scan. Each project now has a knowledge base where teams can describe how code is deployed, which security policies apply, and any controls that cannot be seen from source code alone. Claude also generates a threat model from the code that the team can review and edit, and later scans use that model to decide what is worth flagging and what the environment already handles. This design admits an uncomfortable truth: many false positives happen not because the scanner misunderstands the code, but because it does not know what protections already exist around it. Letting teams write down "we already handle this" is the most direct way to cut useless alerts — provided the team actually writes it and keeps it current, or it becomes one more stale document.

How findings reach the tools a team already uses

Security tools most often fail not on detection, but on what happens after a finding is reported. This update offers three routes out: an API, an MCP connector, and webhooks. The API can list and read projects and findings, resolve or reopen findings, and create and manage projects and repositories; personal access tokens can only see and change what their user can, which matters for permission hygiene. The MCP connector brings Claude Security into Claude and Claude Code, so an engineer can pull up a finding, ask about it, start the fix, and mark it resolved in one session instead of switching tools. Webhooks can notify existing systems when a new finding lands. Alongside these, role-based access controls let admins decide separately who can view projects, triage findings, and create projects, so a large organization can open scanning to the teams that own the code without handing everyone project-creation rights.

For solo developers and small teams, the direct value of this integration surface is limited, since there is no complex security process to plug into. But two ideas transfer even without Claude Security. First, give every security issue an explicit closure standard — not a vague "handled," but "which lines changed in which commit, and what the retest showed." Second, keep a list of "risks we have evaluated and protections we already have," even as a single Markdown file, so the next person does not have to guess again. Tools change. State management and knowledge capture do not.

Price, eligibility, and the boundaries in the official wording

It is worth stating the official terms exactly, to avoid misreading. First, this is for Claude Enterprise customers and remains in public beta, not a general release for all Claude users. Second, on cost: eligible organizations receive $25,000 in free usage credits each month for two months, applying to usage through December 31, 2026, after which usage is billed at direct token cost with no platform fee — but full terms live in the Help Center, including whether unused credits carry over and from which date the two months run, so the announcement's single sentence is not a substitute for that text. Third, scanning runs on the full Claude model family, including Claude Mythos, with no separate Cyber Verification Program access required. Fourth, since the April 2026 public beta, Anthropic says thousands of organizations have used the tool to find over one million vulnerabilities. That is a vendor-reported count of discoveries, not of completed fixes, and not an independently audited result.

Several further boundaries appear in third-party coverage and Help Center documentation, even though the announcement does not dwell on them, and they matter just as much for a rollout decision. First, scan results are stochastic: the documentation acknowledges that, because Claude Security uses an agent that adapts its analysis per run, two scans of the same code can return different results. That means it cannot be treated as a deterministic tool of the kind where identical input guarantees identical output, and teams using it as a merge gate need room for re-checks and human judgment. Second, it does not support Zero Data Retention, which organizations with hard data-residency requirements must confirm first. Third, existing projects do not automatically gain the new capabilities: they must be migrated manually to get continuous scanning and the new credits, migration does not carry over webhooks, scan history, or scheduled scans, and GitHub Enterprise projects cannot be migrated at all. These are implementation details to verify before migration day, not on it.

How it differs from GitHub's parallel moves

Placed next to GitHub's October security work, Claude Security's position becomes clearer. On October 15, GitHub moved agentic autofix for code scanning alerts to general availability: hand an alert to Copilot, and the agent explores the code, proposes a fix, re-runs CodeQL to validate it, and opens a draft pull request for human review. Anthropic's direction is different: this update emphasizes "keep watching" and "track to completion" rather than "fix automatically." A fix can be started from Claude Code, but confirmation of the fix and reopening on regression are handled on the scanning side. One leans toward the act of fixing, the other toward the state of being fixed. For a team, these are complements, not alternatives: autofix addresses how fast something gets fixed; continuous tracking addresses whether a fix still counts after the fact.

There is a deeper philosophical difference. Traditional static analysis is deterministic rule matching: the same code and the same rules give reproducible results. Agent-based scanning like Claude Security is adaptive: it adjusts its analysis path to the code and context, which can widen what it catches but weakens reproducibility. Neither is simply better. Deterministic tools suit gates where the same result must come out every time; agent scanning suits the class of problems that rules struggle to express, especially across services and contexts. A mature team usually runs both: deterministic tools hold the baseline and enforce gates, agent scanning supplements them by finding what rules cannot describe. Treating either one as the only answer guarantees a blind spot somewhere.

Rollout advice by team

If you are already a Claude Enterprise customer using Claude Security, the pragmatic rollout is to pilot on one medium-sized project spanning two services, not to connect every repository at once. Spend the first two weeks on three things: write the first version of the knowledge base (how you deploy, what protections already exist, which alerts can be ignored and why), review the generated threat model by hand before letting it influence later judgments, and measure the false-positive rate and the "fixed then regressed" rate. If, after two weeks, false positives are tolerable and regression tracking has caught something you would otherwise have missed, expand to more projects. During the pilot, do not wire results directly into merge gates; run it as a parallel reference until you have a feel for its variability, then talk about gates.

If you do not have Claude Security but your team already feels that scan reports go stale too fast, do not buy first. Run a process check: how many days pass on average from discovery to fix; who confirms closure after a fix; and how often do closed issues regress, and when do you find out? If you cannot answer those three questions, the bottleneck may be the fix-tracking process itself, not the scanning tool. Establish "every issue has a clear closure standard and an owner" first, and tool evaluation after that will save you wasted spending. Conversely, if the process is already clear and the bottleneck really is that scanning cannot keep up with commit speed, continuous scanning products are worth a serious look.

If you are a solo developer or a small team, this news has few direct action items — you are most likely outside the Claude Enterprise eligibility anyway. But take two habits that cost nothing. First, keep a "known risks and existing protections" list for your own project, even as one Markdown file, noting which alerts you have evaluated and why they can be ignored; your future self will thank you. Second, re-verify fixes: the next time you touch code near a previously fixed vulnerability, run a targeted check instead of assuming it stayed fixed. Both habits block a whole class of "thought it was fixed" incidents without spending anything.

How to handle the stochastic part, concretely

A result that can change between runs, handled badly, produces two opposite overreactions: "results vary, so trust none of them" or "this run found nothing, so there is nothing." A healthier approach sorts agent-scan conclusions into three tiers. Tier one: issues that appear stably across runs with a clear attack path — straight into the fix queue, highest priority. Tier two: issues that appeared once but have a large blast radius — verify by hand first, schedule if confirmed, neither ignore nor panic on a single sighting. Tier three: issues that recur but the team has already evaluated as handled by the environment — record them in the knowledge base with the evaluator and date, and handle future sightings by that record instead of re-arguing them.

Also adopt one simple regression habit: whenever you fix a security issue, record how it was verified — a rescan, a regression test, or a manual review of the fix commit. An automated tracker can mark something "fixed" from code changes, but that mark is about code movement, not about your verification conclusion; the two together make the state complete. For small teams without dedicated security staff, this habit matters even more than tooling, because security memory walks out the door when people leave. A record that says why something counts as fixed is worth more six months later than any dashboard.

Three conclusions you should not draw

First, do not read "over one million findings" as "one million vulnerabilities fixed": discovery and remediation are different things, and Anthropic published discovery counts, not fix or regression rates. Second, do not read "continuous scanning" as "real-time scanning": the official wording is regular rescanning of changes based on risk and complexity, not an instant full rescan on every commit, and the baseline scan itself can take minutes to hours depending on repository size. Third, do not mistake agent scanning's flexibility for a determinism guarantee: two scans of the same code can differ, which makes it suitable for discovery and tracking, not as a standalone pass-or-fail merge gate. Keep those three lines, and the value of this update is clear: it brings security state closer to the true state of the code. Closer is not identical, and the final judgment still belongs to people.