When Anthropic announced that its Claude Mythos Preview model had found previously unknown vulnerabilities and built working exploits for them with no human guiding the process, my inbox was overflowing. By late May, Anthropic and its Project Glasswing partners had reported more than 10,000 high- or critical-severity flaws across every major operating system and browser. The security leaders who reached out were not asking about the vulnerabilities. They were asking what comes next.
Every one of those flaws will trigger a remediation decision, and many will ultimately drive changes to production systems, firewall rules, segmentation, or network policy. One CISO put it to me plainly. “We are about to approve more changes in a year than we used to approve in five, and I still can't tell you what any single change will do before it goes live.” That is the real problem Mythos exposed.
The patch surge is a change surge
In my conversations with security and network teams, the same pattern keeps surfacing. Security teams think in exposures. NetOps teams think in terms of connectivity. The two meet in the change window, and that is where risk quietly compounds.
Mitigating an exposed vulnerability can require a firewall rule, routing, access control or segmentation change. That change may close the exposure, but block intended connectivity elsewhere. Conversely, enabling an application connectivity may unintentionally open another path the network was designed to block. The change works as designed, every check passes, and a new exposure silently goes live alongside it. Nothing alarms, so nobody notices until there is a breach.
Discovery is getting faster. CrowdStrike's 2026 Global Threat Report puts average eCrime breakout time at 29 minutes, with the fastest observed at 27 seconds. An exposure that lingers for an afternoon is no longer a minor gap. It is an opportunity for the attacker.
This is not due to a lack of rigor. The teams I work with run change reviews and lab tests precisely because they understand the stakes. Those processes are traditionally the best available option, but they rely on out-of-date diagrams, tribal knowledge, and incomplete data. They cannot prove the outcome of a change on network behavior or security risk. Until now, the production network has been the only true test environment.
Why visibility is not enough
I have never met a security team short on tools. Scanners, cloud posture platforms, SIEMs, and observability systems all do essential work, primarily helping teams understand exposure, events, and current state. But change approval poses a different question. What will the network do after this change? The question that matters before approving a change is different. How will reachability, segmentation, and policy change across every possible affected path? Tools based primarily on observed traffic or partial network state cannot necessarily determine every possible behavior the change could introduce.
Proving how a change will impact the network and its security posture requires a fundamentally different capability.
Prediction starts with a mathematically accurate network model
Predicting with certainty the network behavior arising from a proposed change requires a mathematically accurate model of the entire production network built from the actual configuration and state of every device from every vendor, on-premises and in the cloud. That model has to trace every possible path all possible packets can take, not just the paths observed in live traffic. Run a proposed network change against it, and its effect on reachability, segmentation, firewall and ACL policy, and compliance is proven before anything touches production.
This is not a capability that can be developed overnight. It requires a mathematical approach to network digital twin technology, one that my team at Forward has spent more than a decade building. The model must be vendor-agnostic and track every possible path in the network. It must return a deterministic outcome with evidence, showing exactly how a change will impact network behavior and security posture. And it must enable the engineer to iterate until it finds a change verified to deliver the intended behavior and security compliance. Anything less is an unnecessary risk to security and connectivity.
The result is deterministic evidence of how the proposed change will affect network behavior and security posture. The same question asked of the same network returns the same answer every time, with evidence a team can inspect. The model is always current, and inputs are always accurate. That is why I believe predictive verification belongs in every enterprise network.
Two questions before every change
I encourage every security team I meet to hold each change to two questions, answered with proof before it reaches production.
Does the change accomplish what we intended?
Does it alter our security posture in any way we did not explicitly approve?
When a team can answer both with evidence, change velocity stops being a risk multiplier. Security and network teams work from the same verified understanding of network behavior. The change window stops being the most dangerous moment on the network and becomes the most controlled one.
Autonomy requires proof before action
My co-founder Brandon Heller argued in a recent article that a post-Mythos world demands more autonomous defense. I agree. Defenders cannot match machine-speed attackers by asking people to review changes faster.
But autonomy without proof only drives more uncertainty. An AI agent that remediates a vulnerability with a plausible but unverified change is not reducing risk. It is relocating it. The same standard applies whether a person wrote the change or an agent proposed it. In a recent study, Cisco and Omdia found 99% of organizations expect guardrails before trusting AI to act, including explainability, approval controls, policy limits, and audit trails.
What encourages me most is that this standard is now achievable. The security teams that establish proof before production now will be the ones best positioned to safely hand routine remediation to AI as autonomy increases, while keeping human expertise focused on the threats that truly require it.
Comments