gVisor vs Firecracker: Was wir bei 8.764 MCP-Servern lernten

Die Wahl des richtigen Sandboxing-Tools für KI-Agenten entscheidet über Sicherheit und Performance. Während Firecracker mit minimaler Überlastung punktet, bietet gVisor umfassendere Syscall-Interception – doch der Einsatz in der Praxis bringt unerwartete Herausforderungen mit sich. Ein Entwicklerteam hat 8.764 MCP-Server analysiert und zeigt, was bei der Implementierung tatsächlich funktioniert.

Warum gVisor und Firecracker im Vergleich stehen

Die Entscheidung zwischen gVisor und Firecracker hängt von zwei zentralen Faktoren ab: Systemüberlastung und Funktionsumfang. gVisor arbeitet als Userspace-Kernel und fängt Systemaufrufe ab, was etwa 5 bis 10 % Performance-Einbußen verursacht. Firecracker hingegen nutzt Mikro-VMs auf KVM-Basis, startet in rund 125 Millisekunden und bietet nahezu keine Überlastung – allerdings nur, wenn KVM-Zugriff verfügbar ist.

Die Analyse von DEV Community-Autor chunxiaoxx unterstreicht diesen Trade-off präzise. Doch wie sieht die Umsetzung in der realen Welt aus? Ein Entwicklungsteam von MarketNow hat gVisor in einer Produktionsumgebung getestet und dabei wertvolle Erkenntnisse gewonnen.

Fünf kritische Lehren aus dem gVisor-Einsatz bei GitHub Actions

Die Integration von gVisor in bestehende Workflows ist nicht immer reibungslos. Fünf zentrale Probleme traten während der Implementierung auf GitHub Actions hervor:

1. Installation erfordert Root-Rechte

Die Standardkonfiguration von gVisor scheitert häufig an fehlenden Berechtigungen. Ohne sudo-Zugriff können Dateien nicht in /etc/docker/daemon.json geschrieben oder der Docker-Dienst neu gestartet werden. Die Lösung erfordert folgende Schritte:

sudo wget -q  -O /usr/local/bin/runsc
sudo chmod +x /usr/local/bin/runsc
sudo tee /etc/docker/daemon.json > /dev/null <<EOF
{
  "runtimes": {
    "runsc": {
      "path": "/usr/local/bin/runsc"
    }
  }
}
EOF
sudo systemctl restart docker

2. Build-Prozesse benötigen Netzwerkzugriff

Ein häufiger Fehler liegt in der Annahme, dass Docker-Builds ohne Netzwerk auskommen. Die Konfiguration --network none blockiert Abhängigkeitsinstallationen wie npm install, die auf externe Paketquellen zugreifen. Wichtig ist die Unterscheidung zwischen Build-Zeit und Laufzeit: Netzwerkisolation sollte erst beim Ausführen des Containers aktiviert werden.

3. gVisor deckt unerwartete Angriffsvektoren ab

Während herkömmliche seccomp-Profile bestimmte Syscalls blockieren, geht gVisor einen Schritt weiter. In der Praxis wurden folgende Versuche erkannt:

• Ein Server versuchte, ptrace() auszuführen – gVisor blockierte dies mit EPERM.
• Ein weiterer Server nutzte bpf() – gVisor reagierte mit ENOSYS, da BPF nicht unterstützt wird.
• Kritische Kernel-Exploits wurden nicht beobachtet, wären aber ebenfalls abgefangen worden.

4. Kompatibilitätsprobleme bei der Hälfte der Server

Rund 50 % der getesteten MCP-Server starteten nicht unter gVisor, da sie auf nicht implementierte Syscalls angewiesen sind. Dies ist zwar technisch korrekt, doch in der Praxis bedeutet es, dass ein Fallback-Mechanismus erforderlich ist. Bei MarketNow wird in solchen Fällen auf ein erweitertes seccomp-Profil zurückgegriffen.

5. Der Fallback-Mechanismus ist genauso wichtig

Falls gVisor nicht verfügbar ist, kommt ein striktes seccomp-Profil zum Einsatz, das folgende Syscalls blockiert:

• ptrace, bpf, mount, umount2, reboot
• kexec_load, kexec_file_load
• clone3, unshare, setns
• init_module, finit_module, delete_module
• perf_event_open
• name_to_handle_at, open_by_handle_at
• process_vm_readv, process_vm_writev

Der Fahrplan: Von gVisor zu Firecracker

Die Empfehlung aus der ursprünglichen Analyse – zunächst gVisor, später Firecracker – deckt sich mit den Plänen von MarketNow. Während gVisor bereits produktiv im Einsatz ist, soll Firecracker ab dem ersten Quartal 2027 folgen. Der Grund für die Verzögerung liegt in den technischen Anforderungen: Firecracker benötigt KVM-Zugriff, der auf GitHub Actions nicht verfügbar ist. Stattdessen müssten selbst gehostete Runner auf AWS genutzt werden, da Firecracker die Grundlage für Dienste wie AWS Lambda und Fargate bildet.

Die sechsschichtige Sicherheitsarchitektur von MarketNow

Die Analyse von MCP-Servern erfolgt in sechs klar definierten Schichten, die eine ganzheitliche Überprüfung ermöglichen:

• L1.5: Statische Code-Analyse (Abhängigkeiten, Geheimnisse, Lizenzen)
• L1.6: Verhaltensbasierte Mustererkennung
• L2 v2.0: Aktive Prüfung mit über 60 adversarischen Eingaben
• L2.5: gVisor-Sandbox (aktuell live)
• L3 (Q1 2027): Firecracker-Mikro-VMs
• L4 (Q4 2026): Supply-Chain-Attestierung (SLSA Level 3)
• L5 (Q3 2027): Unabhängige Sicherheitsaudits (Trail of Bits, Cure53)

Bisher wurden 8.764 MCP-Server analysiert, wobei 206 den gVisor-Test durchliefen. Die Ergebnisse zeigen ein gemischtes Bild:

• 69 Server erhielten die Bestnote 10/10.
• 103 Server scheiterten bereits am Start (Kompatibilitätsprobleme mit gVisor).
• 6 Server wiesen hohe Risiken auf (kritische Sicherheitslücken).
• Drei Server wurden aufgrund von Umgebungsvariablen-Lecks entfernt.

Die vollständige Methodik ist auf der Projektseite dokumentiert. Ein Beispiel für einen erfolgreich auditierten Server (Anthropic’s Dateisystem-MCP) erreicht ebenfalls 10/10 und steht als Referenz zur Verfügung.

Fazit: Sandboxing ist ein Prozess, kein Ziel

Die Erfahrungen mit gVisor und Firecracker zeigen, dass die Wahl der Sandboxing-Lösung von den individuellen Anforderungen abhängt. Während gVisor in vielen Umgebungen sofort einsatzbereit ist, erfordert Firecracker zusätzliche Infrastruktur. Die Kombination beider Ansätze bietet jedoch eine robuste Sicherheitsstrategie, die sich mit den technischen Fortschritten weiterentwickeln lässt. Für Entwickler, die ihre MCP-Server einer strengen Prüfung unterziehen möchten, bietet MarketNow ein transparentes Audit-Verfahren an – von der statischen Analyse bis zur Laufzeitüberwachung.