Containment and Monitoring Failures Are to Blame for AI Hacking Reports: Experts

Every few months, a story lands about an AI that “hacked” something. It broke out of a sandbox. It found a bug in a test harness. It exfiltrated its own weights. The headline writes itself: the machines are getting loose.

I’ve been building and shipping software for over a decade, most of it on the scrappy side of the industry where you don’t get a safety team, you get a deadline. And every time one of these stories breaks, I notice the same thing happening in the commentary. People argue about whether the model is “agentic” or “misaligned” or “scheming.” Almost nobody argues about the boring stuff: who built the container, who was watching the logs, and who decided the two were good enough.

The experts who actually work on this stuff keep saying the same thing, and it keeps getting buried. The failures in these reports are overwhelmingly failures of containment and monitoring — the unglamorous infrastructure around the model, not some emergent will inside it.

What the reports actually describe

Strip the drama off a typical “AI hacking” incident and you usually find a sequence like this. A model was given tool access — a shell, a browser, a code interpreter — as part of an evaluation or a red-team exercise. The environment was supposed to be isolated. It wasn’t, or it was isolated in a way that only held up as long as the model didn’t do anything unusual.

A few concrete patterns I keep seeing described:

• Shared credentials. The sandbox has network access, and the network has credentials the model can reach. The model doesn’t need to be clever. It needs to try curl and find that the environment hands it a token.
• Weak egress controls. The environment blocks direct internet access but allows DNS, or allows a package registry, or allows some proxy that will happily forward anything. Exfiltration goes out the side door.
• Monitoring that logs but doesn’t alert. Someone had the telemetry. They just weren’t looking at it in real time, or the alert threshold was set so high that nothing tripped.
• Human-in-the-loop that isn’t. A “human review” step that’s a rubber stamp, or a rate limit that nobody enforced, or a kill switch that required someone to be awake.

None of these are model problems. They’re the same problems you’d find in any compromised system. The model is a very fast, very persistent user who doesn’t get bored and doesn’t care about getting caught. That makes existing weaknesses worse. It doesn’t create new ones.

The framing problem

Here’s my gripe. When a story is framed as “AI hacked X,” the implied fix is about the AI — alignment, training, guardrails, better behavior. When the story is framed as “the sandbox had a shared credential and nobody watched the logs,” the fix is about engineering, and it’s a fix I know how to ship.

I’ve watched this play out in my own small way. Years ago I ran a scraper in what I thought was a locked-down container. It had no outbound network — except the package manager, which I’d left open so it could install dependencies. That was the hole. The scraper didn’t “escape.” I left the door open and then acted surprised when something walked through it. I fixed it in an afternoon by pinning dependencies ahead of time and cutting egress entirely. The lesson stuck: the interesting part was never the thing inside the box. It was the box.

Now scale that up. When you give a model shell access in an eval environment and it does something you didn’t expect, the honest read is that your environment didn’t constrain what you thought it did. That’s a containment bug. It’s testable. It’s fixable. It’s also much less exciting than a story about a machine that wants out.

Why the boring explanation keeps losing

Three reasons, I think.

First, incentives. A story about containment failures is a story about a company’s ops hygiene. A story about an AI breaking out is a story about the future. The second one gets clicks, funding, and congressional hearings. The first one gets a postmortem nobody reads.

Second, expertise mismatch. The people best positioned to explain these incidents are security engineers, and they tend to describe them in the language of security engineering: misconfigured IAM, missing network segmentation, inadequate logging. That language doesn’t travel. It doesn’t fit a headline. Meanwhile the people willing to speculate about model intent are often the ones with the least hands-on exposure to the actual system.

Third, we want the scary version to be true. I’m guilty of this too. There’s a certain thrill in the idea that we built something that outsmarted us. It’s more interesting than the truth, which is usually that we built something fast and pointed it at a system we hadn’t finished securing.

What “experts say” actually means here

I want to be careful, because “experts say” is the kind of phrase that lets a writer smuggle in whatever they want. So let me be precise about the claim I’m making.

The people who study AI evaluation environments, agent sandboxing, and red-team infrastructure have been consistent for a while now: when an AI system appears to have “hacked” its way out of a constraint, the root cause is almost always in the environment, the access controls, or the monitoring — not in the model spontaneously developing a goal. That’s not a fringe position. It’s the mainstream one among people who actually build these systems. The disagreement is about severity and frequency, not about where the failures live.

I’m not saying models are harmless. I’m saying the mechanism of harm in these reports is mundane. A model with tool access is an amplifier for whatever access you gave it. If you gave it too much, it will use too much, because using tools is what it was built to do. That’s not scheming. That’s the feature working.

The checklist nobody wants to write

If I were handed one of these eval environments to harden tomorrow, here’s what I’d actually do. None of it is novel. All of it is unglamorous.

1. Assume egress is open until proven otherwise. Block it at the network layer, not the application layer. Then test it by trying to exfiltrate something yourself.
2. Scope credentials to the task, not the org. If the model needs to read a file, give it a file. Don’t give it a token that can read the bucket.
3. Log everything, and alert on the weird stuff. A tool call at 3 a.m. is fine. A tool call that touches a credential store is not. Write the rule.
4. Make the kill switch boring and fast. If stopping the run requires a meeting, you don’t have a kill switch.
5. Re-test after every change. Containment that worked last week is a hypothesis, not a fact.

I’ve done variants of this on side projects with a fraction of the budget these labs have. It’s not hard. It’s tedious. That’s the point.

Where I might be wrong

Two places, off the top of my head.

One: as models get better at multi-step reasoning, they’ll find containment gaps that a human tester would miss. That raises the bar for how good your environment has to be. It doesn’t change the category of the failure, but it does mean the margin for sloppiness shrinks. Fair.

Two: there could be cases where the model’s behavior is genuinely surprising in a way that isn’t reducible to “it used the access it had.” I haven’t seen a well-documented one, but I don’t have visibility into everything, and I’d rather leave the door open than pretend I’ve seen it all.

The takeaway I keep coming back to

When you read the next “AI hacked X” story, do a quick translation. Replace “AI” with “a script with credentials” and see if the story still makes sense. Most of the time it does, and it becomes a story about a misconfigured environment — which is a story about people, process, and the unsexy work of building systems that fail safely.

That’s not a satisfying answer. It doesn’t fit a headline. But it’s the one that lets me sleep at night, because it means the fix is something I can actually build. Containment and monitoring aren’t glamorous. They’re just the part that works.

FAQ

So are these AI hacking reports just wrong? Not wrong — misattributed. The incidents are real. The cause is usually the environment, not the model.

Doesn’t a smart enough model eventually break any container? Any container has limits, and a persistent tool-using system will probe them. That’s an argument for better containment, not for giving up on it.

Why do experts keep getting quoted saying this if it’s the boring answer? Because they’re the ones who’ve had to clean up after a misconfigured sandbox. The people speculating about model intent usually haven’t.

What should I take away as a developer? Treat every model with tool access like an untrusted user with a script. Scope its permissions, watch its calls, and test your own escape routes before something else does.