Machine Speed Is the Wrong Target

Tue, 08 Sep 2026 00:00:00 +0000

Part 2 of an ongoing series on where AI lets me down.

Sit through enough vendor briefings this year and you’ll hear the same pitch. Attackers have AI now, so they move at “machine speed”. A human responder can’t keep up with a machine, therefore your response has to be a machine too. Autonomous SOC, agentic containment, closed-loop remediation with no human in the middle. The logic sounds airtight: machine versus machine, and the side still typing in a console loses.

I want to pull on that thread, because I think the conclusion is wrong. Two incidents really show my work here.

Maersk didn’t lose to a fast attacker

On the 27th of June 2017, NotPetya went off inside Maersk. There was no AI anywhere near it. It was a worm: stolen Ukrainian accounting software as the delivery, EternalBlue to get going and pass-the-hash on harvested credentials to spread sideways and up into the servers and domain controllers. Within a couple of hours it had reached every domain-joined Windows machine on the planet, some sixty thousand people’s worth of laptops, desktops, virtual machines and servers, all at once.¹ Every domain controller went down together; Maersk had a copy of Active Directory left to rebuild from only through sheer luck, and the first controller they brought back was running on a Surface Pro 4. The core came back in about ten days. The long tail ran for weeks and months, and the bill was north of three hundred million US dollars.²

Here’s the part the “machine speed” crowd skips. No response loop, however fast, was ever going to win that race. By the time the first alert fired, the network was already gone. You cannot out-click a self-propagating worm that owns your whole environment before your on-call has finished reading the page. So the idea that Maersk’s problem was slow human response, and that the fix is a faster automated response, gets the incident exactly backwards.

What actually would have helped Maersk was decided long before the 27th of June. Network segmentation so a worm can’t touch every subnet. Tiered administration so one set of harvested domain admin credentials doesn’t unlock the planet. Patching the EternalBlue class out of existence. Backups that survive the thing designed to destroy them. That’s architecture, not reflexes. Gavin Ashton, one of the identity engineers who lived through it, wrote afterward that the fundamental risk they’d failed to address was management of privileged access. Segmentation would have slowed the spread and patching would have helped, but what turned a bad day into a near-death event was reusable privileged credentials on a flat network. Not response speed. Attackers hit “machine speed” eight years ago with a worm and some stolen passwords, and the answer then was the same as the answer now: build somewhere that a fast attacker can’t run.

The AI attacker we’ve actually watched was loud, not fast

The other half of the pitch is that the AI attacker is a new kind of adversary, so fast and so capable that only another AI can meet it. When you point one at a real target, that isn’t what you see.

The Hugging Face intrusion in July 2026 is the cleanest example I have.³ It was driven end to end by an autonomous AI agent, thousands of individual actions fired across throwaway sandboxes over a single weekend. That volume sounds terrifying until you look at what it bought the attacker. The meaningful progress, the actual movement toward anything that mattered, wasn’t ahead of what a skilled human would have managed in the same window. The agent got stuck where people get stuck. It just churned through a thousand attempts doing it, where a human would have tried a handful and thought harder between each one.

And all that churn is noise. The intrusion was surfaced by anomaly detection precisely because an autonomous agent hammering the environment looks nothing like normal traffic. This is good news dressed up as a threat. The adversary the marketing tells us to fear moved at roughly human pace on the things that count and lit up the monitoring like a Christmas tree doing it. When I architect environments, I build them to increase the number of actions an attacker has to take to move closer to completing the mission (when I can’t prevent the attack entirely). I want them to make noise. Noise is what detection is built to catch.

Hugging Face’s own writeup draws the opposite lesson, that you now need AI-driven defence to match AI-driven offence. I’d push back on that. The incident is evidence the offence isn’t the flash of light we’re told to fear, and that its defining feature, the thing that gave it away, was volume a human never would have generated. The takeaway isn’t “buy a faster gun”. It’s that the attacker handed you the signal for free.

Automating a bad decision just makes you wrong faster

There’s a quieter problem with machine-speed response, and I wrote about its cousin in part one. An AI told to explain a blob of obfuscated PowerShell confidently read out the harmless echo at the end of the chain and missed the four layers of packing around it. An analyst closed the alert. If you take that same confident-but-wrong engine and give it the authority to act on production without a human sanity-check, you haven’t solved the speed problem. You’ve built a system that isolates the wrong host, blocks the wrong account, or closes the real intrusion, and does it before anyone can catch the mistake. You’ll definitely have incidents, but they’ll be self-inflicted availability incidents, and you won’t see the attacker at all.

Response is where judgement lives. It’s the part of the job where you decide whether the thing in front of you is the whole intrusion or just the edge of what you’ve looked at, and that is precisely the call AI is worst at making. Speeding it up by taking the human out is optimising the one place you can least afford to.

Get the basics right

Stop chasing machine-speed response. Speed is the attacker’s game, and both of these incidents say the same thing when you line them up. Maersk shows the real catastrophe came from architecture, and no responder was going to react their way out of it. Hugging Face shows today’s AI attacker is a noisy junior, not the flash of light we’re being sold. Neither one is an argument for a faster trigger finger.

The work that pays off is making the environment defensible enough that the attacker, human or machine, is slowed to a pace a thinking person can beat, or the attack class is gone entirely. Segment the network so nothing moves laterally for free. Kill reusable admin credentials so credential theft doesn’t hand over the estate. Patch the exploitable class out, don’t play whack-a-mole with instances of it. Phishing-resistant auth so the front door stops being a soft target. Immutable, tested backups so a NotPetya is a bad fortnight instead of an extinction event. Every one of those buys your responders the one thing response actually needs, which is time to think.

We don’t need to move at machine speed. We need to build places where the attacker doesn’t get to either, and where the blast radius is small enough that a human, thinking clearly, wins. Make them play our game: friction, defensibility, and time. That’s a race worth being in.

Gavin Ashton, Maersk, me & notPetya, a firsthand account by one of the engineers on the response. The “every domain-joined Windows machine on the planet”, the ~60,000 affected staff, the Surface Pro 4 domain controller and the privileged-access thesis are his. ↩︎
The roughly ten-day core rebuild and the losses north of three hundred million US dollars are from Andy Greenberg’s The Untold Story of NotPetya, the Most Devastating Cyberattack in History (WIRED, 2018), later expanded in his book Sandworm, and from Maersk chair Jim Hagemann Snabe’s remarks at Davos 2018. ↩︎
Hugging Face’s own account, Security incident: July 2026, and OpenAI’s follow-up, The Hugging Face incident and the road ahead. Both are worth reading; note that Hugging Face reach the “match AI offence with AI defence” conclusion I argue against here. ↩︎

Case Study: Intrusion Response (QU 2026)

Mon, 31 Aug 2026 00:00:00 +0000

Living through the fun together

I gave this talk at Queensland University on the 31st of August, 2026. Rather than picking apart a single host, it zooms out to the thing that’s not discussed as often: leading a whole intrusion response. The slides are at the bottom of this post.

The session walks through the compromise of a fictional custody business, The Secrets Group, from the first detection to the point where the business has to start telling people. The technical narrative is deliberately messy, the way real ones are. A detection fires on a service account beaconing out of a file server. From there the job is to work outward in both directions: back towards patient zero (a phished workstation, some recon, an Invoke-Kerberoast), and forward through lateral movement into a malicious GPO, a CitrixBleed exploit, credential theft, and tampering with a customer’s contract data. There’s a sleeper on a print server that only wakes up a month later, which is the sort of thing that gets you re-compromised right after you think you’re done.

The parts I care most about aren’t the individual findings. They’re the questions that good tech leads are always thinking about:

How do you know you’ve found the edge of the intrusion, rather than just the edge of what you’ve looked at so far?
How do you match tasks to the responders you have, and expand the team mid-incident without drowning the new people?
How do you build one shared understanding of the incident, then go hunting for the gaps in that narrative on purpose?
What does the business actually need from you, and when? Leadership, the board, legal, regulators, customer notification, PR, law enforcement all want different things on different clocks.

I also spend some time on where AI genuinely helps in this work today and where it falls over. It’s a good junior analyst for explaining one artefact or drafting the write-up. It’s bad at holding forty hosts in its head, catching the genuinely novel, and being someone who can sign their name to “this is what happened.” Leadership want people to hold accountable, and that doesn’t change.

If you’re on the business side, the aim is to leave with a realistic picture of what technical response involves so you can set expectations when an incident kicks off. If you’re technical, the aim is the reverse: a better feel for the business concerns you’ll be answering to while you work.

There’s a bonus section on Kerberoasting for if I go full kiwi and burn through my planned content too fast.

Further reading on the model that shaped a lot of this thinking, this is a free eBook that’ll be coming out in September. I’ve been lucky enough to get an advance copy, and it’s excellent: dynamicincidentresponse.com.

Slides (PDF)