Letzte Woche sitze ich bei einem Kunden, Maschinenbau, 80 Leute, solider Online-Shop auf der Seite. Der Entwickler — ein Mann, der seit 15 Jahren zuverlässig alles alleine hält — zeigt mir begeistert, wie er Claude Code auf seinem Laptop laufen hat. Dann zeige ich ihm, was das Tool in den letzten 30 Minuten unbeaufsichtigt auf seinem lokalen Git-Repo gemacht hat. Stille. Danach die Frage, die ich seitdem mindestens einmal pro Woche höre: "Wie mache ich das, ohne dass mir das Ding irgendwann den Laden abfackelt?"
Gute Frage. Andrew Lock hat dazu gerade einen lesenswerten Artikel veröffentlicht, und ich möchte dir erklären, was davon für dich relevant ist — und was nicht.
Was Andrew Lock beschreibt
Lock ist .NET-Entwickler und Blogger, der ernstzunehmende technische Tiefe mitbringt. Sein Artikel beschreibt das Problem präzise: Coding-Agenten wie Claude Code sind produktiv, wenn man ihnen freie Hand lässt — aber genau das ist das Risiko. Der Kompromiss zwischen "ständig auf Bestätigung warten" und "YOLO-Modus mit vollem Dateisystemzugriff" ist unbefriedigend.
Sein Lösungsvorschlag: Docker Sandboxes, die technisch auf MicroVMs basieren — nicht auf normalen Containern. Der Unterschied ist relevant: Die MicroVM hat ihren eigenen Kernel, ein isoliertes Netzwerk, und der Agent sieht nichts vom Host-System außer einem definierten Arbeitsverzeichnis. Das Tool heißt sbx, ist noch experimentell, läuft aktuell auf macOS (ARM) und Windows 11, und erfordert einen Docker-Account.
Das Ergebnis: Du kannst --dangerously-skip-permissions aktivieren, weil der Agent im schlimmsten Fall seine eigene VM ruiniert — nicht deinen Laptop oder euren Server.
Wie das im Mittelstand wirklich landet
Ich unterscheide in meinen Mandaten grob drei Typen, und für jeden ist die Antwort eine andere.
Typ 1: Der Solo-Entwickler oder das Zweier-Team (30-80 Mitarbeitende, eine IT-Person)
Das ist Lock's Zielgruppe — und auch die, die ich am häufigsten berate. Hier ist der sbx-Ansatz tatsächlich interessant, aber mit einem harten Vorbehalt: Das Tool ist experimentell. "Experimentell" in der .NET-Community mit CI/CD-Pipeline und Staging-Umgebung bedeutet etwas anderes als "experimentell" in einem Betrieb, wo die IT-Person gleichzeitig auch der Netzwerk-Admin, der Backup-Verantwortliche und gelegentlich der Drucker-Reparateur ist.
Wenn sbx in drei Monaten sein API ändert und der Entwickler gerade Urlaub hat, steht der Betrieb. Das ist kein theoretisches Risiko — das ist Alltag.
Meine Empfehlung hier: Warte noch ein Quartal. Docker Sandbox ist seit wenigen Wochen ein eigenständiges Tool (vorher in Docker Desktop integriert). Die Dokumentation ändert sich noch monatlich. Lock schreibt selbst, er erwartet, dass sein Artikel schnell veraltet. Das ist Ehrlichkeit, keine Schwäche — aber es ist auch ein Signal.
Typ 2: Das interne Entwicklungsteam (80-200 Mitarbeitende, 3-8 Entwickler)
Hier wird es interessanter. Wenn ihr sowieso bereits mit Docker arbeitet und jemand im Team die Infrastruktur betreut, lohnt sich ein kontrollierter Pilotversuch. Nicht für alle Projekte sofort, sondern für ein abgegrenztes Vorhaben — zum Beispiel das Refactoring eines Legacy-Moduls, das sowieso niemand anfassen will.
Was ihr dabei beachten müsst, was Lock im Artikel nicht adressiert: Datenschutz und Compliance. Die MicroVM läuft lokal, gut. Aber was passiert mit dem Code, den der Agent an die Claude-API schickt? Das ist keine Docker-Frage, das ist eine Frage eurer Datenschutzrichtlinien. Wenn ihr Kundendaten, Geschäftsgeheimnisse oder personenbezogene Informationen in eurer Codebasis habt — und wer hat das nicht — müsst ihr das vorher klären. Das kostet eine Stunde mit eurem Datenschutzbeauftragten, nicht drei Monate. Macht es.
Typ 3: Kein eigenes Entwicklungsteam (alle Größen, IT per Dienstleister)
Finger weg von experimentellen Sandbox-Tools. Nicht weil es schlecht ist, sondern weil es keine sinnvolle Investition eurer knappen IT-Kapazität ist. Wenn euer Dienstleister KI-Agenten einsetzt — was ich bei Ausschreibungen und Leistungsscheinen mittlerweile explizit abfrage — dann soll er euch erklären, wie er das absichert. Das ist seine Verantwortung, nicht eure.
Was im Artikel fehlt
Lock schreibt aus der Perspektive eines erfahrenen Entwicklers, der selbst entscheidet, was auf seinem Rechner läuft. Das ist legitim, aber es blendet zwei Themen aus, die im KMU-Alltag entscheidend sind:
Erstens: Das soziale Problem. Der Engpass ist nicht das Tool, der Engpass ist das Vertrauen. Ich erlebe regelmäßig, dass Geschäftsführer Coding-Agenten komplett blockieren, weil "das ja alles irgendwo hinschickt" — eine pauschale Reaktion, die aus Unwissenheit entsteht. Die technische Antwort darauf heißt nicht sbx, sie heißt: ein klares Bild davon, was der Agent darf, was nicht, und wer das kontrolliert. MicroVM löst das technische Isolation-Problem, aber nicht das Governance-Problem.
Zweitens: Das Kosten-Nutzen-Verhältnis. Lock redet von Produktivitätsgewinn, und ich glaube ihm. Aber für wen konkret? Ein Entwickler, der täglich 6-8 Stunden Code schreibt, gewinnt durch flüssigeren Agenten-Workflow vielleicht 90 Minuten am Tag — das ist real. Ein Entwickler, der 2 Stunden pro Tag entwickelt und den Rest in Meetings, Support und IT-Administration steckt, gewinnt deutlich weniger. Der Aufwand für Setup, Updates und gelegentliche Fehlersuche in einem experimentellen Tool frisst einen Teil dieses Gewinns wieder auf.
Das ist keine Kritik an Locks Ansatz. Das ist eine Erinnerung daran, den ROI für euren spezifischen Kontext zu berechnen, nicht den eines Vollzeit-.NET-Bloggers.
Meine konkrete Empfehlung
Wenn du ein eigenes Entwicklungsteam hast und bereits Docker-Kenntnisse im Team: Lies den Artikel von Lock, installiere sbx auf einem Testrechner, und probiere es für ein isoliertes Projekt aus. Nicht produktionskritisch, nicht mit echten Kundendaten, nicht als erstes Tool, das der neue Entwickler erklärt bekommt.
Wenn du noch nicht weißt, wie du KI-Agenten-Nutzung in deinem Betrieb grundsätzlich steuern willst: Löse das zuerst. Die Governance-Frage — wer darf was, mit welchen Daten, unter welcher Aufsicht — ist wichtiger als die Wahl des richtigen Sandbox-Tools. Ein Regelwerk auf einer Seite reicht als Anfang. Das hat mehr Wirkung als die beste MicroVM.
Der vollständige Original-Beitrag von Andrew Lock: Running AI agents safely in a microVM using docker sandbox
Hast du gerade ähnliche Fragen in deinem Betrieb — wie viel Freiheit gibst du Coding-Agenten, wer darf das entscheiden, und wie erklärt man das dem Geschäftsführer ohne Panikreaktionen? Das sind genau die Gespräche, die ich im 30-Minuten-Sparring führe.
— Bernhard