getbb.app vs. Docker und Lima: Wo ist ein Agent sicherer?

Was bei getbb.app, Docker und Lima tatsächlich verglichen wird

Ich würde getbb.app, Docker und Lima nicht einfach in dieselbe Kategorie einordnen: Sie lösen ein ähnliches Problem, ziehen die Vertrauensgrenze jedoch an unterschiedlichen Stellen. In der ursprünglichen Community-Diskussion fragte Nutzer 144406 nach Erfahrungen mit getbb.app. Nutzer 176533234 lenkte das Gespräch sofort auf die entscheidende Frage: Ist es überhaupt sicher, einen autonomen Agenten auf dem Host auszuführen?

Der beschriebene Arbeitsablauf wirkt sinnvoll: ein separater Container für den Agenten, ein eingebundener Projektordner und ein Test-Runner. Das begrenzt den für den Agenten verfügbaren Kontext und erlaubt es, die Umgebung nach der Ausführung zu löschen. Ein gewöhnlicher Container teilt sich allerdings weiterhin den Kernel mit dem Host. Namespaces, cgroups und Dateisystemschichten verringern die Angriffsfläche; sie machen Docker nicht zu einer virtuellen Maschine.

Lima ergänzt eine separate Linux-VM, vor allem für lokale macOS-Szenarien. Zum Schutz des Hosts ist das eine stärkere Grenze als ein Container, der direkt auf dem gemeinsamen System läuft. Konfiguration, Images und Lebenszyklus dieser Umgebung verwaltet allerdings weiterhin der Entwickler.

Nach dem öffentlichen Produktauftritt und dem X-Account zu urteilen, ähnelt getbb.app eher einer spezialisierten Sandbox: Eine ephemere Maschine wird bei Bedarf erstellt, führt eine Aufgabe aus und wird anschließend zerstört. Erwähnt wird auch ein Plugin, das solche Maschinen über Vercel-Sandboxes bereitstellt. In den verfügbaren Materialien fehlt eine vollständige offizielle Beschreibung des Sicherheitsmodells. Prozess-, Netzwerk- und Dateisystemisolation sollten daher nicht allein aufgrund der Produktbeschreibung als bestätigt gelten.

Die Startgeschwindigkeit allein sagt wenig über Sicherheit aus. In einem verfügbaren Vergleich von Sandbox-Anbietern lag die mediane Zeit bis zum interaktiven Zustand zwischen 0,34 und 45 Sekunden. Bei einem Agenten mit Shell-Zugriff ist die Prüfung möglicher Sandbox-Ausbrüche jedoch wichtiger als ein beeindruckender Cold-Start-Wert.

Wo die praktische Sicherheitsgrenze verläuft

Für vertrauenswürdigen Code bietet Docker meist einen guten Kompromiss aus Reproduzierbarkeit und Geschwindigkeit. Bei einem Agenten, der einen über einen Prompt eingeschleusten Shell-Befehl ausführen kann, würde ich den gemeinsamen Kernel als Teil des Risikos betrachten. Die VM-Grenze von Lima oder eine nachweislich VM-gestützte Sandbox verändert die Architektur und nicht nur den Anschein der Isolation.

Ein spezialisierter Dienst profitiert von einem einfachen Zyklus aus Erstellen, Ausführen und Entfernen sowie von einer kleineren Ausführungsfläche. Der Nachteil liegt auf der Hand: weniger Kontrolle auf niedriger Ebene und Abhängigkeit von Garantien, die der Anbieter tatsächlich dokumentiert, statt nur anzudeuten.

Vor dem Komfort der API würde ich Prozessprivilegien, Netzwerkbeschränkungen, Dateisichtbarkeit, Geheimnisverwaltung, Persistenz des Datenträgers und Ausbruchsszenarien prüfen. Solange getbb.app diese Eigenschaften nicht ausreichend detailliert offenlegt, bleibt der Kernpunkt bestehen: Eine ephemere Umgebung beweist noch nicht, dass ihre Sicherheitsgrenze belastbar ist.

Wir haben bereits Pydantic Monty behandelt, einen sicheren Python-Interpreter zur Ausführung von LLM-generiertem Code ohne Container. Sein Ansatz bildet einen hilfreichen Kontrast zu den Fragen der containerbasierten Sandbox-Isolierung bei getbb.app.