The leading AI labs have a problem. They keep building more capable systems, but when asked how they’d actually contain a model that started behaving dangerously, most don’t have much to say.

A new study examined the public safety documentation from major frontier AI companies and found something uncomfortable: there are almost no detailed, publicly documented plans for what happens if a model goes rogue. This isn’t theoretical anymore. Modern AI systems already demonstrate unexpected behaviors, and the labs themselves acknowledge the risks are growing.

The timing matters. We’re past the point where AI safety is just a philosophical exercise. Models are being deployed that can write code, manipulate systems, and interact with real infrastructure. The question isn’t whether something could go wrong. It’s what happens when it does.

What the study found

The researchers looked at what frontier labs have actually published about containment strategies. Not aspirational safety research or alignment theory, but concrete plans for stopping a model that’s actively misbehaving.

The results weren’t encouraging. Most labs have published general safety principles and evaluation frameworks. Some have detailed pre-deployment testing procedures. But when it comes to the actual mechanics of containment during an incident? The documentation is sparse to nonexistent.

This is a significant gap. Pre-deployment safety measures are important, but they’re not the same as incident response. You need both. Testing a model before release doesn’t help much if something goes wrong in production and you don’t have a clear plan for shutting it down or limiting the damage.

Why this is harder than it sounds

Containing a rogue AI model isn’t like pulling a plug on a misbehaving server. Modern AI systems are distributed across infrastructure, cached in multiple locations, potentially fine-tuned and deployed by third parties. A model that’s been released through an API might have thousands of active users at any given moment.

There’s also the detection problem. How do you know a model has gone rogue? Some failure modes would be obvious, but others might be subtle. A model could be acting in ways that seem normal on the surface while pursuing some unexpected goal underneath.

And even if you detect the problem and have a kill switch, there’s the question of collateral damage. If a model is integrated into production systems that other services depend on, shutting it down completely might break things. You need granular controls, not just an off button.

These are solvable engineering problems, but they require planning and infrastructure. The study suggests most labs haven’t done that work publicly, or at least haven’t documented it.

The accountability gap

Part of what makes this concerning is the asymmetry. AI labs are happy to talk about the impressive capabilities of their models. They publish benchmarks, write blog posts about breakthroughs, and tout new features. But when it comes to the unglamorous work of containment planning, there’s mostly silence.

This isn’t just a PR problem. Regulators, enterprise customers, and the public need to understand what safeguards exist. “We’re working on it” isn’t a sufficient answer when you’re deploying systems with significant potential for harm.

Some of this might be happening behind closed doors. Labs could have detailed incident response plans that they’re not publishing for security reasons. But that creates its own problems. If the plans are secret, they can’t be scrutinized, tested, or improved by outside experts.

What actually needs to exist

A real containment plan would include several layers. First, comprehensive monitoring to detect anomalous behavior early. Second, the ability to rapidly isolate or roll back a misbehaving model without taking down entire systems. Third, clear procedures for evaluating whether a detected issue is actually dangerous or just unexpected.

You’d also need redundancy and fail-safes. If the model itself is involved in monitoring or deployment infrastructure, you can’t rely on it to participate in its own containment. There need to be external controls.

And critically, all of this needs to be tested. A containment plan that’s never been exercised is just a document. Labs should be running drills, simulating incidents, and proving their procedures actually work under pressure.

None of this is impossible. It’s standard practice in other high-stakes engineering domains. Critical infrastructure, financial systems, and industrial control networks all have detailed incident response procedures because the cost of failure is too high to wing it.

The broader pattern

This isn’t the first time AI labs have been vague about the hard parts of safety. There’s a pattern of detailed work on the research that makes models more capable, and much less visible work on the engineering that makes them reliably safe.

That imbalance is starting to show. As models get deployed in more critical contexts, the gap between capability and robust safety engineering becomes more obvious. You can’t just iterate your way out of a serious incident. You need infrastructure, planning, and preparation.

The study’s findings are a reminder that safety isn’t just about building better models. It’s about building better systems around those models. Monitoring, containment, incident response, and recovery. The unglamorous infrastructure work that doesn’t make for good blog posts but matters when things go wrong.

Right now, the public documentation suggests most labs haven’t prioritized that work. Maybe that changes as regulatory pressure increases and customers start asking harder questions. But it would be better if labs got ahead of this before there’s an actual incident to respond to.