More than 100 companies just signed OpenAI's open letter warning that AI-powered cyberattacks on critical infrastructure are imminent. The letter puts the timeline in months and names the targets: hospitals, water treatment plants, and the infrastructure that powers the internet.
At its core this is a speed problem. A published flaw now becomes a working exploit in hours, at a volume no security team can triage by hand. Almost every vulnerability program runs on the opposite assumption. Teams defer most of their vulnerabilities on the bet that few will be weaponized fast enough to matter, and for 20 years that bet paid off. It stops paying when exploit generation takes an afternoon. Remediation has not sped up to match. Fixes still wait on approvals and maintenance windows, and some systems can never be patched at all. Automating this process looks like the obvious answer, but it carries a risk of its own.
I spent years on national Red Team operations carrying out sanctioned attacks on exactly that kind of infrastructure, before a real attacker would. The way in was almost always a chain of ordinary weaknesses that happened to connect, rather than the worst finding on anyone's list. The letter says to fix your highest-risk weaknesses with the urgency of an incident, but high-risk means something different in every network.
One filter survives cheap exploit generation: reachability. Severity scores, exploit availability, and threat intelligence are all facts about the outside world, and AI is making them less predictive by the month. Reachability is a fact about your network. It asks whether an attacker can get to a given flaw through the topology you actually run, holding the privileges and dependencies that exploiting it requires. A frontier model can manufacture an exploit in an afternoon, but it cannot manufacture a route into a segment that has none. Any AI-era defense framework has to be built on that, because it is the only part of the stack that gets smaller as the volume grows.
What does high-risk mean in your network?
A CVSS score rates the flaw in isolation, under the conditions its formula assumes. Nothing in that calculation has seen your environment. It cannot know whether the affected service is reachable from an attacker's likely foothold, or whether a segmentation boundary makes the question moot.
Consider a critical remote code execution flaw on an internal build server. The scanner rates it 9.8 and it goes to the top of the queue. The service listens only on a management segment, and the single route into that segment runs through a jump host requiring credentials that exist nowhere an attacker can get to. Nothing about the CVE changes. The exploit requirements cannot be met in this network, so an attacker walks past it. 2 hops away, a medium-severity flaw on an exposed service sits directly on the route to a domain controller. Your queue has these two in the wrong order, and no amount of rescoring fixes it. The ordering is a topology question.
Reachability analysis is the computation that fixes the order. Run over real topology and real exploit requirements, it returns a far smaller set than the scanner does. In practice, roughly 1% of the vulnerabilities in a given environment are genuinely reachable and exploitable. The other 99% of "critical" findings consume engineering hours without closing anything an attacker could use.
This is how the offensive side has always worked. Operations get planned around a specific route from a foothold to something worth taking, with severity ratings barely entering the planning. Defenders now need to run that same analysis on their own networks, continuously, and reach the answer before an attacker does.
Every instruction leads back to a path
Work through what it asks of every organization and the same requirement appears underneath each one.
Incident-level urgency requires a target list. You cannot run an incident against a backlog of tens of thousands of critical findings. Incident tempo requires a set small enough to hold in your head and assign to named owners. Reachability analysis produces that set.
Verifying results without disruption means path closure. Patch deployment is easy to confirm and tells you very little. The question the letter actually poses is whether the route an attacker would have used is closed, and answering it means re-evaluating topology and exploit requirements after the change rather than re-running the scanner and watching a count drop.
Raising the bar on what you buy, build, and deploy, including AI-generated code, is a volume problem. AI-assisted development produces code faster than any review process was designed to absorb, and a meaningful share of it carries flaws. You will not scan your way back to a manageable number. The gate that scales is the one asking whether a given flaw is reachable in the deployed architecture, since that question stays answerable as volume grows.
Least privilege, access controls, and defense in depth are topology changes. They are also among the most durable remediation available, and most organizations cannot prove they worked. Reachability analysis makes architectural hardening measurable: count the paths to an asset before the change and after. A segmentation project gets an evidence trail.
Broad coverage from cheap models, frontier capability for hard problems, is a triage decision. Reachability is the routing function. Run low-cost analysis across everything, then aim expensive reasoning at the small set of paths that lead somewhere. Spending frontier compute on unreachable findings wastes the same budget as spending engineer hours on them.
Compensating controls are a first-class answer. The letter is direct that systems which cannot be safely patched still need verified controls, matching what defenders face in OT, medical, and legacy financial systems. The useful question is which control breaks the path. Often that is a firewall rule or a privilege revocation. Remediation beyond patching is often faster and easier to agree on, and it still requires knowing the path.
You can’t automate a bad queue
The market's answer to all this volume is autonomous remediation, and it meets the same wall the letter describes. Fixing anything in a large enterprise means changing business owners, OT constraints, and systems that cannot be taken down at all. Software can open those tickets faster than any team. The queue stays the same length, and a queue ordered by severity stays wrong however quickly it moves.
The risk runs deeper than wasted effort. A change pushed into a network you have not mapped can break a service it was never meant to touch, a bet most organizations cannot afford to take.
Reachability makes the queue short enough to act on. Automate against proven attack paths and the automation starts earning its keep.
What to do in the next 90 days
Start with a specific question to your team: of the critical findings sitting in the backlog right now, how many are reachable and exploitable from a realistic attacker foothold? If nobody can answer with a number, that is the gap to close first.
Map topology alongside assets. Connection is where risk lives, and an inventory does not show it. Read-only integrations with the tooling you already run will get you most of the way there without deploying agents or adding scan load.
Set your verification standard to path closure, and give architecture teams reachability metrics so hardening work can be measured. Then hand leadership something they can act on. A short list of named systems with proven attack paths earns a response that a severity chart never will.
100+ companies just agreed in public that the timeline is months. The organizations that come through it in good shape will be the ones that could say, with evidence, which paths an attacker could walk into the systems their communities depend on, and closed those first.
Astelia is an AI-native exposure management platform founded by former leaders of the Israeli National Red Team. It maps your network through read-only integrations, uses agentic AI to analyze exploit requirements against real topology, and surfaces the ~1% of vulnerabilities that are genuinely reachable, with remediation paths beyond patching.
Request a demo to see what the reachable 1% looks like in your environment.
