The useful number in IBM's 2026 breach report is 56%, not $6.04M

A mean computed over 602 organizations that had all already been breached is a conditional number ^[4]. It describes what the incidents in the sample cost, not the odds of joining the sample, and the Passwork team, which flagged the figure and sells a self-hosted secrets management platform, says as much: a vulnerable dependency or a leaked token in a repository is not a "$6 million bug", and IBM's numbers read better as directional benchmarks than as a risk calculator for one application ^[6][21].

The growth rate is the part with operational content. Divide a share of just over one in four by 1.56 and the previous year lands near 16%, about one in six ^[7]. That reading assumes the 56% applies to the share of malicious breaches, and the source reports the increase without saying whether the base is the share or the absolute count ^[8]. If it is the count, the share moved less and the volume moved more, which is a different capacity problem arriving at the same triage queue.

Underneath either reading sits the claim that frontier models can speed up vulnerability discovery and validation ^[9]. Passwork's inference from that is narrow and defensible: if attackers get faster on their half of the race, triage and remediation cannot stay on the schedule they used a few years ago, and a quarterly review becomes hard to justify for anything internet-facing ^[10].

Set that against where the agents actually are. About half of breached organizations reported AI agents in their SOCs ^[11], with threat hunting at 56% and response and containment at 54% ^[12], while vulnerability scanning and management sat at 18% ^[13]. That is a 38 point gap ^[14], threat hunting running more than three times as common as vulnerability work ^[15]. Both leading uses fire after something suspicious has happened; the 18% case is the one that sits in the delivery path, where exposure can be removed before anything is exploited ^[16].

What is left is unglamorous queue engineering: an inventory with a named owner for every exposed service, a separate lane for known-exploited vulnerabilities, remediation SLAs keyed to exploitability and exposure rather than severity alone, and verification that a fix reached production instead of counting a merged PR as remediation ^[17]. Compensating controls are the pressure valve when the upgrade will not deploy: disable the vulnerable feature, add a WAF rule, restrict a network path, put it behind a flag, or take the service off the public surface until it can be patched ^[18]. In CI, the gate rules should combine severity with exploitability, and every critical direct and transitive dependency needs an owner plus a current SBOM so a finding maps to the team that fixes it ^[20].

Passwork's statement of the objective is the sentence worth keeping: not patch everything immediately, but never let a critical finding enter a backlog with no owner and no next action ^[19]. That is a claim about arrival rates. If discovery accelerates while the service rate of the queue is set by a quarterly meeting, the backlog grows whatever the average incident costs, and $6.04M, roughly 20% above the implied global average of about $5.0M, says nothing about when yours clears ^[3][5][22].