AI attacks are moving faster than companies can patch

Wiz co-founder Ami Luttwak calls the recent wave of incidents ‘Black October’: vulnerabilities are appearing at an unusual rate, while attackers can use AI to carry out campaigns with greater speed and expertise. The concern is not just the number of flaws but how quickly an attacker can turn one into access.

Luttwak points to earlier demonstrations of AI finding vulnerabilities and an incident involving Hugging Face as warnings. He says the change is that models can now both find and exploit complex flaws, and that openly available models are catching up quickly.

A weakness need not be a famous flaw in widely used software: a mistake in an application’s own API can be enough. Luttwak says an attack that once took a highly skilled team weeks or months can now take about 20 minutes. That leaves little room for a small company to detect and respond.

Asked how far open models trail, Luttwak estimates that the lead for finding vulnerabilities may be no more than three months. AI development platforms are attractive targets, he says, because they hold valuable AI credentials. He says Wiz had counted an expanding list of attacked companies in that sector.

The hosts ask about PHP2Shell, a vulnerability in a widely used web technology. Luttwak says almost all of Wiz’s customers had some PHP running. He reports that roughly half of the affected installations were patched in the first two or three days, but expects the long tail to take years.

The patching problem is not simply slow internal teams. Some old PHP versions no longer receive patches, and fixes for a Linux kernel flaw can take weeks or months to reach every distribution. In the PHP case, Luttwak says information leaked before the industry’s planned coordinated release.

Luttwak does not see a simple route to automatic patching for legacy companies. A new company can design for it, but only with a connected pipeline: automated development produces a fix, tests validate it, and deployment and operations put it into production. Most established organizations do not have that pipeline for all their code.

Zane Lackey asks how Wiz’s researchers used AI to discover the PHP flaw, which another team also found independently. Luttwak expects simultaneous discoveries to become more common: when a new model brings new capabilities, multiple teams can apply it to the same valuable targets.

Wiz built a vulnerability-detection framework called Atlas and tries models from several providers. Luttwak argues that defenders should use the short lead offered by frontier models to inspect critical infrastructure continuously, although the volume of code means attackers will still find other weaknesses.

Each model and version behaves differently and has its own speed and cost. Luttwak says independent companies need to keep testing combinations instead of choosing one model for every job. For a service operating at scale, the price of inference can determine whether its business model works.

He describes a layered investigation pipeline: deterministic detection first, then a cheaper model, followed by more capable models where needed. Only a suspicious event reaches the most expensive model for a final judgment. The engineering problem is to route work intelligently rather than pay top price for every event.

Sarah Wang asks whether continuous testing can become affordable for ordinary companies. Luttwak says a full scan can cost millions, and that repeating it whenever a model or code changes can consume tens of millions. He says the industry has not solved how best to spend that budget continuously.

A continuous program must choose among external probing, internal visibility, code analysis, disk inspection and observation of running systems. A single expensive scan produces a snapshot; it does not answer how to allocate resources as models improve and software changes.

Lackey asks what happens to established cloud-security problems when AI introduces new ones. Luttwak says the old problems remain: an unpatched vulnerability is still an entry point. Teams still need visibility into their environment and must fix the most consequential risks.

Customers increasingly expect a security product to do more than rank a vulnerability: they want it to locate the code, propose a fix and create a pull request. Similarly, an alert alone is less useful than an investigation explaining the entry point and root cause.

Luttwak expects pressure to automate incident response as well as detection and investigation. He acknowledges that automatic response is a frightening step, but argues that the speed of AI attacks makes it increasingly hard to avoid.

Wang asks about Wiz’s ‘red agent’, which simulates an adversary, alongside its ‘blue agent’ for detection and investigation. Luttwak says a system considered secure last week may no longer be secure after a model gains a new capability. His answer is to test it repeatedly before an attacker does.

The red agent attacks applications from outside while using available internal context to find weaknesses. Lackey asks whether it also uses a staged pipeline. Luttwak says it starts by mapping exposure and identifying unauthenticated internet-facing assets; deeper penetration testing and code analysis follow according to importance.

The amount of effort varies: a quick assessment may spend minutes on an endpoint, while a critical application might warrant ten hours of testing. If engineers cannot fix a discovered problem immediately, Luttwak says the defensive agent can add detections around it. The stages should work together within a budget.

Luttwak says many Wiz customers already use the red agent, but he believes adoption across the wider industry remains insufficient. In his view, continuous external testing deserves priority because it looks at the surfaces an attacker can actually reach.

He contrasts this with spending heavily on code scanning alone. As an example, he mentions an incident involving a credential embedded in a mobile app and exposed data. His proposed first priority is to identify and repeatedly test unauthenticated public entry points.

Asked what founders should do before a release, Lackey recommends moving security work into the development process rather than treating it as a final delay. Continuous tests, investigation and patching should run alongside product development, with automation designed into new infrastructure.

Luttwak asks founders to imagine learning in the morning that an attacker got in overnight. In his example, the attack can reach customer secrets and AI keys in about 20 minutes, before a small company has a person available to respond. He says startups holding useful credentials are targets even when they are not large.

One practical step is to set limits on AI keys so that stolen credentials cannot generate unlimited charges. Both speakers argue that companies should give security more attention and resources, while Luttwak stresses that a purchase alone does not solve the design problem.

Wang cites one security leader who expects an 80% budget increase and asks where money should go. Luttwak compares preparing for highly capable attackers to protecting every entrance to a house: buying another lock does not replace thinking about the windows and roof.

His answer is to review existing tools, continuously test applications and design isolation into the system: restrict networks and processes, use sandboxes, and assume vulnerabilities can appear at multiple layers. He argues that architecture matters more than a larger budget by itself.

Asked what security teams should stop doing, Luttwak argues that many spend too much time on reports and compliance checklists relative to finding real attack paths. He wants teams to identify critical risks, mitigate them or add detection, and prepare a response before an incident.

Wang asks how experienced staff should spend time as agents take on routine work. Luttwak says startups can build an automated process from the beginning, but older organizations have thousands of developers, legacy software and undocumented ownership. Finding who owns a resource and getting a fix deployed remain difficult.

Looking ahead two or three years, Lackey predicts a return to a period of frequent breaches and remotely exploitable flaws, perhaps even internet worms. He recalls when a Windows XP machine could be infected before an online update finished, requiring administrators to install and patch it offline.

Wang asks whether Luttwak’s earlier prediction of a coming Y2K-like moment should be brought forward. He says open models are catching up faster than he expected and views Black October as a possible beginning. He argues that AI attacks can already exceed human capabilities in some complex cases, though he cannot predict two years ahead.

Luttwak says companies need both automated security and a different design for internet-facing systems. If a system is not ready for capable attackers, he argues, its exposure should be reduced. The speakers then turn from businesses to public services and physical infrastructure.

Wang raises attacks on refrigeration equipment and asks about organizations with small security budgets. Luttwak says connected legacy systems in the physical world are also at risk. Wiz’s Scan for Good offers public services scans to help find problems and encourage them to begin their own continuing testing.