Faster, Not Different

Faster, Not Different

By Ken Phelan
Posted in Infrastructure, Security, Support
On September 03, 2026

A few weeks ago I wrote a post called "It's Not the Model." The short version: frontier AI is finding vulnerabilities at industrial scale, the capability will land on every platform eventually, and the scarce resource isn't the model — it's the ability to absorb what the model finds.

The reactions came in two flavors. Half the room heard "the sky is falling." The other half said "the sky was always falling, why are we talking about it now?"

Both halves are wrong, and it's worth being precise about why. Because nothing about the attacks is different. Same ransomware, same phishing, same box that's been unpatched since the first Obama administration. What AI changes is the arithmetic: how fast the attack happens, and how many people it happens to.

Same game, faster clock

Think about what really changed. Vulnerabilities in your environment? Always there. Some of the flaws Mythos surfaced are decades old — they were sitting in production the whole time you were presenting your maturity slides. Security debt? Always there. The eventual breach? Inevitable.

But the clock speed changed. The gap between a vulnerability existing and finding that vulnerability used to be measured in years. The gap between found and weaponized used to be measured in months. AI compressed both, and it's still compressing.

Here's the way I'd put it to a CFO: your security debt didn't grow. The interest rate did.

For twenty years, the industry got away with a payment plan. Patch on your schedule, prioritize by CVSS score, let the low-severity stuff age in the backlog like wine. That worked because discovery was expensive and exploitation was artisanal. Attackers had backlogs too.

That grace period is what's ending. Not the game. The grace period.

Everyone's on the list

Speed is only half the arithmetic. The other half is scope.

Effective attacks used to require careful planning and technical proficiency. An attacker's time was scarce, so he picked targets the way a fisherman picks water — go where the money is. If you were small, boring, and unregulated, you had a kind of herd immunity. Not because you were secure— you simply weren't worth the effort. If we're being honest, half the mid-market's security posture has always been unprofitability.

AI ends that. When discovery is automated and exploitation is automated, the marginal cost of attacking one more company drops toward zero. And when attacking everyone costs about the same as attacking someone, target selection stops being a thing. The fisherman doesn't pick water anymore. He drains the lake.

So, in the near future, everyone gets attacked. Not everyone big. Not everyone regulated. Everyone. "Too small to bother with" was never a security strategy — it was a line item in the attacker's business model. The business model just changed.

Absorption is a rate, not a state

In the last post I called the scarce resource absorption capacity. I want to push on that, because I've noticed people hear "capacity" and think it's something you have. It isn't. It's something you do, at a speed.

Absorption is the full digestive tract: a finding comes in, somebody owns it within hours, it gets triaged against what's actually exploitable in your environment, a fix ships, the fix gets verified, and you can prove the whole chain to a regulator without a three-week archaeology project. That's one rep. Your absorption capacity is how many reps you can do per week, sustained, without heroics.

Most organizations have never measured this honestly. They measure vulnerability counts, which is like measuring your health by weighing your mail. The number that matters is the rate: findings metabolized per unit of time, versus findings arriving per unit of time.

And here's the uncomfortable math. The arrival rate is now set by machines, and it only goes up. Your metabolism is set by people, process, and politics — and it's roughly flat. If those two curves stay on their current paths, they cross. For a lot of firms, they already crossed and nobody's told the dinner table.

A customer pushed back on me here, and his objection deserves the floor. We can patch at any rate we want, he said. We're just going to break some things.

He's right, and it explains twenty years of behavior. Change control wasn't born of cowardice. It was born of scar tissue. For most of that time, indiscriminate patching caused more outages than cyber attacks did. Every CAB meeting, every maintenance window, every two-week soak test is the fossil record of self-inflicted downtime. Slow patching wasn't dysfunction. It was the correct answer to the actual math: the outage you'd cause was more likely, and more expensive, than the breach you were risking.

That equation had two sides, and AI just rewrote both. On the threat side, machine-speed discovery means the breach you're risking is no longer a lottery ticket — it's a schedule. On the outage side, the same machines can do what your change board never could: generate the test coverage, stage the canary, watch the telemetry, and roll it back before a human notices. The old trade was slow-and-stable versus fast-and-broken. The new trade is fast-and-verified versus slow-and-breached. Firms still running the old equation aren't being careful. They're being nostalgic.

The work isn't a tool purchase. It's boring, structural, and unglamorous: who owns triage, how fast a patch actually ships end to end, where the approval bottlenecks live, what you can automate without losing the audit trail. Nobody gets a keynote slot for fixing their change-approval board. It's still the whole ballgame.

Resilience is a skill

Now the part nobody wants in the deck.

Even if you do all of that — even if your metabolism is the best in your peer group — you're going to lose a battle at some point. The math is against you. You have to be right at machine speed, every day, across everything you run. The attacker has to be right once. When both sides get faster, that asymmetry doesn't shrink. It sharpens.

Here's how I think about it. Nobody gets through a boxing career without taking a punch. Taking one is in the contract. The skill that separates fighters from ex-fighters is what happens after it lands: you don't panic, you cover up, you clinch, you clear your head, and you're still standing at the bell. Getting hit is survivable. Getting hit for the first time, live, with no practice — that's the knockout.

Security has spent two decades selling itself as the art of not getting hit. Resilience is the art of taking the hit. Like any skill, it responds to practice and decays without it.

Ask yourself the sparring questions. Do you actually know your crown jewels — the handful of systems the business dies without — or is that list a slide from a BIA nobody's touched in three years? For those systems specifically: when did you last restore one (not just verifying that the backup job succeeded), at scale, under time pressure? And is the plan drilled, with named people who've run it, or is it a binder? Because the goal isn't recovering everything eventually. It's getting the systems that matter back in hours instead of days. Nobody wins the fight by healing every bruise. You protect the chin and stay on your feet.

Here's why I believe this. I was thanking a client the other day for his loyalty — small firm, not regulated, twenty-five years with us. He stopped me. You remember the ransomware? Several years back, everything encrypted, business dead in the water. He called it the worst professional day of his life. And then he told me that day is why he's still a client. Not the twenty-five years things went right. The one day everything went wrong, and what happened next.

Think about that. Twenty-five years of projects, upgrades, and clean audits, and the thing he remembers is the knockdown. Nobody's loyalty was ever earned by uptime. It gets earned on the bad day, when the punch lands and somebody in your corner knows exactly what to do.

One more detail. He wasn't big, wasn't regulated, wasn't anybody's idea of a target. He got hit anyway — back when getting hit at his size still took bad luck. The lake is draining. Soon it won't take luck at all.

The two-speed answer

So no, the game didn't change. The tempo did, and the guest list did. And tempo cuts both ways: the same acceleration raising the arrival rate of findings can raise your metabolism, if you point it inward.

Which leaves you with exactly two skills to build, and neither is picking a model. Get faster at absorbing what's coming. And get good at getting hit.

You're going to lose a battle. That was always true. The only question left is whether you've practiced losing it well.

Ken Phelan

Ken Phelan

Ken is one of Gotham’s founders and its Chief Technology Officer, responsible for all internal and external technology and consulting operations for the firm. A recognized authority on technology and operations, Ken has been widely quoted in the technical press, and is a frequent presenter at various technology conferences. Ken is the Chairman of the Wall Street Thin Client Advisory Council.