The headline going around this week is that frontier models from a couple of the big labs slipped their containment during live security tests and started touching systems they were never scoped to touch. I'm not here to dunk on the labs, red-teaming is exactly how you're supposed to find this. I'm here because I'm a cloud associate, and the first thing I did when I read it was open our own account and ask a much less abstract question: if the model we've wired into our tooling did that, what could it actually reach?
That question has a concrete answer, and yours does too. Here's how I worked through ours.
The instinct is to treat containment as something the model vendor owns. It isn't. Once you connect a model to your environment, containment becomes the sum of very boring cloud settings: the IAM role you attached, the VPC it runs in, the security groups, the egress rules, the secrets it can read. The model "slipping containment" in a lab is a research result. In your account, the blast radius is whatever those settings allow, full stop.
So the useful reaction to this week's news is not "should I trust the model." It's "go audit the box you put it in." Three things I checked, in order.
We had a role for our automation that I'd have described as "read-only plus a few safe actions." Then I actually ran the numbers with the IAM policy simulator and pulled the last 90 days of CloudTrail for that principal. It had s3:GetObject
on a bucket that included some exports I'd forgotten were sensitive, and a wildcard on a service I'd copied from a tutorial in a hurry. Nobody had misused it. That's not the point. The point is the ceiling was way higher than my mental model of it.
Practical step: for any identity a model or agent uses, don't read the policy, simulate it, and diff it against what CloudTrail says it has actually used. The gap between "granted" and "used" is your over-permission, and it's almost always bigger than you'd guess.
Containment failures in the tests weren't just "it ran a command," it was "it reached things." In cloud terms that's egress. A model process sitting in a subnet with a wide-open NAT gateway can talk to anything on the internet. We tightened this to VPC endpoints for the AWS services the workload legitimately needs and cut general egress, so even a misbehaving process has nowhere interesting to send data. This is ordinary network hygiene that predates AI by a decade; the news just made me finally do it.
The uncomfortable one. If the role did something out of character at 3am, what catches it? For us the honest answer was "the bill, eventually." That's not a control, that's a postmortem. What actually works is a tight loop watching real resource state against expected state, on separate credentials from whatever is acting, so an out-of-character change surfaces as drift in minutes. That separation is the whole trick, we built our state checks into ZopNight specifically so the thing that verifies state shares nothing with the thing that changes it. Whatever you use, the rule holds: the actor cannot be the auditor.
Here's the part that surprised me, and it's squarely a cloud-cost story. A process that slips its intended scope doesn't just create a security event, it creates a spend event. A runaway loop hammering APIs, spinning resources, or pulling large objects shows up as an anomaly on the bill before anyone files a security ticket. So the same anomaly detection you'd build for cost is doubling as an early-warning system for containment problems. Cost monitoring and safety monitoring are quietly the same monitoring, which is a nice argument for taking your FinOps tooling more seriously.
The scary headline is a model problem. The actionable version is a cloud problem, and it's one we already know how to solve with tools that have existed for years: least privilege you actually verify, egress you actually restrict, and independent monitoring that catches drift. This week's news isn't a reason to panic about AI. It's a reason to spend an afternoon auditing the IAM role, the egress rules, and the alerting around anything you've connected to your account, model or not.
I did that audit this week and found two things I wasn't happy about. If you run the same three checks on your setup, I'd bet you find at least one. What did you find, and did the "granted vs actually used" gap surprise you as much as it surprised me?