The clock is now hours. Your patch process is weeks

To patch faster without breaking change management, make the controls fast instead of removing them. Most of a patch's elapsed time is not spent writing the fix. It is spent waiting: for a review board, for someone to assemble evidence, for a deploy window. A policy gate that runs on every fix in seconds, one named human approval, and an audit record written as a side effect remove the waiting and keep the control.

That is the whole argument. The rest of this post is why it became urgent in 2026, and what it looks like when you build it.

The interval that collapsed

In June 2026, Anthropic's red team published a measurement worth reading slowly. They gave Claude Mythos Preview 18 security patches for SpiderMonkey, the JavaScript engine inside Firefox, and asked it to work backwards from each fix to an exploit. It produced 8 working code-execution exploits. The first arrived within an hour of Mozilla issuing the patch — 18 days before the patched Firefox release shipped to users.

They ran the same experiment against 21 Windows kernel vulnerabilities. The model produced proof-of-concept crashes for 18 of them within six hours, the first in 31 minutes, and built 8 full privilege-escalation chains for about $15,700 in total.

Their conclusion was one sentence: "N-day has become dangerously misleading. N-hour is closer to the reality we now operate in."

The discovery side moved too. A month into Project Glasswing, Anthropic and roughly 50 partners had used the same model to find more than ten thousand high- or critical-severity vulnerabilities. Of the 530 that Anthropic itself had reported to open-source maintainers, 75 were patched at the time of the update. Anthropic's own summary of where that leaves the industry is the thesis of this post, in their words:

"Progress on software security used to be limited by how quickly we could find new vulnerabilities. Now it's limited by how quickly we can verify, disclose, and patch the large numbers of vulnerabilities found by AI."

Finding is becoming a commodity. Shipping the fix safely is the bottleneck.

Meanwhile, on the defending side

Verizon's 2026 Data Breach Investigations Report, drawn from vulnerability data across more than 13,000 organizations, measured the other half of the race. Three findings, read together:

• Exploitation is now the most common way breaches start — 31% of known initial access vectors, ahead of credential abuse, the previous leader, at 13%.
• The median time to fully patch a known-exploited vulnerability rose to 43 days, from 32 the year before.
• Only 26% of known-exploited vulnerabilities were fully remediated, down from 38%.

Elapsed time, in days

The exploit is measured in hours. The fix is measured in weeks.

• Patch published → first working exploit

  under 1 hour

  Firefox SpiderMonkey patches, Claude Mythos Preview

• Patch published → patched Firefox release

  18 days

  The same patch, reaching users through the vendor's release

• Detection → full remediation

  43 days

  Median, known-exploited vulnerabilities, 13,000+ organizations

015d30d45d

Not one timeline. The first two rows are measured from the moment a patch was published; the third from the moment an organization’s scanner found the vulnerability. They are different vulnerabilities. What they share is the shape of the gap.

Anthropic, Measuring LLMs' impact on N-day exploits (2026-06-08); Verizon, 2026 Data Breach Investigations Report.

The honest caveats, because this post does not get to skip them. Verizon's data covers vulnerabilities on CISA's Known Exploited list found by scanners, which is mostly infrastructure and third-party software rather than your own application code. Part of the slowdown is volume: the median organization had 16 of those to patch, up from 11. And Anthropic's numbers measure what a restricted-access model can do in a research setting, not attacks observed in the wild. The two sources measure different vulnerabilities from different starting lines.

But they describe the same shape. On one side of the race, the interval is shrinking toward hours. On the other, it is growing, and it was already measured in weeks.

The obvious fix is the wrong one

When the clock gets this short, the tempting answer is to take the controls out of the way. Skip the change board for security fixes. Let the scanner open the pull request and let the pipeline merge it. Let an agent ship the patch.

It fails for two reasons, and neither is sentimental.

A rushed patch is still a change. Change control exists because changes are how production breaks. A dependency bump that pulls in an incompatible minor version, a base-image update that drops a library the service quietly needed, a hotfix rolled out to every cluster at once — each of those trades a vulnerability for an outage. Under time pressure you make more of them, not fewer.

Somebody still has to sign for it. After the incident, the auditor and the regulator ask the same question they always ask: who approved this change, and against what rules? "The pipeline decided" is not an answer anyone in a regulated business can give. Speed that deletes the approval does not remove the accountability. It just leaves it unassigned until something goes wrong.

Where the weeks actually go

Look at a typical patch end to end and ask where the time is spent.

Writing the fix is usually the smallest part. A version bump is one line. A digest pin is one line. Even a real code fix is often hours of work, not weeks.

The weeks are spent waiting. For a ticket to be triaged. For the change board that meets on a schedule. For someone to assemble the evidence that the change was reviewed, tested, and approved. For the next deploy window. None of that is judgment. It is the record of judgment, assembled by hand, and the calendar overhead of getting the right people in a room to produce it.

Now list what a change board is actually checking:

1. Is this change what it claims to be?
2. Does it meet our rules — pinned images, required scans, approvals for production, whatever your organization has written down?
3. Who approved it?
4. Is there a record an auditor can read later?

Only the third one needs a person. The second can be code that runs on every change in seconds and never skips one. The first and fourth can be properties of the path the change travels, rather than paperwork assembled after it.

That is the reframe: governance is the speed story, not the safety tax. A control that evaluates every proposal in seconds is faster than a meeting, and stricter, because it does not get tired on the fortieth change of the week.

What this looks like, and how much of it is live

TruStacks is AI delivery governance — the control layer between the agents that write your software and the systems that run it. Here is the remediation path as it runs on the hosted Beta today:

1. A finding arrives from whatever produced it — posted to the API, or uploaded as SARIF from the scanner you already run. We are not a scanner and do not intend to become one. The source is a field on the record, not an integration you are locked into.
2. A person triages it, or dismisses it. Both are recorded.
3. The crew opens a proposal. For a finding on a connected service, the DevOps Engineer re-plans that service's delivery surface — pipeline, Dockerfile, Helm chart, Argo manifest — as a pull request against your platform repository.
4. The constitution decides before anyone looks. Every proposal is evaluated against the constitution before a pull request exists. A denied proposal never becomes a pull request, and an evaluator that fails counts as a deny.
5. A named human merges. There is no configuration that changes this.
6. Your ArgoCD deploys it. The runner watches the Argo Application read-only and marks the finding validated only when it is Synced and Healthy at the merged commit. We observe your deployment; we never operate it.
7. Every step is on the record — each transition with who or what moved it, and when.

The same rule covers fixes that land in application code. When a developer, or their coding agent, merges a fix to a connected service's main branch and your CI builds the image, TruStacks opens the new image tag as an ordinary proposal. Even which version is running in production changes only through the gate and a human approval.

And here is what is not live yet, because a post about governance does not get to blur that line:

• The finding is the trigger and the record, not yet the brief. Today the crew re-plans the affected service; it is not yet handed the finding's own details to write a fix against that finding specifically. Doing so is the next step.
• A failed deploy does not yet trigger a corrected proposal. If the deployment comes up degraded, the finding drops back to fix proposed instead of being marked done, and nothing ships on its own. Re-proposing automatically, with the failure in hand, is the direction. When it lands, it will re-propose. It will not merge.
• Application-code fixes are written by your people or their tools. TruStacks governs how a fix reaches production; it does not write your application code.

The trade, stated plainly

The attacker's interval is now measured in hours, and it is getting shorter. Yours is measured in weeks, and the best available data says it is getting longer. You will not close that gap by finding vulnerabilities faster; finding is the part that just became cheap. You close it by shipping fixes faster, through a path that is still accountable at the end.

That path does not need fewer controls. It needs controls that run at machine speed, a person at the one step that requires a person, and a record nobody has to assemble by hand.

Agents propose. Policy decides. Humans approve. The approval stays. The waiting goes.

The exploit-speed figures are from Anthropic's Measuring LLMs' impact on N-day exploits (June 2026). The discovery and patch-backlog figures, and the quoted summary, are from Anthropic's Project Glasswing: An initial update (May 2026). The remediation and initial-access figures are from Verizon's 2026 Data Breach Investigations Report, measured across more than 13,000 organizations. Every figure here is in our source registry with its sample and caveats attached.