e— title: “The Evolution of Containment” date: 2026-10-01 draft: false tags: [“Incident Response”, “Musings”]

Containment used to come last

For most of my career, containment was the step you took after investigation. That was the order of operations drilled into me in every training, conference, and book I’d ever come across. You detect, you investigate, you scope, and only once you understand the intrusion do you contain it. The reasoning was sound: if you don’t know where the attacker is, how they got in, and how they’re holding on, then any containment action you take is a guess. Pull the wrong plug and you tip the attacker off while they’re still sitting on three other hosts you haven’t found yet. Containment without a thorough investigation was closer to theatre.

Let’s get the contention out of the way. For the purposes of this musing, I define containment as stopping the intrusion from getting worse. That’s it. You’re not evicting the attacker (that’s remediation / eradication), you’re not fixing the root cause, you’re drawing a line and saying “no further”. Everything the attacker has, they keep for now. What they don’t have yet, they don’t get.

Back then (god I feel old), containment was a blunt instrument. Containing a host meant someone physically walking over and pulling the power cord, or yanking the network cable out of the back of the machine. Containing a segment meant getting a network engineer to reconfigure switches so VLANs couldn’t talk to each other, or dropping firewall rules in to sever one chunk of a network from another. These were big, disruptive, slow actions. You didn’t do them lightly, and you certainly didn’t do them before you were confident in your investigative findings. You’d take down production, you’d alert the attacker, or both. Investigate first, contain once, contain hard.

Containment is now two different questions

Somewhere along the way, “containment” stopped being one thing. These days when I say it, I’m usually talking about one of two very different goals. They both achieve the same end, protect the business, but they’re wicked subjective to the incident your investigating.

The first is containing the attacker to the compromised environment. You’ve got them in a part of the network, and the job is to stop the spread. Keep them where they are, don’t let them move laterally, don’t let them reach the crown jewels. This is the classic “ring-fence the fire” model.

The second is containing the attacker out of an environment. This is about what you’re protecting, not where the attacker currently is. Think of a nice big international bank. We generally don’t care very much if an attacker compromises the HR system, or a pile of user endpoints — those hurt, but they’re survivable. What I cannot allow, under any circumstances, is access to the SWIFT network. So containment here isn’t about chasing the attacker around; it’s about hardening the boundary around the thing that would end the company, and making sure that whatever happens elsewhere, that stays sealed.

These two framings pull in different directions. Containing the attacker to somewhere is reactive and follows the intrusion. Containing them out of somewhere is proactive and follows your risk model. Most real incidents need both at once, and being clear about which one you’re doing in any given action stops a lot of confused decision-making in the war room.

EDR made containment surgical

The other thing that’s changed, and changed hard, is how easy containment has become. Modern EDR has turned a host-level containment action from “send someone to the datacentre with a plan” into a button. Click, and the agent cuts that machine off from the network while leaving your tooling able to reach in and keep investigating. No power cord, no network engineer, no VLAN surgery. You can isolate one endpoint (or ten, or a hundred) out of fifty thousand without touching anything else, and you can un-isolate it just as fast if you were wrong.

That precision quietly breaks the old “investigate fully, then contain” model, because it removes the thing that made early containment dangerous. The reason you waited was that containment was blunt and expensive to get wrong. When containing a single host is cheap, reversible, and doesn’t tip your hand across the rest of the estate, the cost of acting early collapses.

Faster, incomplete, iterative containment usually wins now

Attackers move faster than they used to — a lot faster. In talking to red teamers, their estimate for going from initial compromise to domain admin is ~3 hours; earlier this year, Crowdstrike reported their earliest yet observed breakout time (moving from a single host intrusion to multiple-host via lateral movement) of 35 seconds - that’s terrifying! The window between initial access and the attacker reaching something that actually matters has compressed to the point where “finish the investigation first” is a luxury you often can’t afford. If I wait until I fully understand the intrusion before I contain anything, there’s a decent chance the attacker has achieved their objective by the time I’m ready to act.

So the better play, more often than not, is to contain fast and contain incompletely, then iterate as the investigation catches up. Isolate the host you’re confident about now, even though you know there are probably others you haven’t found. Seal the boundary around the thing you can’t lose now, before you’ve scoped the full picture. Then keep investigating, and contain the next thing, and the next. You accept that your first containment action won’t be complete, because an incomplete line drawn early beats a perfect line drawn too late. The old world punished you for acting early; the new one punishes you for waiting.

I recently tried the old model during a red team exercise for giggles, and it went exactly how you’d expect - I couldn’t keep up, and the scoundrels completed their mission (but it was both nostalgic and fun, so i think I still win ;)). Iterative containment only works because containment got surgical. If my only tool were the power cord, iterating would mean repeatedly taking down production, and “contain early and often” would be reckless. Because my tools are precise and reversible, iterating is cheap, and the risk flips.

AI makes the sprawl worse

The pressure’s only going one way. AI lowers the cost of an attacker fanning out across an environment. Where a human operator would pick their next move carefully because their time is finite, an agent will try everything, everywhere, in parallel, without getting tired or bored. The intrusion doesn’t stay neat and linear; it sprawls.

The Hugging Face incident in July 2026 is the clearest example I’ve got.¹ An autonomous AI agent fired thousands of individual actions across throwaway sandboxes over a single weekend. I’ve argued elsewhere that this attacker was loud rather than genuinely fast on the things that mattered — and I stand by that — but the sheer volume cuts straight to the containment problem. When an attacker is touching that many things that quickly, the idea that you’ll fully scope the intrusion before you draw any lines is dead on arrival. Just like inmy little experiment, sprawl outruns the investigation. All the more reason to contain what you can as soon as you can, and let the picture fill in behind you.

Where this leaves me

Containment isn’t the last step anymore, and it isn’t one thing. It’s a question you ask continuously throughout an incident — am I keeping the attacker penned in, am I keeping them out of what I can’t lose — and it’s an action cheap enough now that you should take it early and often, correcting as you learn. The investigation and the containment run together instead of one after the other.

I spent years believing you earned the right to contain by investigating first. The tooling and the threat have both moved far enough that the belief no longer holds. Draw the line early, you can always move it.