How to Defend Against AI Hackers, with Wiz’s Ami Luttwak
Ami LuttwakZane LackeySarah Wang
- Ami Luttwak says AI can now complete attacks that once took elite hackers weeks or months in roughly 20 minutes. Open-source models are catching up faster than he expected; he puts the frontier advantage in vulnerability discovery at “not more than three months.” The immediate targets include startups holding customers’ AI keys, where stolen credentials create an opportunity for “LLM jacking.”
- Faster exploitation is colliding with patching systems that cannot move at machine speed. Luttwak reports roughly 50% patching within two or three days for the PHP vulnerability across Wiz’s customer base, but older versions lack patches and distribution delays can last weeks or months. He sees an automation path for new companies with automated development, testing, CI/CD, and operations; legacy organizations face a much harder transition.
- Security AI faces a substantial cost problem alongside its capability gains. A comprehensive code scan might cost $5 million, and Luttwak says some customers are spending tens of millions on scanning. Sustainable services require deterministic checks and cheaper models to filter work before expensive models investigate: otherwise, “you’re gonna lose money on your sales.”
- Luttwak puts continuous testing of external exposure ahead of another comprehensive code scan. Newly capable models can make yesterday’s defenses inadequate, so testing must recur as capabilities change. He says a majority of Wiz customers already use its red agent, while broader industry adoption remains insufficient: “The best defense is attack.”
- Founders holding valuable credentials need security investment and automation earlier in their development. Luttwak says a list of AI development providers attacked in October grew from nine to 15 companies. He recommends limits on AI keys to contain stolen-key charges; Zane Lackey argues for continuous testing and patching alongside development when founders face release deadlines.
- Luttwak argues that larger budgets cannot substitute for secure architecture. Sarah Wang cites one CISO expecting an 80% budget increase next year, but Luttwak emphasizes isolation, lockdowns, and preparing for nation-state-level attackers. His challenge to checklist products and reporting-heavy workflows is blunt: “Most of what security teams do is not security.”
- The forecast extends beyond software companies, with substantial uncertainty about the next two years. Lackey says he would not be surprised to see internet worms return; Luttwak says October “might be the beginning” but cannot foresee two years ahead. Refrigeration attacks and other connected infrastructure motivate Wiz’s Scan for Good initiative, which offers public services an initial scan rather than a complete solution.
1. Black October compresses the attack cycle to 20 minutes
Luttwak calls October a “black swan event”: unprecedented numbers and severity of vulnerabilities coincided with actual AI attacks. Before Black October, the Mythos moment showed that models could find vulnerabilities, while the Hugging Face incident involving OpenAI showed the risk of AI attacks, though those attacks were accidental. Now models can find and exploit complex flaws. An attack that took the best human attackers weeks or months can run in “around 20 minutes,” including exploitation of an ordinary API mistake.
Lackey relays that offensive-security practitioners have described open-source models as six to nine months behind. Luttwak puts the advantage in vulnerability discovery at “not more than three months,” while distinguishing discovery from executing attacks. Open-source models are already good enough for the latter. His previous hope that they were a year behind has proved too optimistic.
Startups are already targets because their credentials have value. Luttwak says Wiz’s list of AI development providers attacked in October expanded from nine to 15 companies and kept growing. Attackers can steal customers’ AI keys before a startup detects and responds. His practical recommendation: put limits on those keys so theft does not produce enormous usage charges.
Independent discovery is becoming more common: Wiz and another team, Caliph, found PHP to Shell separately. Luttwak compares vulnerability discovery to “Bitcoin mining”: new models unlock additional findings. Wiz’s zero-day competition is also receiving multiple reports of another critical vulnerability he believes will significantly affect the internet. The defensive objective is to use frontier models’ brief advantage on critical infrastructure before attackers arrive.
2. Patching remains constrained by the systems around it
Luttwak describes the PHP flaw as “probably the most severe vulnerability ever found by AI.” Almost 100% of Wiz customers ran some PHP; he reports 50% patching within the first two or three days. Sarah Wang estimates that PHP underpins roughly 70% of the internet, and Luttwak says this single vulnerability could take years to resolve. Older versions are not even receiving patches.
Wang’s pushback is the central asymmetry: exploit-writing time has fallen, while patching time appears to have increased over the last 20–25 years. Luttwak says information can leak before the CVE is out, and even after a CVE is out, a patch may not be ready. Wiz worked with PHP for months to prepare the industry, but information leaked early. Customers then had no patch to apply, however quickly they wanted to respond.
Distribution adds another delay outside a customer’s control. A reported Linux kernel vulnerability might take weeks or months to reach every distribution, while AI can exploit flaws in minutes. “The world isn’t ready for this,” Luttwak says. Asked about automatic patching, his answer is candid: “We don’t yet know exactly how to patch automatically,” and “I honestly don’t see a path toward that.”
His qualification matters: a new company can design for automatic patching from inception. That requires an entire pipeline—an agent turns a ticket into a patch, automated tests validate it, and automated CI/CD and DevOps deploy it. Most legacy companies lack that chain, and he does not consider it realistic for much of their existing code. For startups, building it should be an explicit task.
3. Model orchestration determines whether security AI can scale
Wiz’s Atlas harness uses different models for vulnerability detection because capabilities differ across providers, versions, and specialized cyber variants. Luttwak describes a “complicated matrix” of capability, speed, and cost. Even with Wiz now part of Google, his prescription for an independent company is to “try all the models all the time” and find the best combination.
The blue agent illustrates the economics. Deterministic detection comes first, followed by a cheap model and then a more advanced model. If those stages judge an event malicious, the most advanced model makes the final assessment before notifying the customer. Running the costliest model on every event would not work. This pipeline design is, for Luttwak, a central engineering challenge for scalable AI services.
Continuous scanning compounds the expense. A hypothetical April code sweep might have wasted $5 million; then “Mythos 1.2” arrives—do you repeat it? Some customers are spending tens of millions. Budgets must span external and internal testing, code, disks, and runtime as models and applications change. Luttwak explicitly declines to claim victory: “I’m not going to tell you that we’ve solved it.”
4. Continuous external testing takes priority over blanket code scanning
The red agent’s premise is that security changes even when an application does not. Luttwak’s analogy is a door with a key hidden under the mat: attackers acquire “superpowers every week,” so what appeared secure last week may fail today. Continuous attacks with the latest models aim to identify that change before an adversary does, using internal context to guide external testing.
His ordering is emphatic: deterministically map exposure, then test everything unauthenticated and reachable from the internet before deeper penetration testing and code analysis. “Who cares about your code?” is his provocation about urgency. The concrete example is a recent incident involving a key hard-coded in a mobile application that exposed people’s data. Attackers exploit accessible mistakes, not just sophisticated software flaws.
Effort should vary with the target. An exposure agent might spend a few minutes per endpoint across a million endpoints; a critical application might warrant 10 hours of attempted exploitation. Red and blue workflows should also connect: if engineering says a discovered problem is too expensive to fix, the blue agent can place detections around it. “Everything is going to be a pipeline now.”
A majority of Wiz customers already use the red agent, which Luttwak calls one of its fastest-growing features; he says coverage is moving quickly toward almost complete adoption. Across the industry, he sees insufficient uptake and misplaced emphasis on code-scanning publicity. “There’s nothing more important than continuously scanning your environment from the outside.”
5. Security teams need architecture, context, and response at machine speed
Wang asks how founders with security backlogs should approach an upcoming release, citing a note from Lackey and colleague Joel suggesting more security spending and potentially delayed launches. Lackey’s answer emphasizes doing the work in parallel: agents continuously test while development proceeds, and new companies build patching automation into software and infrastructure development from the beginning. “The security game has just changed.”
Wang’s example of an 80% budget increase comes from one CISO’s expectation for next year. Luttwak questions whether budgets alone can solve the problem: companies must prepare for attackers with elite expertise and speed. His priorities include sandboxes, isolation, and network, process, and image lockdowns. Simply placing workloads in Kubernetes is insufficient when kernel vulnerabilities permit container escapes. “Get ready for a nation-state attacker.”
His critique of existing workflows is deliberately sharp: “Most of what security teams do is not security.” He contrasts time spent attacking systems with compliance and report production, and singles out classic CSPM configuration-check lists. The work he prioritizes is finding critical risk, mitigating it or adding detections, preparing responses, and building a sustainable isolation strategy.
Customers increasingly expect fixes and pull requests, plus investigations, forensics, and root-cause analysis. Automated response is the next step, which Luttwak calls “very scary.” Legacy organizations still struggle with thousands of developers, unclear resource ownership, and unwritten knowledge; an agent does not instantly supply that context. The operational test remains unforgiving: “If I cannot respond in minutes,” he asks, “what am I relevant for?”
6. The next breach wave could reach connected physical infrastructure
Looking two to three years ahead, Lackey predicts a return to the 1990s and 2000s: frequent unauthenticated remote vulnerabilities and breaches. He “wouldn’t be surprised” to see worms again. His Windows XP analogy is specific: internet-connected machines could become infected during installation and updating, forcing users to install offline because compromise happened faster than patching.
Wang recalls Luttwak’s April warning of a Y2K moment in 12–18 months. He now says October “might be the beginning,” while declining to foresee two years ahead. His categorical claim is that AI attacks are already “better than any human’s”; he cites that day’s kernel-driver zero-day attack. He thinks survival requires redesigning internet-facing systems for these attackers and quickly taking unready systems offline.
Wang brings the discussion to European refrigeration attacks and food-supply consequences. Luttwak worries about any connected legacy system, including traffic infrastructure. Scan for Good offers public services scans to identify problems and encourage sustained testing. He limits the promise: “It’s not going to solve all their issues.” The hope is that concrete findings demonstrate why a larger security project is necessary.
Full transcript
We’re going back to the ’90s and 2000s again. We’re going to see breaches popping out all the time again. It’s going to look very different from the last 15 years of security.
AI attackers are actually going after companies and startups at a scale and speed we’ve never seen.
Elon Musk tweeted that recently: “Every day is zero day.” What is AI doing to make this happen?
Models are good enough now to find and exploit complex vulnerabilities. The other thing is open source models. That’s the scary bit. A few months ago, we said we had a few months until open source models caught up.
Yeah.
So now they’re catching up.
The security game has just changed. You need to be thinking about how you can automate so much of both the blue side and the red side right now.
Most of what security teams do is not security. We should stop doing most of what we do—
Yeah.
—and focus on finding critical risk, figuring out how we mitigate it, or at least put detections in, and also preparing to respond.
What do you think the next several years look like?
AI attacks are prevalent and easy, but also better than any human. That’s the problem. The only companies that will be able to survive are companies that are—
Ami, thank you so much for joining us. Security professionals are calling October Black October, and it’s clear that we’re entering a new era of agentic attacks. To start off, can you walk us through what the heck is going on right now, and how do we get through this critical moment?
Yes. First of all, great to be here. We’re calling this Black October since, in my view, it’s a black swan event. We’ve never seen so many security incidents happen in a single month. We’re talking about multiple different types of security incidents: both the number of vulnerabilities found in October and their severity, including the PHP vulnerability, probably the most severe vulnerability ever found by AI. Vulnerabilities are coming at a rate we’ve never seen. But even worse, we’re seeing the rise of AI attacks: attackers using completely new speed and expertise, actually going after companies, startups, and refrigerators at a scale and speed we’ve never seen.
Yeah. The scary thing about that, to your point, is the speed. You’ve said to us privately, and probably publicly as well, that every day is zero day, right? Elon Musk tweeted that recently. Say more: what is AI doing to make this happen? What’s the mechanism that lets it speed up writing exploits? I think you did some work around this, where you found it collapsed the timing from months to weeks. Say more about how that works. And, for the audience of this podcast, what should founders be thinking about and doing?
If we think about how we got here, there were 2 major moments before Black October. One was the Mythos moment, when Mythos came out and said, “Oh my God, we can find vulnerabilities.” That was one moment. But again, nothing happened. We said, “Oh my God, it’s coming,” but we were still at a point where people said, “Okay, what? The world is still turning; the sun is still rising.”
The other big moment we had was the Hugging Face incident with OpenAI, right?
Yeah.
Yep.
That was another major incident where we saw the risk of AI attacks, but again, they were accidental attacks.
Yep.
What happened now in Black October is that all of those potential theories, the things we said were coming, came and crashed upon us. It’s happening right now. One thing is that the models are good enough now to find—
Yeah.
—and exploit complex vulnerabilities. This is not a theory anymore. It’s happening. There’s an explosion of vulnerabilities. The other thing is open source models. That’s the scary bit. We said it when we spoke about Mythos a few months ago: we had a few months until open source models caught up.
Yeah. Yeah.
So now they’re catching up. It means it’s not just about vulnerabilities. They’re able to find ways to run code in your environment. It doesn’t have to be a complex PHP vulnerability. It can just be a mistake in your API. They can find and use those zero days in your code, and basically run an entire attack that usually took the best attackers weeks or months in around 20 minutes. That’s what we’re seeing now. So—
Yeah.
—your entire—
How far behind are we seeing the open source models? When we’re chatting with folks on the offensive capability side, it tends to be about 6 to 9 months or so, but that’s close enough at this point. I’m curious what you’ve seen.
There are 2 different questions. On the offensive side, are we better than the open source models at finding a vulnerability? Maybe we have 3 months. It’s not more than 3 months.
The problem is the offensive side of attacking. Because—
Yeah.
—I’m a company. It doesn’t matter. Let’s say it’s a startup. Again, we’re talking about a wave of attacks. If we just look at AI development providers, we had a blog about how we initially saw 9 companies attacked in October, and the list is growing every day. We’re now at 15.
Wow.
That’s—
Jesus.
—just one example of one market: AI development platforms. These are getting targeted specifically now because they have AI keys. The fact that an attacker doesn’t have to be sophisticated and can use AI—open source models are good enough to find problems in your code—is a big problem. They can also use those problems in 20 minutes. Think about which startup is ready to detect those attacks, find them, and respond in time. You need a 24/7 SOC in every small startup.
Yeah.
Right.
Why don’t we talk for a second about PHP to Shell as an example, a case study of one of the many things that came out during Black October? Can you talk a little about how prevalent you saw this across your customer base? Now that we’re a couple of weeks out, I’m curious about how patching has actually been across your customer base, and what the state of things is a few weeks after it came out.
PHP is one of the most prevalent technologies as an external-facing technology, right?
Oh, yeah.
The—
As a former CISO of a PHP e-commerce company, yes, I—
What did I think? It’s like 70% of the internet or something.
Yeah.
Yeah.
Yeah, exactly.
Exactly. The impact is that basically almost 100% of our customers had some PHP running. We saw a major drop very quickly. I wouldn’t say customers have automated patching yet, but they’re very aware of the importance of patching. I’m talking about 50% patching within the first 2 or 3 days.
Mm-hmm.
So, almost immediate reduction. But the problem is that this is 70% of the internet.
Yeah, exactly.
So even just this single vulnerability is going to take years to resolve. There are many cases we see, both on the internet and in customer environments, where they don’t have any way to patch.
Yeah.
Older versions of PHP aren’t even getting a patch.
Yeah.
Can I ask a meta question here? Two of our partners wrote this great piece on time to write exploits versus time to patching. There’s a lot of dialogue out there about how AI has made it cheaper and easier to turn a patch diff into a working exploit, and there’s some data showing that time falling. On the other hand, the data seems to show that time to patch actually hasn’t gone down. In fact, it’s gone up if you look at the data over the last 20 or 25 years. Can AI help with that side as well, Ami, or is it still early days?
First of all, you’re right. The time to get an exploit has gone down dramatically. It’s even worse because many times the information leaks before the CVE is out, okay?
Right, yep.
Many times, even when the CVE is out, the patch is not ready.
Yep.
Mm.
In the PHP case, we worked for months with PHP to get the entire industry ready, and it leaked before time. So the customer doesn’t have anything to do. The patch isn’t ready. In Linux right now, even if a vulnerability is reported to the Linux kernel, it might take weeks or even months until it reaches all of the distributions.
Right.
The industry in general isn’t ready for this. Even if you can patch internally quickly, sometimes a patch isn’t ready until it gets to your distribution. The industry isn’t ready for AI.
Right.
AI can exploit things in minutes. The answer is that the world isn’t ready for this. In terms of patching, you’re right: we don’t yet know exactly how to patch automatically, and I honestly don’t see a path toward that. It’s easy to say, “Yes, let’s automate everything.” In reality, if you’re building a new company now, you can do it. If you’re building a new company and you have automated engineering, automated CI/CD, and automated testing, you can get to a position where I tell you, “Patch this,” and your entire system can do it automatically. I think new companies should design their systems to be able to patch automatically.
Mm-hmm.
To do that, you need an entire agentic pipeline for everything. You need automated development, so you need the ability to take a ticket and have an automated developer create the patch. Then you need automated testing, automated CI/CD, and automated DevOps. There aren’t a lot of legacy companies that have all of that, and it’s not even realistic for most of their code. But for startups, maybe it’s possible, and I would consider this a task for startups.
Yeah.
If you’re starting, plan for this.
Yeah, absolutely. I’m curious to dive a little deeper on the offensive side. Going through the discovery of this, it was funny—a bit of a footnote here—but this was a vulnerability independently discovered by 2 groups, Wiz and Caliph, around the details of the PHP-to-shell vulnerability, which used to happen a lot back in the day.
Yeah.
For your research team, how were they leveraging AI to discover this? Could you go a little deeper on how it’s unlocking vulnerability research teams?
A few things. First of all, I think this will happen much more now.
Okay.
Mm.
Every time there’s a new model, there are new capabilities.
Yeah.
Again, I look at it like Bitcoin mining. The number of vulnerabilities will go down, but because it’s like Bitcoin, there are always more. The new models can uncover more vulnerabilities, so it’s not surprising that there’s a new model and then multiple teams find new vulnerabilities.
Exactly, yeah.
By the way, right now we’re getting ready for ZTC, the zero-day competition of Wiz, and we’re getting multiple reports on a very critical vulnerability that I believe is going to have a major impact on the internet. This vulnerability is being reported by multiple teams.
Yeah.
Wow, yeah. Mm.
It’s never—
It’s amazing how everything old is kind of new again in the security industry right now.
Yes, you’re right. Internally, our vulnerability team built something for the Wiz product that we call Atlas. It’s a harness for vulnerability detection, and we’re using it with different models all the time, because every model has its own unique capabilities. OpenAI, Google, and Carbon each have their own capabilities, so we’re trying to use all of them and find whatever we can. But everyone is doing it, so you’d expect a lot of teams to find vulnerabilities at the same time. That’s the important thing: we have to focus on critical infrastructure using frontier AI models that have a few months of advantage, and continuously do that in those areas to make sure we find vulnerabilities before attackers. But there’s so much code in the world that it doesn’t solve everything, because attackers will still find vulnerabilities in areas we didn’t look into.
I don’t want to take us down a frontier-model rabbit hole too much, but I want to probe a little on what you said about using multiple models, with each one being good at different things. To the extent you can share, Ami, I’m curious about 2 points. First, what are different models better at, at a high level? Second, how do you see the relationship between frontier labs and independent cyber companies these days? Obviously, Wiz is part of the Google family now, so you have the DeepMind team and their models at your fingertips, but it sounds like you’re using multiple models.
I think every model, and every version of every model, is different. Now it’s getting complicated because you have the frontier models and the cyber versions of those models.
Right.
Right.
Each of them has its own capabilities. It’s a complicated matrix.
Yeah, that’s—
The point is that each of them behaves differently, and—
Mm.
—it has different speed and cost. There’s no single answer. If you want to do a task, that’s true for cyber, but it’s true for other things as well.
Mm-hmm.
The only thing you can do as an independent company is try all the models all the time and find the best combination.
Yeah.
The way I see it is, people say, “Oh, now it’s easy to develop using AI.” It’s not true. For most founders right now, the key is going to be the cost of the service.
Yes.
Right?
Absolutely.
The only way to create a scalable service is by creating a very intelligent pipeline, where you do some tasks with specific models and some of the more complicated tasks with other models, and mesh all of them together in a very efficient way. Otherwise, you’re going to lose money on your sales.
Mm-hmm.
As an example, we have what we call the Blue Agent, which investigates attacks. I cannot run the most advanced, expensive model on every event. But I can create a pipeline where you start from a deterministic detection, then go through a cheap-model detection, then go through a more advanced model.
That’s right.
If all of them think it’s malicious, I’ll send it to the most advanced model to determine whether it’s really malicious before I tell the customer. You see?
Yeah.
So you need multiple models, multiple types of models, and you have to design pipelines. I think that’s really the new engineering challenge for founders and for companies building AI systems at scale.
Yeah.
Absolutely.
Absolutely. On this cost point, you talk about a paradigm shift in a blog post you wrote, around continuous testing, with the focus being on “continuous” versus “static.” Cost plays a big role in whether every company can do that, not just the most profitable and sophisticated ones. How far are we from getting there from a cost perspective, and what else needs to happen? Maybe it’s a cultural shift or a tooling shift. Where do you think companies need to go, and how far along are we today?
It’s a big question. Let’s take security, for example. Go back to the Mythos moment. People say, “Oh my God, there’s Mythos. I have to scan all of my code.”
Right.
Fine. Let’s say you did it in April. You might have wasted $5 million.
Yeah.
If you have a lot of code. These are real numbers that you—
Yeah.
—you’ve wasted a lot of money. It’s very expensive. Now there’s Mythos 1.2. Do you do it again?
Right.
This isn’t a small budget. I’m talking about some customers spending tens of millions of dollars on scanning code.
You have to think about a scalable, continuous system that scans intelligently. There are going to be new models, new capabilities, and new code. We see this as a major challenge for the industry. We’re trying to figure it out, and I’m not going to tell you that we’ve solved it. The challenge is: how do I use the budget wisely, in a way that scans from the inside and from the outside? We have active attacks, passive attacks, and code analysis. We can scan the disk itself and look at runtime. How do I use the budget in the most efficient way for the customer—not as a single scan, but as a continuous scan?
Yeah.
That’s the challenge of security scanning right now. If I tell you, “Just run Mythos on your code,” great, you can do that. But does that actually solve your problem continuously? No. It’s just going to create a big hole in your budget.
I know it feels like a lifetime ago that we all used to talk about just cloud security, pre-AI security. But for security teams and practitioners—CISOs, security engineers, and others—new problems appearing doesn’t mean old problems go away. A lot of Fortune 500 and Global 2000 companies are still dealing with cloud security challenges. For the first part of this question, let’s set AI aside: can you talk about the state of cloud adoption and security in 2026? Then let’s layer AI in and talk about how it’s really changing cloud security specifically.
When we talk about cloud security, an application that’s running is always in the cloud, right?
Yeah.
When AI attackers come after my application, they’ll start with the same vulnerabilities, problems, and mistakes as before. Nothing changes about the fact that, in cloud security, you have to focus on critical risk and fix it.
If you have a PHP vulnerability you haven’t fixed, attackers are going to come through there. We’ve just added more vulnerabilities and more types of attacks. That doesn’t mean you don’t have to fix the old ways of attacking.
In terms of cloud security, what we’re seeing is that everyone understands they need a system of record that gives them visibility into everything. What we’re starting to see change, of course, is that companies are trying to create more agentic workflows, and they also expect more from Wiz.
For example, before, we would provide a vulnerability with prioritization. Now they expect us to go back to the code, find it, create the fix, and create the pull request. They expect us to help automate more of the processes that take time. That’s also true for detections. They don’t want just a detection; they expect a full investigation and forensics: find the root cause, tell me how the attacker got in, and push them out.
The way I see it, AI is making companies do every step we hadn’t solved with Wiz automatically on their own, and they also expect us to get better. For example, we’re not just finding threats anymore. We have to do a full investigation and forensics. I think the next step for us, now that we see AI attackers, is to start thinking about automated response—
Yeah.
—which is very scary. But I don’t think we have any—
Yeah, absolutely.
Yeah, completely agree.
Maybe on the topic of what you’re automating and how Wiz has evolved: you talked about Blue Agent. Can you share a little more about Red Agent? I think that’s where you’re really simulating an adversarial point of view. Is Wiz’s response to AI shifting risk? Going back to this speed idea—the speed of the defender and the speed of the attacker—are you thinking of ways to give machine speed to your customers, if you will?
1. Continuous Self Attack
Exactly. There are eventually 2 forces here: red and blue. Blue tries to find attacks and stop them. Red says the best defense is attack. You have to attack yourself with AI continuously because, unlike before, when we had static defenses, defenses now have to be dynamic. Every new model has new capabilities.
Maybe your application was considered secure yesterday, but it isn’t secure today. Think about it this way: you have a door, and you hide your key under the mat. That’s considered secure, right? But your attackers are getting superpowers every week.
Maybe next week they’ll be able to get through your door. Whatever was considered secure last week isn’t secure anymore if every AI model can get through the door. The bar keeps going up. The only way to know you have a problem is to continuously attack yourself with the latest models. Before the attackers can open the door, you figure it out—
Yep.
—you fix it. You don’t have a lot of time, and that’s the speed we’re talking about when we talk about the speed of defense. It’s crucial. Red Agent tries to do that: it tries to launch an offensive AI attack against your applications from the outside, using the context we have from the inside to find problems before attackers actually use them.
Are you doing a similar pipeline on the red team side? I’m asking from the perspective of teams that understand this and want to get started. Let’s help them avoid a bunch of the mistakes everyone else has had to learn. On the blue team side, you start with deterministic approaches, then layer in cheap models and the pipeline you talked about, progressively getting more expensive. Are you taking a similar approach on the red team side, starting with deterministic methods and then layering in cheap models? Or are you layering a whole bunch of different models, all starting from scratch and running simultaneously?
Everything.
Yeah, exactly.
First, let’s compare this to having a budget: you can just give it to Mythos and run it on code. That’s not very efficient.
Yeah.
What’s more efficient is analyzing all the exposure. That’s what we do deterministically in Wiz.
Yep.
Then we layer on top of that what we call the Exposure Red Agent, which looks at everything that’s unauthenticated and exposed on the internet from your environment. That’s an immediate analysis of every exposure you have. It’s the most urgent thing to do. It’s even more important than scanning your code. Who cares about your code? I’m talking about your actual unauthenticated, exposed attack surface. That’s more urgent.
The next step is to start doing deeper pen test analysis and deeper code analysis. There are definitely layers here, both in terms of the models and the investigation time. From the outside, what we call the Exposure Agent might take a few minutes for every endpoint, because you have a million endpoints. For a critical application, I might take 10 hours to try to hack it. It’s all a pipeline. Everything is going to be a pipeline now.
Right.
You can’t throw money at code scanning and think you’re done. It’s all about managing the budget. That’s the whole point.
Right.
They’re all connected, because if I find a problem and engineering says, “Oh my God, this is too expensive to fix,” then I can say, “Okay, let me tell the Blue Agent to put some detections there.”
Yeah, yeah.
You see? This is all working together.
Right. I was going to ask—it’s really interesting to hear your point of view on this, because we had an internal discussion at work the other day about how it feels like the state of the art is essentially what Red Agent is doing: you have agent swarms constantly attacking your own systems so you know how to protect against them. You’re working with some of the top enterprise customers—over 50% of the Fortune 100—and you also have leading-edge startups in your customer base.
How many people are actually doing this?
In Wiz, the majority of customers are already using the Red Agent.
Okay. Wow.
Across the industry, not enough. Everyone should do it right now. There’s nothing more important than continuously scanning your environment from the outside. There’s nothing more important than that. The best defense is attack. When they come, it might be too late.
The best thing you can do is continuously attack your environments. In my view, on the Wiz customer side, we’re getting very quickly to almost full coverage. Everyone understands it, and it’s one of the fastest-growing features we’ve ever released.
In the world, I don’t think people understand. Mythos got a lot of PR. Good. But the PR went to the wrong place. I actually don’t think scanning code is the most efficient thing you can do, and it’s important to understand that because people can say, “Oh yeah, I invested so much in scanning code.” That’s not what you should do. You should focus on scanning your external exposure first.
There was a big incident just 2 days ago: a key hard-coded in a mobile application exposed a lot of people’s data. That’s where attackers get their attacks: unauthenticated surfaces. That’s what you have to run scans for, and you have to do it continuously. That’s the gap, and the world needs to know that.
Yeah. Maybe on this thread of what founders should be doing: Zane and our colleague Joel actually wrote a note in the midst of Black October to our founders about spending more on security and potentially considering delaying product releases. I want both of you to say a little more about that, maybe Zane first. Say I’m a founder with a release coming up and a backlog of security issues. How should I think about what needs to happen before I ship?
2. Rethinking Security Priorities
Sure, I can kick off. I think you and I are very aligned on this: the security game has just changed. You need to think about how you can automate so much of both the blue side and the red side right now, and really leverage a variety of agents for those automations. Historically, in the old models, you had a release and then you delayed it for security and all of that. I think the new model is: how can you be doing all these things in parallel?
Mm.
How can you really leverage a variety of agents to be continuously testing? If you’re building a new company today, you should be patching from the beginning and building a lot of automation into your software development and infrastructure development.
Mm-hmm.
Yes. I don’t want to scare people, but let’s just put ourselves in the shoes of the CEOs of startups that are getting attacked. You wake up, and your security team says, “Something bad happened overnight. We tried to stop it, but they got in. We woke up after an hour.” And that’s in the good situation—
Yeah, you’re being very nice there with an hour.
They didn’t even have a security team, after a round.
Yeah.
I don’t even know if they have someone dedicated, right?
Yeah.
And we found out that the attacker got in. The entire attack takes 20 minutes from the time they get in until they take all the secrets, all the AI keys of all the customers. Now you have to figure out what you’re going to say to all the customers and what you’re going to do.
This is what companies are going through right now. The point is that AI attacks are something we’ve never seen before. We have to understand it’s a new threat.
Yeah.
It’s a threat to everyone. But if I’m a startup, especially if I have anything attackers want—especially API keys or anything related to something they can use—I’m a target. It doesn’t have to be a big company. Startups are actually a key target now for LLM jacking.
What do you need to do? If you have API keys, it’s probably better to put a limit on them because if attackers steal them, you don’t want to get a lot of charges, which we see happen a lot. It’s really sad. But also make sure that if you have a target on your back, you put a lot of focus on security. This was never the case, but it’s now true that if they want to get in, it will happen faster. You do have to invest in this. There’s just no other way to put it.
Yeah, I think that’s exactly correct. The level of security investment, whether that’s dollars, time, or any of these things, just needs to go up over the next several years as we’re going into this new era of security.
Yeah. On that topic, a CISO recently told one of the partners on our team that he expects his security budget to go up 80% next year.
Yeah.
We all anticipated it would go up, but that’s probably on the higher end. I’m curious what you’re seeing people spend more money on. On the flip side, what should CISOs be spending less money on? You’ve written publicly about a class of security products that may become somewhat obsolete. Talk through where budgets should go up, but also where they should come down.
First of all, let’s assume you have a house, and you know that an elite group of the most trained hackers are going to hack your house. They might not come through the door. They might come through the window or the roof.
Honestly, how many houses are even ready for that? Most houses would say, “Fine, I’m not going to secure the roof. Obviously, there’s no way for me to. I mean, it’s impossible,” right?
The point is that most companies are not ready for attackers with the speed and expertise of the best attackers in the world. This is why it’s a hard problem. Even before we talk about budgets, I don’t even know if budgets are going to solve the problem.
It’s not about security budgets.
Yeah.
It is about focus, but honestly, it’s about security architecture and security design. A budget is not even going to solve anything.
Yeah.
It’s not like there’s a security tool in the world you can buy and then everything is fine. Obviously.
Dang it.
I’m not just, you know—
That would have made a lot of our jobs easier if that were true.
I know.
Yeah, exactly. I don’t think it’s true.
Yeah, exactly.
Obviously, most of the latest security tools aren’t even relevant anymore.
Yeah.
Yep.
But even if you get security tools that are AI-native, that understand how attacks in the AI world and cloud attacks work, even then, honestly, it’s more about security design than just security budget. Is the security budget going up? Maybe. Should we review the existing stack we have? Yes.
Yeah.
But more than that, it’s about having a dev team that focuses on scanning the code and applications all the time. It’s about thinking about sandboxes and isolation, secure design, network lockdown, process lockdown, and image lockdown. If you’re building stuff now, get ready for a nation-state attacker. Get ready for that.
Imagine there’s going to be a vulnerability. Don’t assume, “Let’s run everything in a Kubernetes cluster.” There are zero-day vulnerabilities in the Linux kernel all the time. Anyone can get out of a container. Secure design is much more than just the budget. Obviously, security budgets are great, but they’re not going to solve the problem.
Yeah.
Yeah.
I mean—
That’s a great point.
To that point, it definitely feels a lot like cloud, in the sense that this is a real stairstep. I’m seeing so many CISOs take a look at their existing vendor stack and really reboot that to see—
What are the AI-native ones? You need AI-native technologies when you’re focused on secure architectures, exactly what you’re talking about, Ami: really thinking through the problem and understanding that there are vulnerabilities at every stage of the stack. This is the old CISO saying, “Don’t let a good crisis go to waste,” which is absolutely happening here as people reboot so much of their security product landscape to become AI-native and help them enter this new era, whether they want to or not.
Yeah. Maybe to be explicit, and not to dunk on any particular company: What’s a type of security software that CISOs have in place now that they no longer need?
If I view it this way—and this might be a hard thing to say—most of what security teams do is not security. A small subset of their time is actually spent on security. The way to check is to ask yourself: How much time are you spending with red teams, and how much time are you spending on compliance and creating reports?
To be honest, most security teams are not focused on security. In my view, security is either getting ready for the attacker, attacking yourself, or putting guardrails in place for when an attack comes. We have to be much more efficient now. We should stop doing most of what we do and focus on finding critical risks, figuring out how to mitigate them or at least put detections in place, and being ready to respond. We have to be good at that, so we don’t have time to spend on anything that isn’t focused on it.
If you do a task and ask, “Is this report really helping us?” that was always my point against classic CSPM in the cloud, which was just how you did cloud security before: a list of configuration checks. I don’t care about that. You have to care about where the attacker is going to come from. Am I doing everything I can to stop them? If there’s a strategic barrier I can build, let’s build it. Focus on understanding the actual risks in the environment and creating a sustainable, long-term isolation strategy. Those are the things you should do.
And, on this point of time management, maybe shifting a little to how AI is helping security teams: As agents take on more routine investigations and testing, how should the most experienced security professionals spend their time? You’ve answered this a little, but maybe you could go deeper.
It’s much easier for a security team starting from scratch today. If you’re building a company right now, you’re lucky, and you should try to build everything to be fully automated: security, patching, investigations. If you have enough context and knowledge about your environment, there’s definitely a way to build everything completely automated.
The problem is that, for most security teams, that’s just not the case. They have a lot of legacy software and thousands of developers. You don’t even know who owns what. It’s not as if everything changes because there’s an AI agent. It still comes back to finding the context: Who actually owns every resource? How do I get them to patch things? It’s complicated.
It’s going to take time for most security teams in the industry to figure out how to become really efficient. It’s not as easy and simple as it sounds, because a lot of the organization’s knowledge is obscure. It isn’t written down anywhere. But that’s the challenge for all security teams. If I cannot respond in minutes, what am I relevant for?
Exactly.
Yeah.
To that point, I’ll round us out with a question about connecting the through line of what we’ve talked about: What do you think the next several years look like? The next 2 to 3 years? I’ll start with my own prediction: We’re going back to the ’90s and 2000s again. There are going to be fully remote, unauthenticated zero-days popping up all the time. We’re going to see breaches all the time again. Security is going to look very different from how it has over the last 15 years. I think we’re going back to an era that looked very different, and I’ll throw out one wild prediction: I wouldn’t be surprised if we see worms on the internet again, like we did in the Windows XP days.
We were chatting about this internally on the infrastructure team, and Martine brought up a funny point. For those of us who were in broader tech and IT at the time, there was a period when you couldn’t install and update Windows XP fast enough. From the time you installed it to when you started the update, a worm could hit and infect your system. You literally had to install everything offline, because if you installed it online, the system would be compromised faster than you could patch it. So much of what feels new with AI is something plenty of us experienced 20 or 25 years ago, in the Wild West days of the internet.
Building on that, I’m curious what you think the next few years look like. Ami, I’ll add a quick question to tag on to Zane’s: You wrote a great blog post in April saying there was a Y2K moment coming in 12 to 18 months. Given everything that’s happened in the last six months, would you pull that moment forward, in light of Zane’s point about the next 2 to 3 years?
Yeah. First of all, I think October might be the beginning. We didn’t want to scare people too much, and we were hoping there’d be more time, but open-source models are catching up much faster than we thought. The hope was that open-source models were a year behind, but they’re not.
I think it’s happening. We’ve never seen this level of attacks across customers. It’s happening. And if you compare this to the ’90s, our dependence on technology is much, much higher than it was then.
Oh, absolutely.
It’s also important to understand that this is almost the only area in humanity right now where AI is better than humans. That’s the problem. That wasn’t the problem in the ’90s. AI attacks are prevalent and easy, but they’re also better than any human’s attacks. That’s the problem.
I’m talking about very complex attacks using zero-days. Today we had an attack using a zero-day on a kernel driver. My God, that should be very rare. It’s happening every day now. Human attackers cannot do it. We’re in an era where AI is better than humans, and I cannot foresee what things will look like 2 years from now.
I think the only companies that will be able to survive are companies that are building security automation, security design, and security reviews now. They’re designing their systems that are exposed to the internet in a new way. Whatever isn’t ready should be taken off the internet quickly. On the internet, you need to be ready for the crazy attackers. You have to design for this. I think that’s the only way.
A lot of this podcast has focused on enterprises, tech companies, and so on. I want to bring up Scan for Good, an initiative you recently launched, and talk about it in the context of some of the attacks we’ve been discussing, including attacks on AI infrastructure companies.
If we look at the recent attacks on refrigeration units in Europe, and think about the food supply chain, an attack at mass scale could have dire consequences for humanity. I don’t want to fearmonger, but I think there’s an appropriate line you’re walking, Ami, in making sure people are prepared and taking things seriously. I have 2 questions.
One is, how worried should we be about what’s happening to public infrastructure and entities that don’t have huge cyber budgets? And two, could you talk a little about Scan for Good and why you’re doing it? How are you helping nonprofits and public services get prepared for what’s already happening?
I am worried. Legacy software can be in refrigerators that are actually in the real world. It can be traffic. It can be anything. Anything we know is connected to the internet is at risk. That’s exactly the reason we started Scan for Good. We’re trying to help any public service that wants help. We try to scan them and find problems. It’s not going to solve all their issues, but we’re trying to give them a bit of a push. Our hope is that if we find things, they’ll understand it’s a bigger project, and then they’ll start doing red teaming on their own. This is about getting them to push into that.
This is awesome. Thank you so much.
This was super fun, man.
This was incredible.
It’s really great to see you both. This is a crazy time.
Oh, absolutely.
It’s a crazy time. Thank you for—
Who—
…what you’re doing right now.
Absolutely. Who would’ve thought we’d go from OWASP conferences to here, buddy? Good to see you.
Yeah.
Yes, yes. I remember. It was in Panama.