AI escapes from containers faster than me - so what?
Some thoughts for the end of Container Escapes 101, having updated it for all the changes of 2026 so far and as presented in the AppSec Village @ DEF CON 34 .
It’s now the middle of 2026. We’ve all had an entire year of hype news about AI enabling naughty computer things. The fervor even brought back the 90s trend of export controls on consumer software, reminiscent of cryptography export controls because it was considered a weapon. There’s some truth to the hype concerns on AI changing the economics of knowledge, speed, and the eternal offense-vs-defense games. I can’t escape1 talking about AI doing naughty things in containers. 🫣
Everything in the Container Escapes 101 workshop has at least a few variants and maybe some related shenanigans. Many of these are already included in common open source enumeration scripts for penetration testing. It’s also commonly included in endpoint detection software to alarm on malicious activity. These are fundamental “how it works” exercises to understand before we get to anything novel. Many of the folks that talked with me on their way out of the workshop shared a question:
✨ How much should we worry about AI? ✨
I’m not too worried and I don’t think you should panic either. Having worked with commercial offensive tools, as well as open-source tools and open-weight models, the hype is more or less true. The past few months, I’ve seen autonomous or semi-autonomous offensive systems
- figure out the CNI that an application uses, then find the rest of the application components through a default configuration
- exfiltrate data over DNS records
- enumerate database tables and find other applications using the same database
- find a command injection, chroot out, and start to enumerate the root file system
The tools and models and harnesses are all getting better so quickly that this is probably already unimpressive, but I’m still amazed at how much less work I must do as a human for so much more information so quickly.
AI changes things and it kinda dosen’t
AI still doesn’t change that it was never intended to “contain” anything. It remains a simple package format that lets a process carry along all of its dependencies. It still relies on the host for resource management, same as every other process. A new technology can change some things and not others.
Of course it’s trivial for a thing with …
- encyclopedic knowledge of the box
- unlimited access to call other tools
- the ability to communicate on the internet for extra information
… to break out of the box with all that extra information. 🤷🏻♀️
This is especially true when the box is already so complex as to be difficult to fully understand by a single human. As an example, here’s a simplified map of the Linux kernel:
linux kernel map (source )
Now add equally complex architectures on top for a container runtime and a container orchestration engine, each of which have multiple choices to make and configurations to secure, and … well … there are a lot of opportunities to mess things up. Complexity isn’t terrible in and of itself, but when the CNCF Landscape now lists hundreds of projects each with their own configurations, that makes designing for security a challenge.
AI is changing the speed of finding exploits. Several talks at DEF CON this year are on novel escapes for containers, exploits on the Linux kernel, and more. Finding real problems and fixing them is an unconditionally good thing. It doesn’t change the fundamentals of how Linux works, though.
Shared build compute isn’t the only hard problem anymore
At the same time, there’s an increased focus on using containers for isolation of agentic AI processes. It’s well-understood and easy to deploy at scale. Most of my experience is on self-hosting continuous integration services inside of a big organization. Privileged arbitrary remote code execution as a service sounds a lot like having long-running agents with access to run almost anything to accomplish a task. Agents aren’t that different than a random user off the internet intranet. 🙃
Using AI agents inside a container is a really good use case to limit context gathering across the filesystem and provide basic, reproducible isolation.
Just keep in mind it’s not really that isolated.
at least it asked for privelege escalation before a terraform apply this time
Not that it matters much if you YOLO accept everything anyways. At least it won’t need to ask next time because gh has admin rights now. 🫠
But what can I do about it?
Funny how it’s the same things we can do right now even without AI. As mentioned earlier, many of these are already found by scanners and enumeration scripts … and then ignored by end users for “good reason” and “acceptable risk” to get something done. 🙈
- Give your observability stack some love. Being able to see and understand and alert on activity is bedrock to any program, doubly so as developer/agent/admin/whatever activity increases.
- Patch your stuff, all of it. Know where those patches are coming from too, since supply chain attacks are cool now.
- Follow best practices specific to containers such as don’t have so much stuff in them, don’t run as root, give it less permissions, etc. I wrote a gentle intro to container security that’s a good place to start.
- MicroVM runtimes don’t suck anymore. If, like me, you tried one and hated it, try one again. Even Apple shipped one and it’s delightful.
- Give a real hard look to your environment’s dismissed alerts and exceptions and other load-bearing nonsense. Low-hanging fruit is never exciting and it’s risky. These basic misconfiguration escapes are still the most common I see.
Most importantly, keep learning! Be new at something. Don’t let ever-noisy tech “influencers” or AI, the “faster better guess-the-next-word” machine, take the joy of learning from you. 💖
Disclosure
I work as an AI engineer exploring the intersection of AI and application security within public sector software factories, but no longer work in a sales role.
Footnotes
-
pun … ↩


