Machine speed broke the response clock. Hiring more analysts will not fix it

This article is part of our Opinions section, where we invite industry professionals to share their views on the most pressing technology questions of our time.

Give detection its due. Over the last decade, the industry got genuinely good at seeing things. Dwell times fell. Telemetry improved. Managed detection put trained eyes on environments that previously had none, and many organisations are alive today because an analyst spotted something at two in the morning.

None of that is in dispute. What is in dispute is whether any of it still arrives in time.

Because the thing being detected has changed shape, it no longer takes weeks of patient lateral movement by a human operator who sleeps, makes mistakes, and leaves gaps you can catch him in. It takes minutes, and it does not sleep.

The clock we optimised is the wrong clock

Every response metric in common use measures the distance between two events: the attacker doing something, and you noticing. Mean time to detect. Mean time to respond. Mean time to contain. All of them assume the interesting part of the attack is still happening when the clock stops.

That assumption held when the attacker was a person. It does not hold against software.

Sysdig’s Threat Research Team documented JADEPUFFER in July 2026, the first ransomware operation run end-to-end by an AI agent rather than a human crew. The detail worth your attention is not that an agent can do this. It is what the agent’s own logs recorded. Before the destructive payload ran, the high-value data was already staged on an external server. The theft was finished. The part your tooling was watching for had not started yet.

Read that sequence again, because it inverts the entire premise of response. By the time the incident looked like an incident, the only thing left to contain was the evidence.

Your best response time is still too slow, and that is not your team’s fault

Here is where the conversation usually goes wrong. Somebody looks at these numbers and concludes the security team is too slow, which is both unkind and untrue.

Work out the arithmetic honestly. Suppose you run a genuinely excellent operation. An alert fires and a human sees it in five minutes, which almost nobody achieves. Triage takes ten. Escalation and a containment decision take fifteen more. That is thirty minutes from first signal to first action, and thirty minutes would have been a career-defining performance in 2018.

An autonomous agent enumerates, stages and exfiltrates inside that window. It does not queue behind other tickets. It does not hand off at shift change. It runs at the speed of the API it is calling.

You cannot hire your way to zero. There is no headcount number, no follow-the-sun rota and no amount of tooling that closes a gap whose floor is set by human reaction time, against an adversary that has removed humans from its side of the equation.

The market can already see this coming

This is not a fringe position. A 2026 Dark Reading poll found that 48% of security professionals now rank agentic AI as the top attack vector for the year. Darktrace’s State of AI Cybersecurity 2026 report put the share of security professionals concerned about the impact of AI agents on their organisations at 92%. Industry surveys throughout the year have repeatedly found that roughly two-thirds of security leaders lack confidence in their ability to detect attacks driven by AI at all.

Gartner expects 40% of enterprise applications to embed task-specific AI agents by the end of 2026, up from under 5% in 2025. That is the defensive surface expanding at the same moment the offensive tempo increases.

So, the profession has already worked out that something is wrong. What it has not done is change what it buys, because the reflex when detection underperforms is to buy faster detection.

Faster detection is a rounding error on a finished attack

The honest counterargument deserves a hearing, and it is this: detection is not supposed to prevent everything; it is supposed to reduce impact, and reduced impact is real value. Fair. An organisation that finds an intrusion on day one is in a materially better position than one that finds it on day ninety.

But notice what that argument concedes. It accepts that the loss has already occurred and is now arguing about the size of it. That is a reasonable thing to optimise as a secondary objective. It is a strange thing to build a security strategy around as the primary one.

And against machine speed, the impact reduction shrinks. If the attack completes in four minutes, the difference between detecting it in twelve minutes and detecting it in forty is nothing that shows up on a balance sheet. You are paying a premium to learn about the same loss slightly sooner.

Stop measuring how fast you saw it. Start measuring what never ran.

The reframe is uncomfortable because it makes a decade of investment look misdirected, and that is not quite true either. Detection still matters for the slow attacks, the insider cases, the misconfigurations, the long tail of human-driven intrusion that has not gone anywhere.

What has to change is which clock you treat as the primary one.

A few concrete moves that do not require ripping anything out:

• Split your metrics. Report what your controls stopped before execution as a separate number from what you detected after it. Most organisations cannot produce the first number today, which is itself the finding.
• Run one tabletop where the exercise starts with the data already gone. No encryption, no ransom note, no containment phase. Just a regulator’s letter and a leak site listing. Watch how quickly the plan runs out of moves.
• Ask your suppliers what their control does when nobody is watching the console. Anything whose answer begins with an alert is asking a human to close the gap that human speed created.
• Stop treating response time improvements as risk reduction in board reporting. They are loss mitigation. Label them accurately, and the priorities reorder themselves.

The industry spent ten years building a faster fire brigade, and the fire got faster than the trucks. You do not fix that by hiring more drivers.

You fix it by making fewer things flammable.

More from our Opinions section

• Your AI projects will stall without these data partnerships
• The subscription blind spot
• The AI reality check: The real challenge is governing complexity