Blog

AI-Coding‑Agenten wie Claude Code oder Codex werden zunehmend leistungsfähiger. Das steigert die Produktivität, macht aber blindes Zulassen aller Aktionen gefährlich: Fehlgeleitete Shell‑Befehle oder gezielte Abfragen könnten Ihre Umgebung erkunden oder externe Systeme erreichen. Statt Agenten direkt auf dem Arbeitsrechner laufen zu lassen, empfiehlt sich eine zusätzliche Sandboxing‑Schicht. Eine praxistaugliche Lösung unter Fedora sind MicroVMs, betrieben über podman mit dem krun‑Runtime.

Warum MicroVMs statt nur Container?

Container isolieren Prozesse in Namespaces, teilen aber den Kernel mit dem Host. In der Praxis haben Kernel‑Lücken mehrfach zu Privilegienerhöhungen geführt; CVE‑2026‑39861 ist ein aktuelles Beispiel, das zeigt, dass ein gemeinsamer Kernel ein Angriffsvektor bleibt. MicroVMs dagegen starten einen eigenen Kernel pro Instanz und laufen hinter einem Hypervisor. Sie sind deutlich schneller als klassische Voll‑VMs (Startzeit üblicherweise im Bereich von Hunderten Millisekunden), bieten aber nicht alle Funktionen einer vollständigen VM. Für das sichere Ausführen ungetesteter Agenten bilden sie einen guten Kompromiss zwischen Performance und Isolation.

Komponenten und Voraussetzungen auf Fedora

Fedora liefert podman und das krun‑Runtime in den Repositorien, wodurch sich MicroVMs mit einer Container‑ähnlichen Arbeitsweise betreiben lassen. Zu installieren ist zunächst podman‑compose, wenn Sie Compose‑Workflows nutzen möchten:

sudo dnf install podman-compose

Zum interaktiven Test einer MicroVM kann folgender Befehl dienen:

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

Wichtiges Detail: libkrun sollte Version >= 1.8 installiert sein, weil ältere Varianten bekannte Bedienungsfehler haben (z. B. Probleme beim Drücken der Eingabetaste innerhalb interaktiver Sessions). Außerdem bootet eine krun‑MicroVM standardmäßig als root, die Dockerfile‑USER‑Anweisung wird ignoriert; ein expliziter Benutzerwechsel im Entrypoint ist daher empfehlenswert.

Praxisbeispiel: Agent für ein Python‑Projekt (kurzer Überblick)

Als konkreten Anwendungsfall zeigt das Beispiel, wie man einen AI‑Agenten (hier: Claude Code) in einer MicroVM betreibt, die an ein lokales Python‑Projekt gebunden ist. Der Workflow verwendet ein Container‑Image, in dem ein unprivilegierter Nutzer angelegt wird, und ein Compose‑Setup, das das Projektverzeichnis in die MicroVM mountet. Die wesentlichen Schritte sind:

• Dockerfile: Basis fedora:44, Gruppe/Benutzer mit HOST_UID/HOST_GID anlegen, Verzeichnisse für virtuelle Umgebungen (/venv) und Agent‑Konfiguration (/home/appuser/.claude) erstellen und passende Eigentumsrechte setzen.
• Installieren von Hilfswerkzeugen (z. B. uv als Paketmanager für projektlokale Python‑Installationen) sowie die Agent‑Binaries/Installationsskripte in einer Schicht, die nicht bei jedem Build neu laufen muss.
• Ein Entrypoint‑Skript, das beim Start notwendige Synchronisationen durchführt (uv sync) und anschließend in den unprivilegierten Nutzer wechselt, bevor der eigentliche Agent gestartet wird.

Wichtige Compose‑Konfigurationen

Der Compose‑Dienst für den Agenten enthält einige krun‑spezifische Annotationen und Volumen‑Einstellungen. Zu den relevanten Punkten gehören:

• Annotations, um krun als Runtime auszuwählen und Hardware‑Limits anzugeben, etwa run.oci.handler: krun, krun.ram_mib und krun.cpus.
• user und userns_mode: durch Setzen von user: "${HOST_UID}:${HOST_GID}" und userns_mode: keep-id sorgt podman für UID/GID‑Translation, sodass Dateien in der MicroVM die richtigen Eigentümer auf dem Host haben.
• Volume‑Flags wie :U,z: U veranlasst rekursives Chown, z sorgt für ein gemeinsames SELinux‑Label, sonst kann SELinux den Zugriff der MicroVM auf die Dateien verhindern.
• Umgebungsvariablen, z. B. CLAUDE_CONFIG_DIR, UV_LINK_MODE, UV_PROJECT_ENVIRONMENT und UV_PYTHON_INSTALL_DIR, strukturieren, wo Daten persistiert und wie uv arbeitet.

Build und Start

Ein typischer Ablauf zur Erzeugung und Ausführung sieht so aus (aus dem Projektverzeichnis):

HOST_UID=$(id -u) HOST_GID=$(id -g) podman-compose -f .agent-sandbox/docker-compose.yaml build

Für persistente Agent‑Konfigurationen legen Sie ggf. ein Volume an:

podman volume create claude-config

Und zum Starten in einer interaktiven Session:

HOST_UID=$(id -u) HOST_GID=$(id -g) podman-compose -f .agent-sandbox/docker-compose.yaml run --rm claude

In der MicroVM können Sie mit uname -a prüfen, dass dort ein anderer Kernel läuft als auf dem Host – ein sichtbares Indiz, dass es sich nicht um einen normalen Container handelt.

Automatisierung: Ein kleines Hilfswerkzeug

Damit Sie das Setup nicht für jedes Projekt manuell nachziehen müssen, lässt sich ein kurzes Skript erstellen, das in drei Aktionen arbeitet: init (Projektdatenstruktur anlegen), build (Image bauen) und run (Container/MicroVM starten). Dieses Skript installiert ein Kommando wie sbx, das die oben beschriebenen Schritte zusammenfasst und Routinearbeiten automatisiert.

Sicherheits‑Hinweis: MicroVM ist kein vollständiger Schutz

MicroVMs erhöhen die Hürde für Angriffe deutlich, sie sind aber keine undurchdringliche Grenze. Die Sicherheitsgarantien hängen vom Hypervisor, libkrun‑Code und der gesamten Konfiguration ab. Wer hochriskante oder potenziell bösartige Software ausführen muss, sollte über eine klassische Voll‑VM oder eine isolierte Cloud‑VM nachdenken. Für viele Use‑Cases, insbesondere beim Entwickeln und Testen von AI‑Agenten lokal, sind MicroVMs jedoch ein pragmatischer Kompromiss: schneller als volle VMs, sicherer als reine Container.

Fazit

MicroVMs mit podman + krun bieten auf Fedora eine praktikable Möglichkeit, AI‑Coding‑Agenten in einer stärkeren Sandbox zu betreiben. Sie kombinieren die gewohnte Container‑Workflow‑Erfahrung mit einem eigenen Kernel pro Instanz und damit einer verbesserten Isolation gegenüber Kernel‑basierten Angriffen. Achten Sie auf ausreichende Ressourcen (RAM/CPU‑Annotationen), eine aktuelle libkrun‑Version (>= 1.8) und eine durchdachte Benutzer/Volume‑Konfiguration mit UID/GID‑Translation und SELinux‑Labeln. Und: MicroVMs sind eine sinnvolle Erhöhung der Sicherheit – aber nicht die ultimative Garantie gegen alle Angriffsformen.