markdown formatted blog content

Why You Should Isolate Your AI Coding Agents in MicroVMs (And How to Do It)

Let's be honest: AI coding agents have changed the game. Tools like Claude Code and Codex can draft features, debug issues, and refactor code at a pace that would have seemed like science fiction just a few years ago. But here's the thing nobody talks about enough — these agents are also really good at accessing things you probably don't want them touching.

Want them to explore your Kubernetes cluster? They can do that. SSH into your production servers? Absolutely. Run commands with elevated privileges? Technically, if you let them.

This is where the rubber meets the road for developer productivity. You want the power of an AI coding assistant, but you also need to sleep at night knowing your production environment is safe. The solution? Sandboxing — and specifically, using microVMs to give these agents their own isolated universe to play in.

The Security Reality Check

Here's the uncomfortable truth: running AI agents in unattended mode is essentially running untrusted code on your machine. The companies building these tools aren't trying to steal your credentials — that's not their business model. But the internet is creative, and attack vectors like Slopsquatting and prompt injection attacks are becoming increasingly sophisticated.

The agents themselves have built-in mitigations, sure. But mitigations aren't perfect, and new vulnerabilities emerge regularly. Just look at recent sandbox escape vulnerabilities — they remind us that lightweight isolation tools like bwrap, while useful, aren't impenetrable fortresses.

Containers offer another layer of protection, but here's the uncomfortable part: containers share the host kernel. Recent kernel vulnerabilities have demonstrated privilege escalation potential, meaning a determined attacker could potentially break out of container isolation. For a security boundary, that's not ideal.

This is why microVMs are becoming an attractive option. Unlike containers, each microVM runs its own kernel. Even if an attacker finds a kernel vulnerability, they're confined to that specific microVM's environment. It's security by isolation — and it's surprisingly practical.

What Are MicroVMs, Anyway?

If you're familiar with traditional virtual machines, you already know the concept: complete isolation with your own kernel, your own system resources, your own everything. The downside has always been that VMs are heavy — they take minutes to boot, consume significant RAM, and generally feel like overkill for running a coding agent.

MicroVMs flip this on their head. They maintain the security benefits of traditional VMs (separate kernel, strong isolation) while starting in hundreds of milliseconds instead of minutes. You get the security boundary of a VM with the footprint closer to a container.

On Fedora Linux, there's a elegant approach using the krun runtime for Podman. This means you can use the same familiar Podman workflow you're already using for containers, but with microVM isolation under the hood. No new tools to learn, no complex configuration — just swap out the runtime.

Getting Started: Installation

Installing the krun runtime on Fedora is straightforward:

dnf install crun-krun

Once installed, running a microVM is almost identical to running a regular container:

podman run --runtime=krun --rm -it fedora:44 /bin/bash

That's it. You now have a fully isolated microVM running Fedora. The workflow you already know, but with stronger security boundaries.

A Few Things to Keep in Mind

MicroVMs aren't regular containers, so a few practical considerations apply:

Allocate enough resources. The defaults might be too conservative for a coding agent that needs to compile code, run tests, and manage project files. Use krun annotations to ensure adequate CPU and RAM allocation — otherwise you might see unexpected OOM kills at the worst possible moment.

Check your libkrun version. Versions before 1.8 have a bug that prevents proper keyboard input. If you find yourself unable to press Enter in your coding agent, this is likely why. Update to avoid frustration.

User handling is different. The microVM always boots as root regardless of what USER directive you set in your Dockerfile. You'll need to either switch users manually after startup or build the user switch into your entrypoint script.

A Practical Setup for Claude Code

Let's walk through a real-world example: sandboxing Claude Code for a Python project using uv for package management. We'll use Podman Compose for orchestration.

First, install Podman Compose:

dnf install podman-compose

The setup consists of three files: a Dockerfile, a docker-compose.yaml, and an entrypoint script.

The Dockerfile

FROM fedora:44

ARG HOST_UID=1000
ARG HOST_GID=1000

# Create group and user matching host UID/GID
RUN groupadd -g ${HOST_GID} appuser && \
    useradd -u ${HOST_UID} -g ${HOST_GID} -m appuser

RUN mkdir -p /venv && chown appuser:appuser /venv
RUN mkdir -p /home/appuser/.claude && chown appuser:appuser /home/appuser/.claude

USER appuser

# Rarely-changing tooling
RUN curl -LsSf https://astral.sh/uv/install.sh | sh && \
    curl -fsSL https://claude.ai/install.sh | bash
USER root

# Frequently-changing RPMs
RUN dnf install git make vim free libpq-devel python3-devel gcc -y && \
    dnf clean all

COPY --chown=appuser entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

USER appuser
WORKDIR /app

ENV PATH="/home/appuser/.local/bin:$PATH"
ENTRYPOINT ["/entrypoint.sh"]
CMD ["/bin/bash"]

Notice a few key points: we create an unprivileged user, install the tooling we need (uv and Claude Code), and structure the Dockerfile so that frequently-changing dependencies are at the bottom. This optimizes build caching — you won't need to reinstall uv every time you add a new package.

The Compose File

The docker-compose.yaml handles mounting your project directory, setting SELinux labels, and configuring resource allocation. This is where microVMs differ slightly from regular containers — you'll need to handle UID/GID translation and explicit hardware resource requests.

The Entrypoint Script

The entrypoint handles the user switch we mentioned earlier. Since microVMs always boot as root, this script needs to switch to your unprivileged user before handing off to the shell or the coding agent.

Is This Worth the Extra Setup?

Absolutely. Here's the value proposition: you get to use powerful AI coding agents without giving them unrestricted access to your workstation, your cluster credentials, or your production environment. The isolation is real — separate kernel, separate namespace, separate everything.

The setup overhead is minimal compared to the security benefits. And once you have the infrastructure in place, spinning up isolated agent environments becomes routine.

For developers and teams handling sensitive codebases, deploying to production clusters, or working in regulated industries, this isn't optional — it's essential. AI coding agents are tools, and like any powerful tool, they need proper safety measures.

Wrapping Up

MicroVMs on Fedora Linux represent a practical middle ground between the security of full virtualization and the convenience of containers. They start fast, they isolate effectively, and they integrate smoothly with existing Podman workflows.

If you're using AI coding agents in your development workflow, especially in unattended mode, consider giving them their own microVM sandbox. Your future self — and your security team — will thank you.

The tools are there. The documentation is solid. And the peace of mind? That's priceless.