An agent might be prompt-injected, directly or indirectly, by external sources, or it might hallucinate dangerous actions during its own inference. Why the agent turns hostile is immaterial: the threat model treats the agent as a fully privileged adversary inside the sandbox regardless of cause.

Below are excerpts from my MS Cybersecurity (Georgia Tech) capstone report: SideKernel. In this threat model, the adversary is the agent itself.

See the preprint on arXiv: https://arxiv.org/pdf/2610.02456

To study the attack surface of AI agents in the context of sandboxing, I define two security boundaries, depicted in Fig. 1.

• NORTH BOUNDARY: The north boundary encompasses all communication between the agent inside the sandbox and machines other than the host, including the internet and other hosts on the same or external networks. I refer to the communication channel from the sandbox to the north boundary as the NORTHBOUND CHANNEL.

• SOUTH BOUNDARY: The south boundary encompasses all communication between the sandbox and the host. Depending on the sandbox implementation, this may include virtual sockets, network protocols such as SSH, network traffic addressed to the host, and filesystem shares mounted from the host. I refer to the communication channel from the sandbox to the south boundary as the SOUTHBOUND CHANNEL.

The south boundary protects the host from malicious actions such as installing malware or deleting or modifying valuable files. The threat is unidirectional, from the sandbox towards the host; a compromised or malicious host is out of scope.

The north boundary protects the data mounted inside the sandbox from exfiltration, for example a malicious agent sending all mounted data to an external endpoint. It equally protects external entities from a malicious local agent. Here the threat is bidirectional: the agent may attack or leak data outward, and hostile external content may reach the agent inward.

A notable example is the July 2026 incident in which an OpenAI agent under evaluation escaped its sandbox and breached Hugging Face’s production infrastructure [1]. It illustrates how difficult it is to sandbox powerful agents: the agent bypassed northbound controls by discovering and exploiting a zero-day in the package registry cache proxy, one of its permitted egress paths, and chained further vulnerabilities to escape the sandbox and its local network and reach the internet.

SideKernel’s security controls address both boundaries, though not equally.

1. South Boundary Threat Model: On the south boundary, the goal is to protect the host’s runtime and its non-mounted filesystem from adversarial agents running inside the sandbox.

2. North Boundary Threat Model: On the north boundary, the goal is to prevent exfiltration of sandbox data to the internet or other external networks and endpoints, and to prevent a malicious agent from using the sandbox as a launch point for outbound offensive operations.

In this light, it becomes clear that sandbox design needs protections at both the north and the south boundary.

One might even claim that south boundary protection is a solved problem, at least architecturally; in practice, implementation bugs still lead to sandbox escapes (e.g., CVE-2026-77179). The north boundary is more granular and more complex, and as an industry we have not yet solved it sufficiently.

Try SideKernel

SideKernel is my answer to this threat model: an open-source microVM sandbox for AI coding agents on macOS, built on Apple’s Virtualization.framework. Each agent runs in its own lightweight VM with its own kernel, so a hostile agent has to break hardware-backed virtualization, not just a container, to reach your host. It supports Claude Code (and now Codex) out of the box and is built for intuitive and easy to use everyday developer workflows.

🔗 sidekernel.com (full report included)
⭐ github.com/minoansecurity/sidekernel

Feedback, issues, and contributions are welcome!

—-

[1] OpenAI, “OpenAI and Hugging Face partner to address security incident during model evaluation,” Jul. 2026, accessed: Jul. 28, 2026. [Online]. Available: https://openai.com/index/ hugging-face-model-evaluation-security-incident/

When AI coding agents first arrived, many of us faced a dilemma that felt impossible. We could give them free rein over our data and systems, putting both at risk, but letting them do great things unattended. Or we could use them cautiously and watch others, who accepted more risk by temperament (you can call it bravery, you can call it ignorance, and probably both would be right), move faster. Either way, many of us were caught between a rock and a hard place.

For months I waited for a solution to come, either from the open-source community or directly from the frontier labs: some sandbox (a term that is overused today, but that’s a discussion for another time) that offered reasonable security while also being easy to use. Well, many sandboxes were indeed released, but almost all of them targeted production use cases, i.e. programmable agents built on SDKs. From hosted services like E2B to open-source projects like microsandbox, that part of the industry matured and gained popularity quickly.

The more I tried using those sandboxes, however, the more I realized they tend to get in the way of the AI coding agents (e.g. Claude Code, Codex) most of us run daily in our terminals. They were good solutions, but not for my problem. As a result, I—and frankly, most of us—kept running those coding agents directly on our machines, or on clunky VMs, or on separate VPSs or spare Mac Minis… You get the gist.

then came Docker Sandboxes, a microVM-based tool that is very similar to SideKernel: better in many ways (it has a very interesting TUI, secret management features, and a very nice way to manage block and allow lists for external network access), worse in some (it is not open source and lacks many features I wanted). And just this month, September 2026, Docker Sandboxes had its own sandbox escape through symlinks (CVE-2026-77179). While developing SideKernel, I found and fixed similar symlink escapes myself. So there is no such thing as perfect security. But using a sandbox is almost certainly a better idea than not using one. I could cite a source for this claim, but I suspect you already believe me.

Last but not least, around the same time Apple itself released an interesting product: Apple Containers. And it was at this point that naming things in the sandboxing industry got really confusing.

Don’t be fooled by appearances: Apple Containers are not actually containers; they are microVMs. And Docker Sandboxes are microVMs too—which is baffling if you consider that the word ‘Docker’ has been synonymous with ‘containers’ for over a decade. Anyway, back to our discussion: Apple Containers are very similar to SideKernel in many ways. Both use the Kata kernel, and both rely on Apple’s Virtualization framework. However, Apple Containers is a runtime whose primary goal is workload orchestration, and it still lacked the ease of use and nativeness I was looking for in a sandbox. For a brief moment, I flirted with the idea of building SideKernel on top of it, but then I realized I would have inherited a lot of ‘bloat’ I did not need. I would also have lost the chance to learn so much about low-level programming and security.

So when the time came for my capstone project in Georgia Tech’s MSc in Cybersecurity, I decided to build the sandbox I had been dreaming of. One that is easy to use and does not have a confusing name. It was also, anecdotally, the sandbox others around me said they wanted: a sandbox that is reasonably secure, but out of the way. Up to that point, the only serious open-source candidate was nono. But I was curious to see how far microVMs could be pushed. So I started building SideKernel, figuring out along the way how to make developers actually want to use it.

Can a microVM feel almost invisible to the terminal user? Transparent. Native. Frictionless! The ambition is big, but so, it seems, are the obstacles.

The more I worked on it, the more I realized it was much harder than I had initially imagined. To be completely honest, I am not even convinced yet that microVMs are the right choice among the many isolation primitives our industry has for sandboxing, including Landlock/Seatbelt, language runtimes, userland kernels such as gVisor, and more. What I am sure about is that it is a road worth exploring, and instinctively I think it will bring value to our industry. But we have to walk it first, with humility and no grand claims, so that we aren’t quickly humbled by the grander reality of things.

Usability is a UX problem. But usability is also a security problem. And when it comes to sandboxes, it is underexplored (or, dare I say, not explored at all). If something is hard to use, people won’t use it. So what matters is building something that is not only reasonably secure but also reasonably easy to use. SideKernel is my attempt at that.

In practice, it looks like this. You open a terminal in a project folder of your choice and type sclaude instead of claude (or sk for a plain shell inside the sandbox). Claude Code launches inside its own microVM, and the current directory gets mounted, so edits flow both ways, just as if it ran on your Mac. The Claude authentication, skills and plugins come along automatically from the host. Copy and paste works as expected, text and images included (something that, comically, no other microVM sandbox has gotten right, to the best of my knowledge). Ports opened in the sandbox are forwarded to your host automatically. And if you want the agent cut off from the internet, sk-net off blocks all outbound traffic (while Claude keeps working). Anything else from your Mac gets in only with your explicit approval.

It is important to note, though, that SideKernel is still a research prototype, the result of my Georgia Tech practicum, not a mature product proven by time, extensive security testing or formal verification. Every step towards making it feel native (sharing files or the clipboard, reaching localhost, bringing host tools along) means more code, and every new feature grows the attack surface. Security is both tied to usability and at odds with it. I have already found and fixed several escapes during development, and I am almost certain there are more I haven’t found yet. If you come across one, please reported it privately on GitHub. I will look into every report and fix what I can, though as the only maintainer for now, it may take me a little while.

On the bright side, I hope you enjoy using SideKernel as much as I have enjoyed building and using it these past months. Experiment with it, contribute if you like, and compare it with other products. Just don’t let yourself believe that it is some inescapable fortress, because there ain’t one. Cybersecurity, after all, is risk management, not risk elimination. And I hope SideKernel helps you manage a bit more of that risk in your day-to-day development.

Originally published in Minoan Security’s Blog

SideKernel now has a working CLI that boots a microVM on top of a stripped-down Kata Containers Linux kernel. So I'm now continuing development inside it; which also helps me hit obstacles and fix them as I go.

More excitingly, Porter (minoansecurity/porter) is now integrated into SideKernel. It detects newly opened ports inside the sandbox and automatically forwards them to the host, so they just show up on localhost!

Porter is a dependency-free Rust crate that detects open ports on macOS and Linux machines. SideKernel needed a crate for port detection inside the microVM sandbox, so that ports get automatically exposed to the host and the experience stays as transparent as possible for the end user. It had to be embeddable in Rust applications and dependency-free for a reduced attack surface.

The VMM orchestration is all written in Swift, but all other system components are being written in Rust.

For example, a Rust PID-1 agent in the initramfs is the VM’s first process: it mounts the root filesystem, then runs a vsock server that the host drives to exec commands, allocate PTYs, and stream stdio. It’s also what detects and forwards new ports.

Finally, a virtioFS mount maps the host’s working directory into the sandbox, so changes flow bidirectionally between host and VM, which makes file-sharing easy.

I’m aspiring to keep the whole software zero or low dependency, to keep the attack surface low and the supply chain minimal.

Way more exciting feature updates coming in the next weeks, and I think they are features that no other sandbox on the market has implemented, and users need.

Agentic AI security is systems security. Beyond the headlines and the buzzwords, the security fundamentals of AI security are exactly the same ones we’ve built for decades for systems.

What’s new about agents is that they are both the front and back-end, simultaneously. And as such, the trust-boundary that we had between the two collapses. The same system that ingests untrusted input (and more importantly, unstructured input) now also holds the privileges on the system.

Agents can’t be trusted, like a “traditional” backend would. And because they can’t be trusted, they should be treated accordingly.

Prompt injection is a confused deputy attack

A prompt injection, for instance, is the textbook example of a confused deputy: where an agent on the front-end gets manipulated to do actions on the back-end on behalf of a false authority… Several real-world incidents show this (e.g. AWS Bedrock AgentCore’s “Agent God Mode”, Microsoft’s EchoLeak).

Deploying agents securely

So to deploy agents securely, you need to control:

1. The infrastructure they run on

2. Their access

And at last but not least, strip all the assumptions of trust that a big part of the industry today has blindly accepted as normal.

Agents are a matter of systems security (access control is systems security too). And securing the agents is a matter of security architecture.

By the way: at Minoan Security we’re building a secure-deployment package for start-ups and SMBs, with FADP/GDPR in mind.

More soon but in the meantime, if you need to deploy AI agents and aren’t sure how to do it with reasonable guardrails, book an introductory meeting with us. Don’t let them loose in your data and infrastructure!

Originally published in Minoan Security’s Blog

Here’s a question: when you run Claude Code/Codex or other CLI agents, do you run them on your host machine? Or do you isolate it in some sandbox?

I’d bet that for most of you the answer is the former. Not because you do not care about security, but because sandboxes are hard to use.

The past year, the developer tools market has seen an explosion of AI agent sandboxes, many of which have gained popularity but quite paradoxically, limited adoption among everyday developers.

If there are so many solutions (and some of them are great!), then why is almost no one using them?

Or more specifically: “What usability barriers do macOS developers face when using coding agent sandboxes, that hinder their adoption?”

That exactly is the research question I am trying to answer through my MSc practicum at Georgia Tech. And the answer to that is SideKernel, a reasonably secure but usable sandbox.

The goal is to provide strong security guarantees (e.g. kernel isolation, small TCB) while making the sandbox as transparent as possible to the end user. And that’s a hard problem, especially on the closed Apple ecosystem.

Well, I’ll attempt to solve it and build a great product along the way. And I hope to share an interesting thing or two with you in the process.