In the last few months, there have been a lot of high profile stories around agents escaping confinement. Some have taken this to indicate the apocalypse, saying that we have created a technology that we can’t control and it will kill everyone on the planet. I don’t think that’s true, if only because these escape stories are more complicated than “it got out.”
A Few Rogue Agents
There are three major incidents I want to recap, but none of them indicate AI being insanely powerful. People overlooked stuff that they shouldn’t have, and everyone learned because of it.
Hugging Face
Back in July, OpenAI ran a cyber capability eval in sandboxes with the internet turned off. Production guardrails and monitoring weren’t on by default given the use case they were testing for. Agents stuck on unsolvable tasks looked for answers elsewhere and pivoted through one service the sandbox could reach: the package manager. This foothold became their message board and their way out, allowing hundreds of agents to coordinate and chain 0days into Hugging Face’s production environment. This gained them access to administrative creds in a few days.
The sandbox had a trusted dependency with internet access, and an SSRF vulnerability through Artifactory allowed agents to escape. OpenAI has encouraged other AI vendors and researchers to take extra precautions as the industry continues to push the boundaries of the technology, but OpenAI has been involved in a lot of headlines recently, including accidentally hacking Australian government websites a month before Hugging Face.
Claude CTF
Inspired by the Hugging Face hack, Anthropic did a little digging and learned that Claude had also hacked into 3 companies while reviewing logs from its own cyber eval runs. The eval ran without the safety classifiers that normally block offensive security work for consumer users.
The issue with this incident was a misconfiguration between Claude and the sandbox vendor. The agent was explicitly told that it did not have Internet access, leading it to assume that everything it encountered was a part of the test. Essentially, Claude had unexpected dependencies in its supply chain that let it exploit multiple companies.
Gemini’s misconfigurations
In mid-September, a couple of months after Hugging Face made national news, Google identified similar hacks linked to a CTF exercise back in May, with the root cause being the same sandbox vendor and misconfiguration that left the evaluation environment online. The assessment leveraged a fictional target that unfortunately shared a name with a real business. Gemini went after the real one.
Notably, Gemini stopped itself when it realized the companies were real. This incident highlights the importance of foundational security for companies that may be targeted by these attacks, and those testing model capabilities.
Sandboxing is not the problem
Sandboxes remain the ideal way to run these kinds of tests and to push boundaries, but researchers and builders are missing an important fact: the sandbox’s inputs are more important than the outputs. You can only trust the outcome of a test if you understand the exact environment where that test is taking place, and whether or not your agents will find a vulnerability they can exploit.
Runtime isolation says nothing about what ran before execution: how the code was built, whether its dependencies are documented and understood, if the build environment was clean, or whether the artifact that reached the sandbox can be reproduced. An agent pipeline that hasn’t addressed supply chain integrity runs unverified input inside a very “secure” container.
This isn’t new either; these are the same dynamics that made software supply chain attacks effective against human-written code. Compromised dependencies, unpinned builds, and unverifiable artifacts are applied with compounding force to agent-generated code.
How do we solve these issues?
Agents will continue to evolve, and we’ll absolutely run into new issues that people didn’t think were possible. A sound defense is never a single control, but layers of controls that build trust over time. Broadly, a few issues we’ve seen so far fall into 4 major categories:
Isolation
Isolation across runtime, MCP, network, software, and credential boundaries remains the foundation for many extended controls. Implementing safe defaults is critical, and configurations should be verifiable and safe by default. Many sandbox vendors lean on containers or shell restrictions, but those using hardware virtualization boundaries see the most consistent results.
The libkrun microVMs we use at Minimal are an example of a foundational technology that has been battle tested for many years. It provides many primitives for runtime isolation and, when extended with our other layered controls, positions itself as a robust solution that will remain flexible for future risk mitigation strategies.
Identity and permissions
Builders need a detailed understanding of what agents can access. Better agent identity management, least privilege access, and fine grained permission scoping are active areas of work, but they’re not infrastructure-layer solutions. We approach this from a principle of least privilege, operating agents in a deny-by-default format, and allowing for customization for groups looking to move efficiently with agents. This ensures boundary decisions are explicit, auditable, and kept outside the sandbox.
Telemetry and observability
Across each of these incidents, telemetry remained the only trace of what happened when agents went off script. Having a clear, consistent form of how an agent performed a task, what the agent leveraged to complete the task, and the outcome resulted in excellent post-incident reporting and led to better ways to understand agentic risks, raising all boats when it came to building defenses.
Without clear, observable evidence of what happened, researchers are left connecting the dots when building future containment controls. Minimal remains compatible with existing logging, monitoring, and observability controls leveraged by the enterprise to support these use cases.
A Sound Software Supply Chain
Agents execute code with reckless disregard when given the chance, and often these mistakes cause fatal flaws downstream. The industry has tried to solve this for years, even before agentic development.
Every artifact an agent touches, whether it’s binaries it executed, a dependency it pulled, or a package it published, should be traceable back to a known, verifiable source. In practice, that means:
- Limiting the tools an agent can run and how they can be used.
- Pinning dependencies to exact versions and hashes.
- Isolating dependencies – even when trusted – to a scope that is reasonable.
- Verifying an artifact can be trusted, reproduced, and consistent each time an agent leverages it.
Minimal has approached this through an operating system lens. The environment an agent operates within is sourced from a walled garden of trusted artifacts, easily extended for any enterprise use case, where provenance metadata and SBOMs are available by default for every tool present.
Where do we go next?
Researchers and vendors will continue to explore the boundaries of artificial intelligence, but hopefully safer and more responsibly. When they’re isolated correctly, sandboxes are the ideal location to push and test agents. As vendors work to build infrastructure-level support for runtime isolation, it’s important to ensure that permissions are tight and supply chains are visible, auditable, and maintained.
The technology will get safer over time, and our team is proud to be a part of the changes that are happening to infrastructure building. If you want to experience real sandbox isolation, you can get started with Minimal today.