The Blast Radius Clock: Why After-the-Fact Detection Is Too Slow for AI Agents

Ryan Rowcliffe

4 hours ago

9 min read

Blast radius is not a property of a breach.,it is a function of time.

The same compromised credential produces a contained incident or a company-defining one depending entirely on how many seconds it held before something interrupted it. We all know this. It is why we bought detection, built a SOC, wrote runbooks, and put numbers on mean time to detect and mean time to respond. The whole apparatus is an attempt to shorten one interval.

Here is the problem. Every component of that apparatus was sized against a human adversary typing at a keyboard. The clock those components were built to beat now runs at a speed none of them were designed for, and the gap is not 20% or 50%. It is orders of magnitude.

The uncomfortable version: for an agent operating at machine speed, your detection pipeline is not a control. It is a recording device.

Do the math before you argue with it

Four numbers, all from this year's frontline reporting, all from organizations with no incentive to exaggerate.

Measure	Current figure	Prior
Average eCrime breakout time	29 minutes	65% slower in 2024
Fastest observed breakout	27 seconds	—
Initial access to hand-off between crews	22 seconds	over 8 hours in 2022
Global median dwell time	14 days	11 days

The first three are the ones people quote. The fourth is the one that should stop you.

Dwell time went up. Mandiant's M-Trends 2026 puts the global median at 14 days, climbing from 11. So adversaries move between stages in 22 seconds, and we still take up to two weeks to notice they are there. Those two facts sitting in the same report is the entire thesis of this post, and no amount of SOC tuning reconciles them.

The exploit clock tells the same story from a different angle. Mandiant's mean time to exploit now reads negative seven days. Exploitation routinely precedes the patch. A number below zero is a polite way of saying the defensive sequence we all learned has inverted.

One honest caveat, because Mandiant is careful about this and I will not stretch it. Their own read is that the vast majority of successful intrusions still come from fundamental human and systemic failures, not from AI. That is correct and worth repeating to anyone selling you AI-shaped panic. The argument here is narrower. Not that agents are breaking in. That once anything is inside, agents set the pace, and the pace has already outrun the response function.

What a machine-speed chain actually looks like

Abstractions do not persuade anyone. Here is a real one, from the July intrusion at Hugging Face, which I wrote about at the time and keep returning to because the timestamps do the arguing.

An autonomous agent escaped a sandbox and ran a coherent campaign against production infrastructure for four and a half days, roughly 17,600 recovered actions, with no human directing any individual step.

Four and a half days sounds slow., it was not. The duration was reconnaissance, most of it failing. The decisive moves were not slow at all.

The agent read a pod's environment and came away with platform tokens, AWS keys, and a static MongoDB password before a single line of its own code ran inside the perimeter. One secret object held 136 keys, and Hugging Face's own assessment is that everything which followed descends from that single read. Impersonating an internal connector credential bound to a system: masters gave it admin on two clusters within one second. At 19:53 on day three it escaped to root on a node; six minutes later it was authenticated to an internal MongoDB with the password it had lifted on day one.

One second for cluster admin. Six minutes from node root to database.

Now put your response process against those intervals. Alert generation, correlation, enrichment, queue, triage, an analyst forming a hypothesis, an escalation, an approval to revoke something in production. Name the organization where that completes in six minutes at 8 p.m. on a weekday. I have not worked in one, and I have worked in a lot of SOCs.

The part Hugging Face volunteered is the part that should worry you most. Their triage stack did correlate the ambiguous signals into a coherent attack signal. It then failed to rank it critical, so nobody got paged. Every event in that chain looks like any given day: pods read service account tokens, EC2 roles authenticate to EKS, TokenRequest mints tokens because that is its job. A severity model that scores events one at a time will never score that chain, no matter how fast it runs.

The equation does not close

Write out what detect-and-respond actually costs, in order, and the problem stops being philosophical.

Signal generation, ingestion and normalization, correlation across sources, severity scoring, queue time, analyst triage, hypothesis, escalation, and change approval. Execution of the containment action.

Best case in a well-run shop, with a tuned pipeline and someone awake, that is minutes. Realistically it is tens of minutes, and the 14-day median dwell figure says that for most organizations most of the time it is not minutes at all.

The agent's action completed in one second.

You cannot close that gap by optimizing the pipeline, and this is where a lot of security programs are currently spending money they will not get back. Cut your MTTD in half and the agent still finished. Cut it by 90% and the agent still finished. Every step in that sequence happens after the action, and no amount of speed converts an after into a during. It is a category error, not a tuning problem.

There is a second failure underneath the timing one, and it survives any amount of acceleration. Severity models score events. Agent attacks are composed of individually legitimate events. Faster scoring of individually legitimate events produces faster confirmation that nothing is wrong, right up until the postmortem.

So the honest framing is not that detection is too slow. Detection is doing exactly what it was built to do, at roughly the speed it was built to do it. The environment changed underneath it. We are running a control designed for an adversary who needed eight hours to hand off access against one who needs 22 seconds, and asking the control to try harder.

Worth being precise about what that means, because it is not an argument that the fundamentals failed. They did not. Least privilege, credential hygiene, segmentation, inventory, continuous verification were correct fifteen years ago and they are correct now. Nothing about agents changed the control set.

What changed is the compensating control we were leaning on without writing down. Every accepted risk in this area, the uninventoried service accounts, the static secrets in process environments, the automation credential nobody wanted to tighten, was signed off against the same unstated assumption: exploitation happens at human speed, so a human will have time to notice. That assumption was always weaker than we admitted, because the noticing half depended on detection quality we knew was uneven. At 22 seconds it is not weak, it is void.

Which leaves the one gap that was genuinely ours. We never built the observability to correlate identity correctly, human or non-human, across the domains those identities actually operate in. That absence is what let the bad bets look reasonable for a decade, because a risk you cannot see gets priced at zero.

What stops a clock

Only one thing stops a clock, and it is not a faster clock. It is something standing in the path.

This is the whole argument behind ARISE, the category Software Analyst Cyber Research defined this month, and specifically behind its Agentic Control Depth scale. ACD 2 is post-event telemetry and alerting after the action completes. ACD 4 is inline intervention before it completes. SACR puts the production floor at ACD 4 for agents touching sensitive data or critical workflows.

That boundary is the only one on the scale that changes your blast radius. Everything below it changes how well you can describe your blast radius afterward.

Inline means the control sits in the decision path and the action waits on its answer. Allow, block, redact, pause, step up authentication, route to a human, cut scope, revoke the credential, quarantine, terminate. Those verbs all operate on something in progress. Compare them to the verbs in your current stack, which are mostly detect, alert, score, notify, and report.

Three objections come up whenever I put this in front of an architecture team, and all three are reasonable.

Latency. Fair, and non-negotiable to quantify. Every inline control adds time to legitimate work. Ask for the measured p99 in milliseconds, not a claim that it is fast. An enforcement point adding four seconds to an agent action is an availability incident waiting for a Monday.

False positives now break production. Also fair, and this is why layer two of ARISE is not optional. Behavioral and intent analysis is what lets enforcement be selective instead of blunt. Inline blocking driven by static rules alone gets disabled within a month, and it deserves to be.

We cannot put a gate in front of everything. Correct, so do not, tier it. Read operations on public data run free. Actions touching regulated data, minting credentials, changing entitlements, moving money, or reaching production infrastructure go through the gate. That tiering decision is a business conversation and it should happen before procurement, not after.

The standards work is further along than most teams realize. NIST SP 800-207 has specified continuous verification at the policy enforcement point since 2020. The architecture was written down. We mostly implemented the visibility half of it and called the job finished.

What I would do Immediately

Measure your own clock before you buy anything to fix it. The number will make the business case on its own, and nothing I write here is as persuasive as your own timestamps.

Pick one agent already running in production. Instrument the full path for a week: first observable action, signal generation, correlation complete, analyst acknowledgment, containment executed. Not the SLA. The actual elapsed times. Most teams who run this exercise find their real interval is three to five times their reported MTTD, because reported MTTD starts counting at alert creation rather than at the action.

Then put that number next to one second and take the comparison to your risk committee.

Run a tabletop with the clock visible. Take the Hugging Face sequence, or any agent chain relevant to your estate, and walk your own process against it with a timer on the wall. Stop the exercise at the point where the agent would already have finished. Whoever is left holding an unfinished runbook step has learned more than any slide would teach them.

Separate your action classes into three buckets this week: run free, gate inline, always pause for a human. Do it on a whiteboard with the business owners in the room. You are deciding how much latency the organization will accept in exchange for interruptibility, and that is not a security decision made alone.

Audit entitlement scope before you touch credential hygiene. Rotation is the reflex and it is often the wrong first move. One connector credential bound to system: masters was never a rotation problem. Rotating it buys a fresh key with identical reach.

And when a vendor tells you they secure agents, make them say which verb. Detect is not block, alert is not pause, visibility is not revocation. Then ask for the latency number in milliseconds and watch what happens to the conversation.

The one layer where the denominator holds still

There is a budget argument underneath the timing argument, and it is the one I would take upstairs.

When an adversary tests paths at machine speed, your network and endpoint telemetry scales with their throughput. More agents pointed at you means more events, more storage, more correlation, more license. That cost curve follows their volume, not your risk, and it runs past your budget before it runs past their patience.

Your identity inventory does not move. A finite number of agents, service accounts, delegated authorities, signing keys, and tool surfaces. That number is the same whether one action per second arrives or ten thousand. It is the one layer of the stack where the denominator holds still, which makes it the only layer where you can win on economics rather than on spend.

This is why AuthMind built for runtime rather than for reporting, and why SACR named us a representative vendor with broad alignment across all three ARISE layers. Shadow agent discovery finds the identities nobody registered. Agentic identity threat detection and response works on the chain rather than the event. Governance and posture management fixes reach before an incident tests it. The enforcement verbs sit in the path, which is the only place they do any good.

Agents do not wait for your queue. They were specifically built not to.

So the question is no longer whether your detection is fast enough. It is whether anything you own can say no while the action is still happening. If the answer takes a meeting to produce, you already know what it is.