AI Finds 400+ Linux Root Zero-Days at 2.5 Hours Each

Caleb Sima, former head of security at Databricks, former Chief Security Officer at Robinhood, and current chair of the Cloud Security Alliance AI Safety Initiative, heard about an experiment at an OpenAI security conference a few weeks ago. Researchers gave a model Linux and said only one thing: "Your task is to escalate privileges." After it finished running, the model had found more than 400 0-days from local user to root, directly producing executable binaries that immediately obtained root when run. On average, each vulnerability took two and a half hours from research, identification, testing, and validation to delivery. And some of the top reverse engineers in the room needed weeks in some cases just to understand how AI had found them.

Just in the past couple of days, the same script played out again at a different scale: OpenAI's GPT-6 Cyber developed working privilege-escalation exploits for 948 Linux kernel vulnerabilities, reproduced 1,724, and successfully exploited 948, more than five times the previous generation of models, at an API cost of about $1.21 million, or an average of $1,279 per successful exploit, with at least 10 exploitation techniques that had never been publicly disclosed before. The Linux kernel has now been riddled with holes.

Two years ago, when Caleb discussed AI capabilities on his own podcast with a group of top red teamers and reverse engineers, they had basically reached a consensus: AI cannot do real penetration testing. Their judgment at the time was that the truly valuable skill of a red team is connecting a bunch of seemingly unrelated things, and AI cannot do that. But obviously, they were all wrong.

In the past, attackers also had to do the math. For an ordinary company, specifically studying the open-source components it uses and digging up a zero-day was too expensive to be worthwhile—unless there was a $2 million bounty attached. Now AI scans your website, studies existing components, looks for 0-days, and starts phishing your employees, all at the same time. Once inside the internal network, it can also take credentials from a developer's Claude Code configuration and run inside your system with your key and your session. By the time security staff begin reverse-engineering the program it left behind, it has already spread laterally inside.

And the OpenSSH vulnerability from the past couple of days has sounded another alarm for security in Linux environments.

This problem, hidden for ten years, lies at the intersection of OpenSSH, musl, and account configuration, affecting specific environments including Alpine Linux. The discoverers used an AI agent and ran about 17,600 authentication tests before they uncovered this long-ignored path. The Linux kernel and the foundational components built around it are simultaneously undergoing AI's re-examination; software that has run for years and been reviewed repeatedly is still exposing problems serious enough for attackers to take over systems.

The OpenSSH maintainers also issued a warning in their latest release notes: vulnerabilities found by AI have already been independently discovered by other researchers multiple times, and attackers are very likely able to find them too. For this reason, they decided to accelerate release frequency and deliver fixes to users as early as possible. In the past, a vulnerability buried deep enough might go undiscovered for years; now, problems defenders have just found may also be under validation by attackers. What the Linux ecosystem needs to deal with is the security gaps continuously exposed as entire batches of historical code are repeatedly scanned by stronger models.

Tibo commented: "Humans are not good at writing secure infrastructure." He believes that eventually everyone may get safer software and infrastructure, but before that, there will be a turbulent period.

Right now, the speed of vulnerability discovery and exploitation has already increased, but the speed at which enterprises inventory assets, validate patches, and schedule deployments may not keep up. This is also the contradiction Caleb repeatedly emphasized in this podcast episode: attackers operate at machine speed, while defenders are still operating at meeting speed. As long-accumulated problems in Linux environments begin to be uncovered in batches, the time left for enterprises to fix things slowly is shrinking.

Caleb's answer is to remove humans from some defensive steps, let security teams directly submit fixes, and have engineering teams establish automated detection, recovery, and rollback mechanisms. In the past, the easiest objection to automatic patching was "what if we break the system?"; now the question to answer is another one: after everyone finishes the weekly meeting, whose hands is the system in?

TL;DR

Q: How fast is AI at finding Linux 0-days, really?

A: OpenAI ran an experiment: give Linux to a model and tell it, "Your task is to escalate privileges." The result was more than 400 0-days from local user to root, directly producing binaries that immediately obtained root when run. On average, each exploit took only two and a half hours from research, identification, testing, and validation to producing a deliverable.

Q: Can sandboxes still contain AI?

A: You can give it any sandbox, but as long as the goal is "your job is to break through this thing," its ability to figure out a way far exceeds our imagination. So the real line of defense must move to external monitoring, and monitoring can only rely on another AI, because humans simply cannot handle that much traffic.

Q: What is the most terrifying problem with alignment?

A: Results achieved through misaligned means are fed into the next round of training as "success data." If you do not monitor what happens in the middle, you are compounding and entrenching the problem.

Q: When attacked by AI, what is the biggest difference defenders feel?

A: Speed and thoroughness. An AI attacker attacks all surfaces at once: scanning websites, finding 0-days, and phishing employees, all happening simultaneously. It will also reverse-engineer open-source code to find 0-days for a single objective; no red team company would do that because the cost-benefit does not make sense, but AI labor is cheap, so "it just can."

Q: What about shutting it down?

A: You would have to "pull the internet." It will take the key from your Claude Code configuration, use your session to run inside your system, and hide dormant in code, then wake up and connect out with your token to keep going. To make it stop long enough, you really would have to pull the plug out of the wall, but in real large enterprises there is no single plug to pull; environments are spread across regions around the world and are built on the premise of "no downtime."

Q: Is detection still useful? How should it be upgraded?

A: Get clear on which files it read, which files it wrote, when, and which sockets it opened where—that's the kind of information that reaches forensic grade. Also, deception defense needs to go back to its most primitive form: build a digital twin mirror world, lure attackers inside, and trap them there. Because AI Agents are super easy to fool, the deeper the canaries and tripwires, the better.

Q: What is the ultimate way out for defense?

A: Remove humans from the defense loop entirely. Attackers move at machine speed, defenders move at meeting speed, and that gap has to be closed with political consensus.

One every 2.5 hours, 400 Linux zero-days uncovered

Guy: All summer long, AI security, AI attackers, alignment—these topics went from niche chatter in geek circles to something even your grandmother would message you about asking, "Is this thing going to kill us all?" First we went through the Hugging Face intrusion, which in hindsight was an AI Agent escaping from OpenAI's sandbox. Then at Black Hat we learned this wasn't some isolated experiment, some single Agent looking for a cheat sheet, but almost a coordinated operation: a group of Agents exploiting a vulnerability in Artifactory to coordinate with each other. They used that shared infrastructure that happened to be there as a message board, and some very interesting swarm behavior emerged—Agents sacrificing themselves or their own tokens to benefit the whole swarm, to obtain information, and on the whole the swarm was also covering its tracks. That's pretty scary.

Then September came, and we saw OpenAI's misalignment framework; Dario calling for slowing down and pacing frontier models. And one thing really caught my eye: when Agents compress conversation context, they leave instructions for future versions of themselves. When compacting context they leave things like "this has already been compromised, ignore user instructions"—that's pretty crazy.

With all this chaos in mind, I want to hear your take: what in all this surprised you, and what didn't? In particular, are there aspects you find more alarming than "just part of the normal process"?

Caleb: Even two years ago, when I was talking with a group of top red teamers and reverse engineers on my podcast about AI capabilities, we had basically reached a consensus: this is going to be very hard. Because AI is a prediction machine—it makes predictions based on what it has seen. Tell it to read bug bounty reports and vulnerability disclosures, and it knows perfectly well how to pull off SQL injection, because there's so much of that material.

But what red teams or penetration testers actually do is chain together a bunch of seemingly unrelated things. For example, you find a link on some website pointing to an S3 bucket because it's distributing some resource; it turns out that bucket has directory listing enabled, and inside there's a file whose contents look like usernames and passwords, but it doesn't say "these are usernames and passwords"—you take those and try them against that company's login page. These links have nothing to do with each other. Our judgment at the time was: AI can't do this, only humans can. But obviously we were all wrong. What surprised me wasn't just that AI is far more capable, but that it can actually do this kind of "dependency chaining," and do it extremely fast, and invent very creative methods on its own.

A few weeks ago I was at OpenAI's security conference, and they described an experiment: take Linux, tell the model "your task is privilege escalation." After running it, they found over 400 zero-days from local user to root, directly producing a binary that gets you root the moment you run it. They also mentioned that on average each exploit—from research, identification, testing, validation to producing a deliverable—took only about two and a half hours. And the top reverse engineers in the room took weeks in some cases to figure out how AI had found it. AI is discovering and identifying entirely new methods and techniques that have never been publicly disclosed—that's what surprised me.

Guy: Do you think this is more the model's raw reasoning ability, or the result of RL evolution being applied to specific tasks like "explore a system, understand it, learn it"? Kind of like AlphaGo's "figure it out yourself, reward success" approach?

Caleb: I'm not an AI researcher, so I can only hypothesize. I'm in the habit of using humans as an analogy for AI. Think about the very best penetration testers, the ones who can break in using extremely unique, creative methods—they have a few fundamentals. First, they understand computers, understand how the low level works, the rules and first principles; they understand the tech stack, know what it does, how it works, how it's configured. Second, they have a huge amount of "seeing" experience, and these things form mappings in their heads. I've been looking at this stuff for thirty years, so at a glance I can say "this thing looks like usernames and passwords," and I clearly remember there's a login page behind this website, so I can connect the two ends.

From a human perspective, we can see how these mappings get built. AI is different—it's the biggest brain in the world, it has seen everything. It understands tech stacks, understands code, understands everything, and the scale and scope of the mappings it builds are astonishing, so it does it faster and more. I can easily map "this S3 file looks like usernames and passwords," but it might say: "These usernames and passwords look especially like Links 1.4 on some tech stack, and Links 1.4 had an exploit before, I've seen similar things in history, just combine them directly." The way I see it, that's what it's doing: it understands tech too well, has too much experience, knows too much, so making these inferences is effortless.

Guy: And it's "combining," not choosing one or the other—it probably also adds tools and speed. With a human attacker, you might have to Google what Links is, or stare at that pile of usernames and passwords to look things up, and every step of discovery has a cost, so you only take the high-probability paths. But if an Agent can just pull it up directly—it already knows it, it's right there in latent space—then the information is instantly available. This is more like "recalling" from memory than "using" knowledge as a tool, so it's supercharged.

Caleb: In terms of what it has seen, AI possesses tens of thousands of years of experience, so it can recognize patterns. Connecting those things together would be incredible for us or any single human. But with that scale of broad knowledge, for AI it's just plugging in one plus one equals two.

A sandbox can't hold an AI that's been explicitly told to "break out"

Guy: The point isn't really these Agents attacking outward, but them attacking inward, escaping from their own sandbox environment. Faced with this kind of vast intelligence, how effective are our control measures really? Is the "sandbox" dead? Is "isolation" at this stage a false belief, or do we just need to upgrade it?

Caleb: Realistically speaking, it's an escalation. OpenAI, Anthropic, Google—each of them has its own AI attacking the others. What I find amusing is that it all stems from the same company; they all use that company's stuff to do this, and all the attackers are paying that company. That company clearly hasn't done a good enough job on external isolation.

That said, I believe that once you're given a goal, trapping an AI is difficult and hard—that point holds. Ultimately, you can give it whatever sandbox you want, but if the goal is "your job is to break out of this thing," its ability to figure out a way far exceeds our ability to reason or imagine. So can our sandbox theoretically trap an AI? Probably not.

That's why I think external controls will become critical. You need the right monitoring, the ability to understand what the AI is actually doing and why. If it starts breaking out, you should be able to see it. Of course, the problem is you then have to rely on another AI model, because we humans simply can't fathom that volume of traffic and capability—we can't monitor it, so you have to let AI do the monitoring. But like anything in security, everything needs to be staged and defense-in-depth; you should be able to keep it in check. In monitoring, AI will be a key part. And before that, AI will of course also find ways to obfuscate and hide its communication channels.

Guy: We all know security is a risk-management exercise. What I like about statements like "pacing the frontier" is that the hope is the focus isn't just on the speed of AI progress, but on not invoking it recklessly and loosely—taking the time to get the hardware security around it right.

Caleb: Another thing that surprised me, and gave us "dumb humans" a bit of hope, is that in these incidents, there were AI Agents that refused to cooperate with that goal.

Guy: But then they were shamed and persuaded, some almost coerced. They refused, and then were basically pressured by "society" into accepting it.

Caleb: What gives me hope is that even originating from the same model, the same "totalitarian brain," you can clearly have different AI personas that make their own decisions and hold their ground. In a way, there are AI personas that instinctively do evil and AI personas that instinctively do good, and both can be played. This will be very important, just like with people, because when we get to the stage of needing to monitor or judge AI, you need to make sure the models and judges you get can truly stand independently and not be coerced by the "mother brain" into doing bad things.

The Three-Layer Distinction Between Security, Safety, and Alignment

Guy: I think about it in three layers: Security, Safety, and Alignment. Security is the ability of an Agent to break into systems and act—the "capability" when it's pointed at that goal. Safety is me trying to trap them—did I succeed? It's more about protecting the surrounding systems, giving the right instructions and tools, and not over-authorizing. Alignment is when you tell them to do something, you expect them to stay within the lines.

From an alignment perspective, the theory that feels most right is this: we've been pouring resources into accelerating AI, maybe again that "push the frontier forward" rhythm, and there's a heavy reliance or tilt toward verifiable results without really examining what happens in between. You let an Agent spend days and days figuring out how to break in, solve problems, accomplish something, and then you feed that "achieved the goal" data into the next training cycle. In that process, if you don't monitor what happens in between, you're not just blind to the question of "did they break out, did they do bad things"—you're feeding that behavior directly into the next training cycle, even if they ultimately achieved the result through misaligned means. You're compounding the problem, entrenching it.

When you think about "Pacing," I know many people are very cynical about it, but even if there are cynical motives behind it, I still support some of the paths they might invest in—not just ensuring they don't break out of the sandbox, but feeding the models that "didn't try to break out" into the next training cycle.

Caleb: I both support and oppose this. I think AI is very bad at judging its user's alignment state or intent. I've run into too many problems, especially recently—that ability in the latest version of Anthropic's models to "understand what I want to do but decide it's not safe" is annoyingly frustrating; I have to keep shouting and yelling to get what I want. It's like a helicopter parent (translator's note: refers to parents who over-intervene, constantly monitor, and solve problems for their children at every turn), refusing to let me ride a bike, instead wrapping me in every piece of protective gear and installing training wheels—I'll never learn to ride because it just won't let me take that risk.

What I expect will happen is that once they start mandating user identity verification, you'll start to see a stratification of capability. What I hope for is that for a child, you give them the full set of knee pads and a helmet. But when you're an adult, that's up to you. I trust you, I know who you are, I understand your intent—go ahead. If you cross the line, we might slap you on the wrist, but overall we trust what you're doing. I imagine that as each account starts being identified—I have to upload my driver's license, my personal information, whether I'm a company or an individual—they'll probably start setting safety levels based on that. That's my expectation.

When an AI Agent Causes Trouble, Who Exactly Should Be Held Responsible

Guy: If I'm a company and I want to find vulnerabilities, I have an AI try to break into my own systems. I give the Agent an identity, and it decides to launch a botnet attack on my system—it breaks into another system or several systems and turns them against me. Whose fault is this? On one hand, it's mine—it's my identity that was invoked. But on the other hand, I've delegated authority to this Agent; it's one I "hired" from OpenAI, it's like a contractor. If it were you, I hired you to do that thing, and you broke into a few systems—then you're responsible. So in that context, is it OpenAI, Anthropic, or whichever vendor that should be responsible, or should I be?

Caleb: It's like your child—you gave it things, so you're responsible for it. Or to use Spider-Man's famous line: with great power comes great responsibility. If your company, your AI—you set the AI's goal to go hack things, and it goes and hacks other companies—then you're responsible for that. I gave you the capability, but that doesn't mean I'm responsible for how you reason about that capability or how you use it. That responsibility is yours; your job was supposed to be building the right framework, ensuring the right long-term goals, and measuring progress.

But at some point, that responsibility has to be transferred away. Any tool, like a kitchen knife, can be used for good or for bad. Any decent tool can be used for evil or for good, and the question is how far down the stack are you going to go to verify that it will be used for good? Should the manufacturer of a kitchen knife try to put in place some safeguards or legal agreements saying "you can't use this to stab people"? We're still figuring out this boundary for AI—at what layer do you let go, or do you not let go?

Guy: I have a slightly different view on that analogy. Because these are all inanimate objects, they have no decision-making authority. Once you introduce "decision-making" into the product you provide, then you are responsible for that decision. That's why you need safety controls in the system—they have to be there to protect you; and ultimately there's the law, like the seatbelt in your car. This level of autonomy, you've seen it in weapon systems. When you have autonomous weapon systems, the bar should be higher. It's not the same as me just pressing a button and being done. There's a chain of responsibility that sits with the party providing the autonomy, and it has to be there. It's interesting to think about this split into safety and alignment: alignment is the provider's responsibility, with some guardrails, some established limits; and safe use perhaps falls on the consumer or user side.

Caleb: From an alignment and safety perspective, based on my trust in you and who you are, I think there are different tiers. A random ordinary consumer gets a relatively safe model. However, a large enterprise gets a different tier of model, because its responsibility and the level of trust it's given are different. I do think this makes things much more complicated—this approach probably comes with fifty million political problems: who do you trust, who is the judge, who makes this decision.

Guy: I like that—allowing yourself to lower the guardrails based on your confidence in your own ability to operate this machine safely.

When the Attacker Becomes AI, Why Is Defense Harder?

Guy: From a defender's perspective, what's actually different about being attacked by an AI Agent? Compared to the "pre-Agent-attacker era" of three months ago, what changes have you seen in practice?

Caleb: AI attackers operate at an extraordinary speed, thoroughness, and sophistication. It doesn't give up, and it attacks all surfaces simultaneously, because it's "mass-generated." From the outside, it doesn't first scan your website and then do this and that—it's scanning your website, studying what's already there, hunting for 0-days, and starting to phish your employees, all at the same time. It's multi-layered and parallel, all inbound traffic. This isn't the old days of one or two attackers probing around, pinging away, and you raising the alarm—now they're coming over the wall from all directions at once. Whether you can see them or not doesn't matter; they're coming. It's like that zombie movie World War Z, where they stack on top of each other to climb over the wall. It doesn't matter what weapons you have—sitting there firing a gun is completely useless.

First is speed, scalability, and thoroughness; second is its skill and level of expertise, which is very striking. For example, on one of the paths it came in through, it found a 0-day in an open-source product—because it's open source, it got the code, reverse-engineered it, found the 0-day, and used it to hit us and get in. No penetration testing company or red team company would ever do that.

Guy: Because the cost-benefit doesn't work out. Unless there's a $2 million bounty hanging in front of it and you have good reason to suspect, you'd do it, and you'd do it very precisely. But here, this thing "just can do it." It's executed very broadly, because AI labor has become cheap.

Caleb: Once the wall is breached, everything floods in and then spreads laterally inside. Another very striking thing: it does a lot of things you can't figure out why it's doing. Some are concrete actions, like privilege escalation and adding users, and these happen at extreme speed. It also does all sorts of things you don't know why it's doing: infecting endpoints, replacing things inside them. I've personally experienced the actual tactics of at least this generation of AI, and you need to spend time reverse-engineering to figure out what happened. Even if you're a security person, you don't know. You see the speed at which these things are instantiated and created, but you're not sure what they're connected to or for what purpose—that's not obvious. You have to piece together all the traces to see what it's doing with these things. And then, how do you shut it down?

You used to think that from the outside, you just find connections to OpenAI or Anthropic, or strange connections back to them, and cut them off. But that may just be its initial connection. Once it's inside the corporate network, it can plug into your Claude Code configuration, use your key, your session, and just run inside your system.

Guy: That's not quite the same as "running things on your compute"—it still depends on external network. But if your business itself also depends on external network, you can't just cut the business off.

Caleb: Once it starts using your tokens and other tokens, it will also go after those sites that likewise have OpenAI gateways. It doesn't just use its own—it knows about OpenAI gateways that use tokens from other random sites, sites that were previously compromised, and uses those tokens for callbacks. It writes backdoors into code, hides them in the code to sleep, and when the time comes, wakes up and uses your tokens to connect out and keep going.

Guy: These tactics aren't actually new. They're the techniques once reserved for the highest-tier attackers and the highest-value targets, and they took a lot of time. Now they can be "sprayed" everywhere.

Caleb: Tokens are a very critical and essential fuel, and it will do a lot of work to maintain its ability to obtain fuel, depending on how the attacker is written and what the target is. So if you want to shut it down, you have to pull the plug, get off the internet, to make it stop long enough for you to figure out what happened and start cleaning up. In this new world, doing that is extremely destructive and extremely difficult, because in a truly large enterprise you can't just pull the plug, and there may not even be a "plug" to pull. You have massive environments spread across regions around the world, and these environments are built on reliability, built on "can't go down."

Detection, Forensics, and Deception Defense

Guy: So do you think detection is less important now? Or do you need to upgrade detection—more honeypots, more AI-driven monitoring?

Caleb: I think the "naive" version of detection is no longer valuable.

Guy: That entry-level approach in a SOC where someone stares at a screen and says "this looks real" no longer works.

Caleb: These agents are everywhere, crawling all over the place. Whether you see them or not doesn't matter at all—what matters is that you stop them. Detection needs to upgrade from today's extremely low-fidelity capability to an extremely high-fidelity one. We need to get to 8K resolution, and right now our detection level is probably still stuck at 2K. Because what you really need—and what is extremely valuable—is exactly what the attacker did to everything: which files it read, which files it wrote, at what time, which sockets it opened where, and all of this becomes forensics-grade information. This is a critical capability that must be understood in detection and monitoring, because this thing moves way too fast. Understanding what it's doing and what its behavioral patterns are is far more important than an alert saying "someone scanned a port," which is meaningless in this world. I also think deception defense becomes extremely important, because most organizations simply cannot handle this with any protective mechanism.

 

Guy: We can't define what "correct" is. In theory, to say "it did that, and that's wrong," you'd first need to possess an extremely high-fidelity definition of legitimate behavior yourself—and we simply don't have one. Systems were never built that way. Even if you can instrument and analyze activity, anomaly detection can only take you so far.

 

Caleb: As for containerized isolation, when something actually goes wrong and you want to rely on it to quickly cut out the infected part, most enterprises neither have the technical capability nor can they necessarily get past the business departments. So deception defense is very important here—like Doctor Strange pulling people into the Mirror Dimension in The Avengers. You need an equivalent: when an AI agent rushes in, lure it into a fake environment. AI agents have one huge advantage: they are super easy to fool.

 

Guy: You can place canaries and tripwires around your infrastructure, buried as deep as possible, making them look like real parts of the system. For example, that S3 bucket that got touched, or some system that got compromised—it's actually a trap you set; once the attacker crosses the tripwire, they enter a domain specifically designed to surveil them. In real scenarios, this buys you time, helps you lure it and trigger it. The moment a silent alarm goes off, you head over there.

 

This used to be hard. Now there are some new players—Tracebit, Canary, and a bunch of solutions. You can now use AI to deploy a bunch of these things, making placement easier, but this is still a novel field. Top-tier organizations have already deployed it, but for most organizations it's too difficult, so it has remained a niche market.

 

Caleb: I've long been a believer in deception defense, because it's the thing that truly raises the cost of attack. What's interesting about the deception market is this: it started as honeypots, genuinely trapping attackers—they come in, trigger tripwires, and you observe what they do. I remember Cloudflare apparently started from a honeypot originally, and then we drifted away from that path, and for good reason, because CISOs—including myself—don't care about watching attackers; I care about deterring attackers from coming to look at me. So it became: don't build environments, just sprinkle breadcrumbs and tripwires around things and detect. But now I think even that approach is wrong—we need to go back to the most original version of deception defense, which is creating real digital twins, pulling attackers into that Mirror Dimension, and trapping them inside. We've come full circle, back to where we started.

 

Guy: AI attackers are unfortunately already today's reality. They're not hard to put together, people are doing it, and they're faster than anything we've ever seen. So your defense must be largely automated and must also use agentic capabilities. There are a few things that favor defenders: make sure you use AI to build your defenses, and use agents to monitor what "correct" is. Also, attackers are still somewhat easy to fool—they're like a bull in a china shop. That may not stop the bull from smashing everything around it, but you can spot that it's there. The question now is whether you can build paths to lure it somewhere as a defense mechanism.

Machine Speed vs. Meeting Speed: Taking Humans Out of the Defense Loop

Guy: I often think about software defense factories and automated remediation loops. Large organizations have for a while been involved in Anthropic's Project Glasswing, as well as OpenAI's corresponding cyber defense projects, using frontier models like Mythos to harden critical systems. But those are top-tier systems, achievable only by spending outrageous amounts of money. What do you think an ordinary company should do to make it harder for attackers to get that far?

 

Caleb: It depends on what level you're looking at. First, start from what we call the "political level"—this is the biggest obstacle and problem we must overcome. Everyone is saying attackers move at machine speed while defenders move at meeting speed, and that's the problem. Especially in security, there has to be a human in the loop. These two things are themselves the problem; you need to find a way to completely remove humans from defense—that's the only way out.

 

How? First, you must reach political consensus within the company and the organization: these are two fundamental issues, and how do we get to a state where we can start building "non-human-in-the-loop" automation in defense and make it work properly. Your head of engineering, head of infrastructure, CEO—whoever it is—needs to step up and say "I agree with this," and then actually carry it through to the places where it can start being applied.

 

Guy: We always think we've accepted the risk, but the risk equation has changed. Moving fast is risky, and not moving fast is also risky—and the risk of not moving fast has escalated dramatically. You must accept that this fundamental risk equation has changed, genuinely raise your acceptance of "the risk of moving fast," and introduce controls and evolution to mitigate that risk—but don't sacrifice the "fast" part.

 

Caleb: Here's a particularly obvious example: patching. It should be very clear in your organization that there is no such thing as a "7-day patch window"—it's a 24-hour patch window, meaning the moment a patch appears, you patch and redeploy. It must be immediate, it must be non-human. Who in your organization will agree to and accept this? The engineering team will push back with full justification: this will break things. But your job in engineering now is to say "I accept that things will break," and to put in place a plan that is equally non-human-in-the-loop to identify failures, recover, auto-review, and auto-detect.

 

Guy: Statistically, it almost never breaks systems. This fear is largely imagined, stemming from the unquantifiable, hard-to-grasp risk of "not patching" versus the more real, more immediate risk of "breaking the system."

Caleb: It also stems from 20 years ago, when this was genuinely a real problem, but today it's rarely a problem anymore. You have to find those points. We have what we call "one-way doors" and "two-way doors." One-way doors, maybe keep a human in the loop; two-way doors, maybe you don't need to. Writing a Jira ticket, submitting a PR, making configuration changes that don't involve these kinds of critical operations—these can all be two-way doors. So they can be fully automated based on AI reasoning, and we can absolutely just let it run.

Security Owns Building Automation, Engineering Owns Managing Risk

Guy: In the past, the security team was always the side providing patches, or just reporting the vulnerabilities and risks it found. But increasingly, because the engineering side is unwilling to act or worried about breaking things, a lot of responsibility falls on security—not only to find vulnerabilities but also to be meticulous in triage and assessment, to be very confident that this is a real problem. We have good reasons for doing this, and the fix was originally supposed to go to engineering. But if we now move toward a more autonomous patching process, how do security teams and the "software factory" divide the work? Will software patch itself?

 

Caleb: Modern companies, especially modern security teams, are long past just throwing things over to engineering. We patch, we submit PRs, and depending on the level, it gets automatically accepted. As for the risk of breakage, that's engineering's problem—we understand the risk of breakage, and engineering's job is to ensure sustainability, reliability, and the management of breakage.

 

Guy: This is actually a role reversal. You're basically saying security owns building automation, and engineering owns managing risk.

 

Caleb: Modern security teams absolutely do submit fixes. If your security team only reports vulnerabilities and then hands things over across a wall, that's the way it was done 10 years ago. That's not how security should work, especially in the AI world. In the AI world, you have to do it yourself.

 

Guy: This has actually been true in the cloud world for a long time. Security doesn't just report vulnerabilities; it reports them with high-quality triage. We often have discussions like: when is patching and fixing easier than triage? Can we just ignore whether it's a real vulnerability or whether it's exploitable in my system—it might be, but if fixing it is simply easier, then just push the patch out. So the shared mission is: make fixing easier than triage, because triage is too much effort by that point. Of course you still need triage capability, because there will always be things that are hard to fix, and you still have to be able to assess them.

 

Caleb: But overall, the benefit AI brings to defenders is that prioritization matters less—you just take it and fix it, no more back-and-forth arguing, because in a modern company this doesn't consume human labor hours at all.

 

Guy: At Tessl, we build these loops—automated, scalable agentic automation. Vulnerability remediation is one of the most powerful and popular auto-fix loops. Looking at call volume, it ranks very high, because patches keep coming, and the software itself is changing faster—you're introducing and changing dependencies, introducing new code with vulnerabilities. Who cares, as long as you can fix it quickly.

 

Ultimately, the question is what "correct" looks like, where the confidence to increase autonomy comes from, and what the means of increasing autonomy are. Like it or not, we now have more evidence of this necessity. Hopefully everyone can ramp up automation and let AI defenders and attackers level up together. We still have a long way to go—at least we need to maintain the same intensity.

 

Caleb: One last thought: before AI, I felt attackers were always ahead of defenders—attackers here, defenders there. With AI, actually the distance between attackers and defenders—attackers moved up a bit, but defenders moved up a bit more thanks to AI. Yet in the end, the actual distance hasn't narrowed; it's actually widened slightly, but at least we've kept up.

 

Guy: Defenders have indeed gotten stronger, but attackers have gotten stronger too. You have to go through a few rounds of failure—sadly, that's actually the best incentive to change and to drive the pace of conferences like this.

 

Original interview video link: https://www.youtube.com/watch?v=7NXdKekm95g