Zero Trust can’t stop at a claim. You need to prove it.

A senior executive at a large international bank in London told me recently that AI wasn’t a risk to his firm. His people weren’t allowed to use it, it was against policy, and as far as he was concerned that closed the conversation. It didn’t. A policy describes what a company intends. It says nothing about what people actually do. In a firm full of capable people working against deadlines, the chance that not one of them had quietly opened an AI tool was close to zero. He was describing a control he had never tested. He’d mistaken a rule for a fact.

That mistake is everywhere right now, and it reaches well past shadow AI. Most organizations can describe their security in exhaustive detail. Far fewer can show that it holds when something goes wrong. The distance between those two things is where leaders must turn their attention.

Available is not the same as resilient

The costliest version of that mistake is quiet and almost universal: many leaders treat “the service is up” as proof that the service is resilient. This isn’t always the case. Well, at least for services that haven’t been stress-tested. A system that stays available only because no one has seriously come after it yet isn’t resilient, it’s an incident waiting for a start date. Resilience is what’s left when something does go wrong but your customers don’t feel the impact. Can the service take a hit, keep running or recover fast, and can you show that it has? Uptime isn’t that. Uptime is just the good weather you’ve had so far.

Regulators need proof, not paperwork

Risk isn’t new. What’s new is that regulators expect you to prove you can manage it, not just assert that you can. DORA entered into force in 2023, but the compliance deadline only landed in January 2025, and the technical standards underneath it have kept raising the bar since. The requirement is blunt: don’t describe your controls; show that they hold when a real threat scenario hits.

DORA asks you to test secured services, govern them, measure how well the security held up, and show you’ve improved over time. That moves the question from “what is our control model?” to a much harder one: “can you show that your critical services stay operational under stress?”, and that accountability rests with the C-suite, not the security team.

What proof actually looks like

Beyond the policy binder and tooling inventory is where we find our proof: knowing how a service behaves when something breaks. Take any critical service in the financial sector: retail payments, claims processing, trade settlement, customer onboarding. The questions are the same for all of them. When did you last test a real disruption to it? How did it perform? How long did recovery take? What decisions were made under pressure, and what did you change afterwards? These are the questions leadership should be asking well before regulators ever do.

Leadership must get comfortable telling that story end to end: which services matter, what threatens them, how they were tested, what broke, and what got fixed. If you can’t tell that story, everything else you say about your security is just narration without substance. 

Frontier AI is what applies the pressure

If DORA raised the expectation, frontier AI is the reason the expectation is justified. As the newest generation of intelligent AI models, frontier systems are now finding vulnerabilities faster than security teams can triage them. Anthropic’s Project Glasswing, built on the Mythos frontier model, surfaced more than 10,000 high- and critical-severity vulnerabilities in systemically important software in its first month, much of it in code people viewed as well understood so “safe enough”. The bottleneck in security has moved from finding flaws to fixing them before someone else uses them against you.

Mythos is the most capable offensive security model I’ve seen, and the results genuinely stopped me. It’s the clearest picture yet of what the next few years might look like. But the point isn’t one model or one lab, and it certainly isn’t the fact that this lab’s model is pointed in a defensive direction. The same capability that lets Glasswing find flaws so they can be fixed lets a less friendly operator find them so they can be weaponized. Once a model this good exists, you plan for the ones that come after it, including the ones nobody is publishing benchmarks about. Offensive-capable frontier AI is now a class of threat, not a single headline.

Governments have read the same signal. They’ve stopped treating frontier AI like ordinary software and started treating it like strategic infrastructure, with restricted access, staged deployment, and models requiring review before release. It’s a recognition that the speed of discovery has changed what “safe enough” even means.

The systems you won’t touch are the proof

Every large finance business has systems it refuses to touch. “This one makes money, it’s stable, leave it alone” is the mentality. Freezing a ‘stable’ critical revenue system used to be an acceptable trade-off because threats moved slowly enough for organizations to respond. That trade-off logic doesn’t hold water now because the threat landscape is far less forgiving. Again, the argument boils down to validating assumptions for proof: how do you know your system is ‘safe enough’ if you haven’t tested it? The code you’ve left alone longest has had the least scrutiny, and frontier models are built to find exactly that kind of code. 

This is the availability trap in the flesh. That untouchable, untested system is up and generating revenue. Leadership sees uptime but what’s really there is unknown risk. It’s up until it’s breached, and ‘operational-until-attacked’ is not a security posture. Some of these systems need rearchitecting. Most, in the near term, need to be treated as exposed rather than exempt: protected, tested, patched, and put on a plan instead of a pedestal.

Let’s be honest with ourselves about risk

Unprovable security isn’t a tooling problem; it’s a credibility problem. If you can’t demonstrate how your critical services behave under disruption, regulators start questioning your resilience, investors start questioning your oversight, and your own people lose confidence in the system exactly when they need it most. All of it lands on the customer in the end.

So, when a regulator, an auditor, or an investor asks how you stay in control while a disruption is actually unfolding, the real question isn’t whether your systems are up. It’s whether you can prove they’d survive your worst-case scenario. If the only answer you have is “it hasn’t gone down yet,” that isn’t resilience. That’s luck, and luck isn’t something you get to put in a filing.

A policy that says "no AI" doesn't mean no AI is happening. Across nearly one trillion enterprise AI transactions analyzed, the gap between assumption and reality is now measurable, and widening according to our AI Security Report.

The hardest question in this piece is also the simplest: can you show that your critical services survive under stress? If you're not sure, start here. Run a free security risk assessment .