Letzten Herbst hatte ich ein Gespräch mit dem Entwicklungsleiter eines Maschinenbauers mit 120 Mitarbeitenden. Sein Team — vier Entwickler — hatte angefangen, Claude Code produktiv einzusetzen. Nach zwei Wochen kam er zu mir: "Bernhard, die KI hat uns fast die Datenbankverbindung in ein öffentliches Repo committet." Fast. Zum Glück hatte ein Entwickler es vor dem Push bemerkt. Aber das Vertrauen war weg, und das Team wollte aufhören, den Agenten überhaupt zu nutzen.
Das ist kein Einzelfall. Ich höre das Muster regelmäßig: Entweder läuft der Agent im vollständigen YOLO-Modus — weil die ständigen Tool-Call-Bestätigungen nerven —, oder er wird nach dem ersten Schreckmoment gar nicht mehr benutzt. Beides ist Ressourcenverschwendung. Andrew Lock adressiert genau dieses Problem, und sein Ansatz ist technisch sauber. Deshalb lohnt es sich, genauer hinzusehen.
Was Andrew Lock beschreibt
Lock erklärt, wie man mit dem Tool sbx (Docker Sandbox) KI-Agenten wie Claude Code in microVMs isoliert ausführt. Die Kernidee: Der Agent bekommt nur Zugriff auf ein definiertes Arbeitsverzeichnis, der Netzwerktraffic läuft über einen Proxy — der sogar Credentials injizieren kann, ohne dass der Agent sie je zu Gesicht bekommt. Um nicht bei jedem Sandbox-Start dieselben Tools manuell nachinstallieren zu müssen, zeigt er, wie man eigene OCI-Images baut, die auf den offiziellen docker/sandbox-templates aufbauen. Als konkretes Beispiel nimmt er .NET: System-Packages via apt-get als root, anschließend das dotnet-SDK als agent-User. Das fertige Image wird auf Docker Hub gepusht und dann per sbx run -t docker.io/my-org/my-template:v1 claude gestartet. Er erwähnt ehrlich, dass er selbst .NET-Build-Hänger in eigenen Projekten erlebt — ein seltenes Maß an Transparenz für einen Tech-Blogger.
Wie das im KMU wirklich landet
Lass mich direkt sein: Der Ansatz funktioniert. Aber er kommt mit einem Implementierungsaufwand, den viele Mittelständler unterschätzen.
Was lohnt sich:
Die Sicherheitsarchitektur ist solide durchdacht. MicroVMs statt Docker-Container bedeutet echter Kernel-Isolation, keine shared namespaces. Der Netzwerk-Proxy mit Credential-Injection löst ein reales Problem: Deine Entwickler müssen dem Agenten keine API-Keys direkt übergeben. Das allein ist für mich als Berater drei von vier Kritikpunkten, die ich normalerweise in Security-Reviews für KMU-Entwicklungsumgebungen aufschreibe, wert. Und die Custom Templates sind der richtige Ansatz für Projekte, wo das Tooling-Setup mehr als fünf Minuten dauert — das ist bei .NET-Shops, Java-Monolithen oder Unternehmen mit internen Paketregistries fast immer der Fall.
Was nicht lohnt sich:
Für ein Team unter fünf Entwicklern, die gelegentlich KI-gestützt Python-Skripte oder einfache Web-Features bauen, ist das Overhead. Ein Dockerfile bauen, zu Docker Hub pushen, Versionierung verwalten — das ist CI/CD-Infrastruktur für das Dev-Tooling selbst. Wenn dein Team keine dedizierten DevOps-Ressourcen hat oder Docker-Images nicht zum Tagesgeschäft gehören, schreckt das ab. Ich habe Mandanten, bei denen der erste Versuch, ein Custom Template zu bauen, an der fehlenden Docker-Desktop-Lizenz gescheitert ist. Docker Desktop ist ab einer bestimmten Unternehmensgröße lizenzpflichtig — das erwähnt Lock nicht, ist aber für Betriebe ab 250 Mitarbeitenden relevant.
Was fehlt:
Lock schreibt aus der Perspektive eines Datadog-Ingenieurs, der täglich mit komplexen Build-Pipelines und enterprise-grade Tooling arbeitet. Was in seinem Artikel keine Rolle spielt:
Erstens: Team-Adoption. Das Setup ist für einen erfahrenen Entwickler nachvollziehbar. Aber der Junior-Entwickler im 40-Mann-Betrieb, der Claude Code gerade erst entdeckt hat, verliert sich spätestens bei "du musst dein Image zu einer OCI-Registry pushen". Ich empfehle meinen Mandanten: Einer baut das Template, einer pflegt es, alle anderen nutzen es per Copy-Paste-Befehl. Sonst wird das Template nach drei Wochen nicht mehr geupdated und ist schlimmer als gar keines.
Zweitens: Kosten. Docker Hub hat seit 2023 Pull-Rate-Limits und kostenpflichtige Tiers für Teams. Für kleine Teams ist das vernachlässigbar — aber wer das Image intern sensitiv hält (interne Libraries, Firmenzertifikate im Image), will es nicht auf Docker Hub packen. Eine private Registry kostet extra, sei es GitHub Container Registry, GitLab Registry oder AWS ECR. Das ist kein Blocker, aber es gehört in die Kalkulation.
Drittens: Das .NET-Hänger-Problem. Lock erwähnt es ehrlich als persönliche Erfahrung. In meiner Beratungspraxis ist das kein Randproblem — .NET-Builds in containerisierten Umgebungen reagieren empfindlich auf CPU-Throttling und Memory-Limits. MicroVMs mit Default-Ressourcen können da tatsächlich hängen. Wer ernsthaft .NET in Sandboxes betreiben will, braucht explizite Ressourcen-Konfiguration und muss das testen, bevor er das seinem Team ankündigt.
Meine konkrete Empfehlung
Für KMU-Entwicklungsteams zwischen 3 und 15 Entwicklern würde ich so vorgehen:
Schritt 1: Fang mit dem Standard-Template an, ohne Custom Image. Testete, ob sbx in eurer Umgebung überhaupt stabil läuft und ob euer Projekt-Setup damit kompatibel ist. Eine Woche, kein Infrastrukturaufwand.
Schritt 2: Wenn ihr merkt, dass ihr bei jedem Sandbox-Start mehr als 5-10 Minuten damit verbringt, Tools nachzuinstallieren, dann — und erst dann — lohnt sich ein Custom Template. Baut es einmal sauber, legt das Dockerfile ins Repo, pusht das Image in eure CI/CD-Pipeline. Automatisiert den Push bei jedem Merge in main.
Schritt 3: Wenn euer Projekt sensible Interna im Image benötigt, nehmt keine öffentliche Registry. GitHub Container Registry mit privaten Images kostet nichts extra, wenn ihr ohnehin GitHub nutzt.
Was ich nicht empfehle: Direkt mit einem Custom Base Image anzufangen, um die offiziellen Templates zu umgehen. Lock beschreibt das selbst als "not officially supported" — und das merkt man. Die offiziellen Templates enthalten eine Menge undokumentierter Konfiguration. Das ist kein guter Ausgangspunkt für produktiven Betrieb.
Der vollständige Original-Beitrag von Andrew Lock: Running AI agents with customized templates using docker sandbox
Wenn du wissen willst, ob und wie KI-Agenten in deinem konkreten Entwicklungssetup Sinn machen — ohne Sandbox-Theorie, sondern mit einem Blick auf dein Team, dein Stack, deine Risikobereitschaft:
— Bernhard