The only way to win the cat-and-mouse game is to stop playing it
The “Mythos Moment” has reignited the AI-cybersecurity conversation. The considered response, now converging across AI policy, cybersecurity, and platform engineering, is exploring how the OT sector can step out of the traditional cat-and-mouse cybersecurity game.
A game with structural disadvantage
Cybersecurity has always favored the attacker. Kry10's CEO, Boyd Multerer, describes the dynamic: "Cybersecurity is a cat-and-mouse game. The adversary has the advantage because they get to be a scientist. They get a copy of the software, isolate it, and run experiments with all the time in the world. But nobody knows they're running those experiments, and once a threat is released, the defender has zero time to respond.”
That structural asymmetry has always favored attackers, and now AI decisively changes how. As Boyd puts it: "AI has taken what was already a hard game for the defender and made it impossible. The machines are now better at attacking than anybody, including the machines, are at defending."
Redefining the game’s players
The conventional cat-and-mouse description of cybersecurity names two players: an adversary with all the time in the world to be a scientist, and a defender with zero time to react. But there’s a third, often forgotten, party in this game and the cat-and-mouse cycle is due to them.
Software developers write the code in the first place, and the cat-and-mouse loop runs on top of what they ship. Defenders try to contain the damage when an attack lands; importantly, defenders are usually not the same person, or even team, as the developer. They are specialists, with the original developer largely shielded from the aftermath of attacks against the code they wrote.
That is what makes the conventional cat-and-mouse framing incomplete. The whole cycle exists because vulnerable code gets written in the first place, and the party most responsible for that has been outside the game.
How can the OT sector step out of the cat-and-mouse cybersecurity game, especially now that we know there are even more players to consider? What are the considerations for OT cybersecurity in a rapidly evolving threat landscape increasingly driven by AI?
The gap that sidelines OT
Tatyana Bolton at the Operational Technology Cybersecurity Coalition (OTCC) said it well when she was quoted recently in ISMG's reporting on Project Glasswing. She spoke about how operational technology (OT) vendors are absent from the closed-door access programs that shape how AI helps defenders find software vulnerabilities. Hyperscalers, security giants and forty open-source projects are at the table. Specialist OT cybersecurity vendors are not.
The OT sector has a lot to lose from AI-supercharged attacks on critical infrastructure. Right now it has the least access to AI-supercharged defense. Bolton's call for OT inclusion is necessary, and it's the right place to start. Kry10 endorses it.
But there is also a deeper layer that the conversation isn't yet reaching. AI vulnerability discovery is a faster way of playing a game that OT operators have been losing slowly for years. The more enduring question is whether they should be in that game at all?
The same case is being made publicly across cybersecurity policy and in venture circles. Nicole Perlroth, formerly The New York Times' lead cybersecurity correspondent, is now a partner at Ballistic Ventures and a CISA advisor. Over the past year, in talks and podcasts, she has been making the case that AI is a decisive offensive force multiplier in cyber, and the offense-defense asymmetry it creates is the strategic problem of this decade.
Project Glasswing and OpenAI's Trusted Access for Cyber are both responses to that asymmetry. These frontier labs are giving select defenders early access to AI-powered vulnerability discovery so they can find threats before adversaries do. This is useful and necessary capability if defenders are going to keep up at all. The OTCC is right that OT vendors should also be in those programs.
But for operational technology, even with that access, the underlying structural disadvantage remains.
Why this is harder for OT
Operational technology systems are built to last decades. OT operators are understandably conservative by nature after all, they run environments where downtime is the kind of event measured in dollars, deaths and destruction. Most cannot be patched on the attacker’s timescale, so while an OT operator diligently works through a multi-year coordinated patch program, the AI-armed adversary has all the time in the world to find the next flaw, and the next, and the next.
AI vulnerability discovery is helpful in this context but the asymmetry remains brutal. For OT, AI vulnerability discovery makes the defenders faster, but it does not fundamentally change the architecture they are defending.
Stepping out of the game
The OT cybersecurity discussion has changed in the last six months, and there is a different move now available to OT operators. The AI policy writer Dean Ball, in a recent essay, argues that staggered model releases and government-controlled access programs are useful in the short-term but cannot be the long-term answer.
Given the expectation that AI cyber capabilities will continue to improve, neither [staggered release nor government-controlled access] are long-term sustainable solutions. Instead, the future of software security will involve fundamental changes to the way we approach the problem.
Ball’s prescription is unambiguous; fund the research that delivers "formal verification and other methods of provably secure software development", and let the market adopt provably secure software at scale.
That conclusion is not new to the people who have been working on it. As Boyd says,
The only possible solution here is a fundamental change at the architecture level, where we use math to prove that key pieces don't have flaws to find in the first place. The only way to win the cat-and-mouse game is to not play the cat-and-mouse game!
Boyd articulates the move directly in the context of Kry10. "What Kry10 is really doing is bringing the role of the original software developer properly into the game. We’re saying, if a developer can’t write vulnerable code in the first place, then there are no vulnerabilities for the scientist attacker to find”.
This is the move formal methods make: they change what happens at the developer's desk, before any attacker, defender, or AI gets near the code. Whole classes of vulnerability don't exist, because the math has ruled them out. The entire center of power in the cat-and-mouse game shifts.
A converging mindset
The convergence on this perspective is notable; from policy commentators calling for formal verification as a viable solution, to cybersecurity reporters and investors deeply understanding the offense-defense asymmetry, to increasing demand for engineers who have been quietly building secure platforms.
The conclusion is the same across all these groups. This is what calm and considered looks like in cybersecurity right now: a recognition that the enduring answer has been maturing in formal-methods research for two decades, and the conditions calling for it have arrived.
A formally verified system component has been mathematically proven to behave the way its specification says it will. Whole classes of vulnerability cannot exist in such a component. The adversary's most powerful tool, the ability to be a scientist with all the time in the world, does not produce a flaw, because the flaw was never there to find.
Around that verified core, verified fault domains contain and prevent faults from spreading from one part of the system to another. Each component lives in its own enforced partition. A breach in one partition does not become a system-wide event. For OT, that is the difference between an incident and a sector-level event.
This is what Kry10 has been building for the past 7 years. Our Kry10 Operating System (KOS) is a practical and dynamic operating platform for critical systems and OT built on top of the seL4 microkernel, the world's only operating-system microkernel that has been fully formally verified. The formal verification research backing KOS is decades deep and now the conditions calling for it have genuinely arrived.
What this means for you
For executives in defense and critical national infrastructure, the practical implications are concrete.
The tools are already available to you, so learn about them. If your teams are writing software, they need to learn about how formal methods can be leveraged to increase security. If your business is running machines, take the time to understand how running formally verified systems and software can lower your risk and improve your uptime.
A final thought from Kry10
The OTCC is right. Operational technology cannot be an afterthought in the AI-cybersecurity conversation, and the inclusion call is the right place to start. At Kry10, we'd add a second argument. The conversation about who gets early access to AI vulnerability discovery is happening inside an older game where the terms have just been rewritten by the same AI capabilities.
For OT operators running infrastructure built to last decades, finding the next threat faster is part of the answer. The deeper part is whether we can build systems where there is no flaw to find. What was once a fringe view is now the considered conclusion emerging across AI policy, cybersecurity journalism, and decades of platform engineering.
Both conversations need to happen, and there needs to be stronger representation for OT.
If this is the conversation you're starting to have internally, we're having it too. Kry10's operating platform brings composable separation into practice for defense and critical national infrastructure. Reach out for a walk-through of what it looks like in your environment.
You can connect to us directly through hello@kry10.com.