AI-Coding\u2011Agenten wie Claude Code oder Codex werden zunehmend leistungsf\u00e4higer. Das steigert die Produktivit\u00e4t, macht aber blindes Zulassen aller Aktionen gef\u00e4hrlich: Fehlgeleitete Shell\u2011Befehle oder gezielte Abfragen k\u00f6nnten Ihre Umgebung erkunden oder externe Systeme erreichen. Statt Agenten direkt auf dem Arbeitsrechner laufen zu lassen, empfiehlt sich eine zus\u00e4tzliche Sandboxing\u2011Schicht. Eine praxistaugliche L\u00f6sung unter Fedora sind MicroVMs, betrieben \u00fcber podman mit dem krun\u2011Runtime.<\/p>\n
Container isolieren Prozesse in Namespaces, teilen aber den Kernel mit dem Host. In der Praxis haben Kernel\u2011L\u00fccken mehrfach zu Privilegienerh\u00f6hungen gef\u00fchrt; CVE\u20112026\u201139861 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\u2011VMs (Startzeit \u00fcblicherweise im Bereich von Hunderten Millisekunden), bieten aber nicht alle Funktionen einer vollst\u00e4ndigen VM. F\u00fcr das sichere Ausf\u00fchren ungetesteter Agenten bilden sie einen guten Kompromiss zwischen Performance und Isolation.<\/p>\n
Fedora liefert podman und das krun\u2011Runtime in den Repositorien, wodurch sich MicroVMs mit einer Container\u2011\u00e4hnlichen Arbeitsweise betreiben lassen. Zu installieren ist zun\u00e4chst podman\u2011compose, wenn Sie Compose\u2011Workflows nutzen m\u00f6chten:<\/p>\n
sudo dnf install podman-compose<\/code><\/pre>\nZum interaktiven Test einer MicroVM kann folgender Befehl dienen:<\/p>\n
podman run --runtime=krun --rm -it fedora:44 \/bin\/bash<\/code><\/pre>\nWichtiges Detail: libkrun sollte Version >= 1.8 installiert sein, weil \u00e4ltere Varianten bekannte Bedienungsfehler haben (z. B. Probleme beim Dr\u00fccken der Eingabetaste innerhalb interaktiver Sessions). Au\u00dferdem bootet eine krun\u2011MicroVM standardm\u00e4\u00dfig als root, die Dockerfile\u2011USER\u2011Anweisung wird ignoriert; ein expliziter Benutzerwechsel im Entrypoint ist daher empfehlenswert.<\/p>\n
Praxisbeispiel: Agent f\u00fcr ein Python\u2011Projekt (kurzer \u00dcberblick)<\/h2>\n
Als konkreten Anwendungsfall zeigt das Beispiel, wie man einen AI\u2011Agenten (hier: Claude Code) in einer MicroVM betreibt, die an ein lokales Python\u2011Projekt gebunden ist. Der Workflow verwendet ein Container\u2011Image, in dem ein unprivilegierter Nutzer angelegt wird, und ein Compose\u2011Setup, das das Projektverzeichnis in die MicroVM mountet. Die wesentlichen Schritte sind:<\/p>\n
\n- Dockerfile: Basis fedora:44, Gruppe\/Benutzer mit HOST_UID\/HOST_GID anlegen, Verzeichnisse f\u00fcr virtuelle Umgebungen (\/venv) und Agent\u2011Konfiguration (\/home\/appuser\/.claude) erstellen und passende Eigentumsrechte setzen.<\/li>\n
- Installieren von Hilfswerkzeugen (z. B. uv als Paketmanager f\u00fcr projektlokale Python\u2011Installationen) sowie die Agent\u2011Binaries\/Installationsskripte in einer Schicht, die nicht bei jedem Build neu laufen muss.<\/li>\n
- Ein Entrypoint\u2011Skript, das beim Start notwendige Synchronisationen durchf\u00fchrt (uv sync) und anschlie\u00dfend in den unprivilegierten Nutzer wechselt, bevor der eigentliche Agent gestartet wird.<\/li>\n<\/ul>\n
Wichtige Compose\u2011Konfigurationen<\/h3>\n
Der Compose\u2011Dienst f\u00fcr den Agenten enth\u00e4lt einige krun\u2011spezifische Annotationen und Volumen\u2011Einstellungen. Zu den relevanten Punkten geh\u00f6ren:<\/p>\n
\n- Annotations, um krun als Runtime auszuw\u00e4hlen und Hardware\u2011Limits anzugeben, etwa
run.oci.handler: krun<\/code>, krun.ram_mib<\/code> und krun.cpus<\/code>.<\/li>\n- user und userns_mode: durch Setzen von
user: \"${HOST_UID}:${HOST_GID}\"<\/code> und userns_mode: keep-id<\/code> sorgt podman f\u00fcr UID\/GID\u2011Translation, sodass Dateien in der MicroVM die richtigen Eigent\u00fcmer auf dem Host haben.<\/li>\n- Volume\u2011Flags wie
:U,z<\/code>: U<\/code> veranlasst rekursives Chown, z<\/code> sorgt f\u00fcr ein gemeinsames SELinux\u2011Label, sonst kann SELinux den Zugriff der MicroVM auf die Dateien verhindern.<\/li>\n- Umgebungsvariablen, z. B.
CLAUDE_CONFIG_DIR<\/code>, UV_LINK_MODE<\/code>, UV_PROJECT_ENVIRONMENT<\/code> und UV_PYTHON_INSTALL_DIR<\/code>, strukturieren, wo Daten persistiert und wie uv arbeitet.<\/li>\n<\/ul>\nBuild und Start<\/h2>\n
Ein typischer Ablauf zur Erzeugung und Ausf\u00fchrung sieht so aus (aus dem Projektverzeichnis):<\/p>\n
HOST_UID=$(id -u) HOST_GID=$(id -g) podman-compose -f .agent-sandbox\/docker-compose.yaml build<\/code><\/pre>\nF\u00fcr persistente Agent\u2011Konfigurationen legen Sie ggf. ein Volume an:<\/p>\n
podman volume create claude-config<\/code><\/pre>\nUnd zum Starten in einer interaktiven Session:<\/p>\n
HOST_UID=$(id -u) HOST_GID=$(id -g) podman-compose -f .agent-sandbox\/docker-compose.yaml run --rm claude<\/code><\/pre>\nIn der MicroVM k\u00f6nnen Sie mit uname -a<\/code> pr\u00fcfen, dass dort ein anderer Kernel l\u00e4uft als auf dem Host \u2013 ein sichtbares Indiz, dass es sich nicht um einen normalen Container handelt.<\/p>\nAutomatisierung: Ein kleines Hilfswerkzeug<\/h2>\n
Damit Sie das Setup nicht f\u00fcr jedes Projekt manuell nachziehen m\u00fcssen, l\u00e4sst 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<\/code>, das die oben beschriebenen Schritte zusammenfasst und Routinearbeiten automatisiert.<\/p>\nSicherheits\u2011Hinweis: MicroVM ist kein vollst\u00e4ndiger Schutz<\/h2>\n
MicroVMs erh\u00f6hen die H\u00fcrde f\u00fcr Angriffe deutlich, sie sind aber keine undurchdringliche Grenze. Die Sicherheitsgarantien h\u00e4ngen vom Hypervisor, libkrun\u2011Code und der gesamten Konfiguration ab. Wer hochriskante oder potenziell b\u00f6sartige Software ausf\u00fchren muss, sollte \u00fcber eine klassische Voll\u2011VM oder eine isolierte Cloud\u2011VM nachdenken. F\u00fcr viele Use\u2011Cases, insbesondere beim Entwickeln und Testen von AI\u2011Agenten lokal, sind MicroVMs jedoch ein pragmatischer Kompromiss: schneller als volle VMs, sicherer als reine Container.<\/p>\n
Fazit<\/h2>\n
MicroVMs mit podman + krun bieten auf Fedora eine praktikable M\u00f6glichkeit, AI\u2011Coding\u2011Agenten in einer st\u00e4rkeren Sandbox zu betreiben. Sie kombinieren die gewohnte Container\u2011Workflow\u2011Erfahrung mit einem eigenen Kernel pro Instanz und damit einer verbesserten Isolation gegen\u00fcber Kernel\u2011basierten Angriffen. Achten Sie auf ausreichende Ressourcen (RAM\/CPU\u2011Annotationen), eine aktuelle libkrun\u2011Version (>= 1.8) und eine durchdachte Benutzer\/Volume\u2011Konfiguration mit UID\/GID\u2011Translation und SELinux\u2011Labeln. Und: MicroVMs sind eine sinnvolle Erh\u00f6hung der Sicherheit \u2013 aber nicht die ultimative Garantie gegen alle Angriffsformen.<\/p>\n