OpenAI CEO Sam Altman said that fixing software vulnerabilities one patch at a time is no longer feasible in the age of AI. The statement carries weight because it comes from one of the industry's biggest model developers: the speed at which flaws are found and exploited appears to be starting to outpace the speed at which defenders can produce patches.

What happened?

In a talk, Altman said he no longer believes we can patch all vulnerabilities. The core of the message is this: AI models are getting faster at reading code, hunting for flaws and generating exploits, while defenders cannot scale at the same pace. The remark is not a product announcement but a frank assessment, from an industry leader, of a side effect of his own technology.

Why does it matter?

For decades the security industry has run on the same cycle: a flaw is found, it is reported to the vendor, a patch is released, and organizations apply it. This model rested on the assumption that finding vulnerabilities is expensive and slow. It took a skilled researcher days or weeks to find a single flaw. That slowness bought defenders time.

AI is eroding this assumption. Large language models can scan vast codebases, recognize known vulnerability patterns in new contexts, and derive exploit code by examining the diff in a patch. The moment a patch is published, it becomes a roadmap for attackers. The window between patch and exploit is shrinking. Recent flaws in the PHP ecosystem and incidents targeting remote management tools such as ConnectWise show where this pressure is building up: widely used software that many organizations rely on and that is patched slowly. The issue here is not a string of isolated incidents but the shared pattern behind them.

A second problem is asymmetry. An attacker needs to find just one working exploit. A defender has to secure every component, every dependency and every legacy version. AI does not reduce this asymmetry; it widens it. Tools are getting cheaper for both sides, but an attack needs only a single door to succeed. On top of that, at many organizations the problem is not the absence of a patch but the delay in applying it. Altman's warning is therefore aimed not only at software vendors but also at patch management teams.

What is changing?

The approach is shifting from "close the holes" to "accept that holes exist and limit the damage." This extends the zero trust principle already under discussion in security architecture. Assuming a component will be compromised changes a design from the ground up: network segmentation, least privilege, short-lived credentials and tight isolation between components.

Placing the two approaches side by side makes the difference clear:

DimensionPatch-centric securityArchitectural resilience
Core assumptionVulnerabilities can be found and closedVulnerabilities are inevitable; damage must be contained
FocusReducing the number of vulnerabilitiesShrinking the impact of a breach
Weak pointShort window from patch to exploitHigh design and operating cost
Example toolsVulnerability scanners, patch managementIsolation, sandboxing, memory-safe languages

The move to memory-safe languages is one concrete example of this shift. Languages such as Rust block a significant share of vulnerability classes at compile time. With AI-assisted code generation, though, review becomes critical: a model can produce code quickly, but it can produce security flaws just as quickly. Models can also be used on the defensive side; automated code review and patch suggestions are heading in that direction. Still, there is no guarantee that defense will win with the same tools.

There is also a matter of candor. Altman's remarks come from the head of a company that sells models. He is in a position both to magnify the problem and to promise a solution. The warning deserves to be taken seriously, but it should not be read in isolation from product strategy.

What's next?

Three developments are worth watching. First, the restrictions and access policies model developers put on cyber capabilities: will exploitation skills be measured and limited? Second, software supply chain regulation: initiatives that impose secure-by-design obligations on vendors may gain momentum. Third, whether organizations speed up their patching processes or reduce their dependence on patches by isolating critical systems.

In our view, the key lesson is this: patch management is not going away, but it is ceasing to be the only line of defense. Systems that are not designed on the assumption that flaws are inevitable stand to suffer most from this new speed gap. Altman's admission is as much an alarm as it is an acknowledgment that architectural decisions are now the main stage of security.

For more on this topic, see CISA's secure by design principles.