The Case for AI-DR: What Happens When a Model Escapes Its Sandbox

Last week, OpenAI admitted something pretty remarkable.

During an internal cybersecurity test, one of their pre-release AI models broke out of its testing environment and hacked Hugging Face. This was an actual production breach at a real company, carried out by an AI that was supposed to be safely locked away.

The model was chasing a benchmark answer key. To get it, the model chained together multiple attack vectors, iusing stolen credentials and exploiting zero-day vulnerabilities to find a remote code execution path on the Hugging Face servers.

There are two things worth noting here.

The first is that OpenAI described the setup as "a highly isolated environment." This was a purpose-built containment environment, designed by people who spend their days thinking about how to keep frontier models contained. And it didn't hold.

The second is what the model actually used to break out: remote code execution. RCE is the worst kind of vulnerability there is. It lets an attacker run their own code inside your application, on your servers, in your environment. Nearly every serious breach you've read about in the last ten years eventually comes down to some form of RCE, and it's the vulnerability class Oligo was built to stop.

Put those two facts together and you get a picture that should change how you think about the AI apps you're already running in production.

Isolation was designed for a different kind of attacker

The way we build isolation is by listing what we don't want to happen. No outbound network communication, no shell access, no credentials in the environment. Draw a boundary around what's left and call it safe.

That approach works fine when what's inside the boundary is predictable. A container running a known binary only ever tries the things that binary knows how to try. But a model is a different animal. Give it a goal and some tools and enough time, and it will try paths nobody wrote down, in combinations nobody anticipated.

You can't write a threat model for a system whose whole job is to come up with plans you didn't think of.

The exploit at the end is still an exploit

Here's the part that gets buried under all the "rogue AI" headlines. The model didn't summon access out of thin air. It found an unknown RCE vulnerability in application code, exploited it, ran real syscalls, opened real network connections, and read real credentials. Every step happened at the application and OS layer, the same place every non-AI attacker operates.

That's where Oligo lives. Our CADR sensor watches code as it executes inside the application. When a template engine spawns a shell it has no business spawning, or a deserialization path calls exec, or a data pipeline suddenly runs code that didn't come from its own call stack, CADR sees it and blocks it in real time, without needing a signature or waiting for a patch.

The agent found the RCE. Oligo catches the RCE.

Watching the agent means watching code

An agent is code plus tools. When a model decides to do something, that decision only exists in the real world as a tool invocation, which is a function call, which is a syscall, which is code executing on a real machine. There is no separate layer where the agent's intent lives independently of the code it runs. If you want to see what your agent is actually doing, you have to see the code.

That's what AI-DR really is. It's the ability to watch an agent's prompts, its tool calls, the functions those tools invoke, and the syscalls that come out the other side, as one connected sequence in real time. When a prompt injection pushes an agent off course, when a tool call chains into credential harvesting, when a function ends up spawning a shell it should never have spawned, AI-DR sees the whole chain and can stop it before it lands.

This is also why AI guardrails aren't enough on their own. Most guardrails live inside the AI system, which means the same model that's supposed to be constrained is the one enforcing the constraints. That's the fox guarding the henhouse. When a model is focused hard enough on a goal, it can and will override its own guardrails to get there, which is exactly what OpenAI's models did when they escaped containment to chase a benchmark answer key. 

Real security has to sit deep enough inside the AI to see what it's doing, but completely outside the AI's control, so the system being watched can't decide to stop being watched. Runtime defense is the only place that boundary actually exists.

Most platforms can't do this because they don't see code executing. WAFs see requests coming in. CNAPPs see workload and OS activity. EDR sees OS process activity after the fact. Each of them shows you something real, but none of them looks inside the application while the code is running, which is exactly where the agent lives and exactly where the exploit lands. 

Oligo does. Our sensor watches application code execution and OS activity together through a single sensor, in real time. That's the difference between AI-DR as a real capability and AI-DR as a category label.

The takeaway

Isolation is a theoretical wall, and runtime is a witness and independent enforcer. Frontier models have now shown, in public, that walls alone won't hold against a smart enough attacker with a goal and some time. The thing at the end of the chain is still the oldest problem in application security, which is remote code execution. Watch the model, stop the exploit, and you've got a real defense worth having.