When I built one of the earliest pentesting firms, back in the 1990s, a serious attack was a slow craft. It took skilled people days, sometimes weeks, to study a target, find the weaknesses, work out how to chain them together, and get in. The scarcity of that skill was, in a strange way, part of your defence. There weren’t many people who could do it, and it took them a long time to do it.
That world is gone, and it went quietly.
AI has changed the economics of an attack. What used to take a skilled operator days or weeks can increasingly be done in minutes. The work that was scarce and slow is becoming cheap and fast, and when the cost of attacking you falls, the number of people willing to try climbs. You are no longer tested occasionally, by the few. You are tested constantly, by the many, at a speed no human team was built to match. Verizon’s latest Data Breach Investigations Report (DBIR) found that 15 distinct attack techniques are now being accelerated by generative AI, with attackers using it to move faster at every stage, from spotting the gap to writing the exploit.
And this year the same report recorded a turning point. For the first time, exploiting a software vulnerability has overtaken stolen credentials, and now accounts for 31% of breaches. For years the story about initial access was that attackers logged in. Now they hack in, through a weakness someone already knew about.
Most organisations are meeting that world with a habit formed in the old one. They run the scan. They run the pentest. They work through the findings. And somewhere in that process, a feeling settles in that the job is done.
Think about that feeling, because it’s the most dangerous thing most cybersecurity leaders own.
Finding is not proving
For most of my career, the thing that haunted the testers I worked with wasn’t the single catastrophic vulnerability. It was the chain.
Real adversaries rarely need one devastating flaw. They take numerous small, forgettable weaknesses and string them into a single way in. An exposed endpoint here. A credential sitting where it shouldn’t. A misconfiguration nobody thought worth a ticket. Each one, on its own, is noise. Any competent scanner will list it, rank it (usually low), and move on. Chained together, used in the right order, they are a breach.
And here was our frustration, the one every pentester and red teamer will recognise. We could walk you down a path. That was the craft, and a good report showed exactly how we got in. What we couldn’t do was show you every path, or show them again next month once everything had changed. We tested a slice, in a window, and by the time you read the report we were describing history.
A report of findings is not a verdict. It never was. Any point-in-time test hands you a snapshot, and what you do with it is your decision. Whether to go live, whether to keep running, which risks to accept, all of that sits with you, and it’s decided on evidence that begins ageing the moment it’s written.
Which means the question the industry has spent decades answering, what might be wrong here, was never the right one. Finding is easy now. Scanners are cheap, dashboards are everywhere, and any team can list everything that might be wrong before lunch. What’s hard is proof. And proof doesn’t make you secure. It tells you whether you are, and gives you evidence of what an attacker can genuinely do with those weaknesses. And when you fix them, confirmation the risk is really gone. Most testing gives you that once, in a retest after the fix. What it doesn’t give you is the same confirmation after the next change, and the one after that.
That’s the shift.
Cybersecurity stopped being only a visibility problem some time ago. Visibility still matters, because you can’t defend what you can’t see, but it’s quietly become the easy part. The hard part is evidence. And most organisations have almost none.
The blind spot with a schedule
Here’s where that comfortable feeling becomes real exposure.
A test before release, or once a year, is a tripwire for the conscience. It makes everyone feel covered while the live environment drifts out from under them. And the moment testing stops, the proof starts ageing. Not over months, but from the very next change, because what you’re holding describes something you no longer run.
That’s not a cautious posture. It’s a blind spot you’ve chosen to schedule. It looks respectable on an audit. But it’s an insecure practice wearing the costume of diligence.
The answer isn’t to stop testing early. It’s to stop treating a test as an event and start treating it as a loop. If AI has made finding a vulnerability fast and cheap for the attacker, then finding, fixing and re-testing has to become just as fast for you. Prove the weakness is real, close it, and confirm the fix held, fast enough that the gap between a vulnerability existing and it being shut closes in hours rather than a quarter. That loop is exactly what drew me to what Horizon3.ai has built, and I’ll come back to it.
Test before release, yes, and then test what you actually run, in production. And before you call me out on this, I know how it sounds. “Test in production” is usually a phrase you hear as a warning, not a recommendation, because the risk of breaking something live is worse than the risk you are testing for. That’s what has genuinely changed. Testing safely against your live environment, without taking systems down or exposing data, is now possible with the right tools and guardrails, and it matters more than any test in staging ever could. A test against a copy proves something about the copy.
And now it has your name on it
Follow the thread and it all comes to the same thing. A slow loss of control. You can’t clearly see what an attacker could do to your live environment. You can’t keep your proof current as that environment changes beneath you. And you frequently can’t fix what’s found, because the remedy sits on another team’s backlog. And I don’t mean control in the fantasy sense of locking everything down. We gave that up years ago. I mean it in the only sense ever available to a defender. Can you see what’s really there, and get something done about it before an attacker does?
Here’s the frustration every cybersecurity leader knows and few say aloud. You’re accountable for the risk, but rarely own the fix. Your job was never to patch it. It’s to see it clearly, prove it’s real, hand it to the team that owns it with enough weight that it can’t be buried, and confirm it’s closed. Visibility, evidence, verification. That’s the whole of the control you genuinely have, and it’s worth far more than it sounds.
One day something will go wrong, and the question won’t be “were you breached?” Everyone is breached eventually. The question will be whether you did everything in your power. Whether you saw the risk, proved it, escalated it with evidence, and confirmed the paths that mattered were shut.
And increasingly, the body asking won’t just be a regulator. It will be a court.
That’s the accountability gap I’ve been writing about recently. You can’t close it entirely, but you can close most of it by turning “I raised it” into “I proved it was exploitable, I escalated it with evidence, and I verified whether it was shut.”
What a defensible position looks like
That’s why I’m partnering with Horizon3.ai.
Their platform, NodeZero®, behaves like an attacker rather than a scanner. Safely, across your live estate, from cloud and identity to your public-facing assets, it chains weaknesses into the real path an adversary would walk, proves the impact, and then verifies that your fix genuinely closed the door.
It’s done this across more than 250,000 production-safe tests, more than every manual pentest in history combined. That’s the only reason anything keeps pace with attacks that take minutes.
It doesn’t remove the human. It removes the drudgery, and hands your people back the thing they’re short of – time to make the decisions a machine shouldn’t. What you get at the end of it isn’t reassurance. It’s evidence you can put in front of your board, your regulator, or a court.
Don’t assume you’re secure. Prove it. See Horizon3.ai in action.
Now I want to hear from you…
For as long as I’ve been in this industry, “we tested it” has been accepted as good enough. Do you think “we can prove it” will become the standard we’re all held to? Head on over to LinkedIn and tell me there. It’s where we’re having this conversation.
In the spirit of full disclosure: I’ve received compensation for promoting this thought leadership blog. I only align myself with organisations and solutions I believe in – those that genuinely address the challenges I research and write about. Horizon3 ai is one of them.
