Stephan Schmidt - June 15, 2026

Dein KI-Agent darf alles. Solltest du ihn lassen?

Wann sich Devcontainers und Sandboxes für KI-Coding-Agents lohnen — und wann sie Overkill sind.

Ich hab letztens einfach mal mitgezählt. An einem einzigen Nachmittag habe ich in Claude Code über hundert Mal „ja" geklickt. Ja, schreib die Datei. Ja, führ den Befehl aus. Ja, leg das Verzeichnis an. Ab einem bestimmten Punkt lese ich gar nicht mehr, was da steht, du tippst nur noch Enter, Enter, Enter — derselbe Reflex, mit dem jeder von uns schon mal die iTunes-AGB „gelesen" und akzeptiert hat. (Ich hatte zu dem Zeitpunkt drei Claude-Instanzen in drei tmux-Panes offen)

YOLO-Mode, das automatische Durchwinken, gibt es aus einem guten Grund: Alle sind es müde und wollen dass der Agent lange allein arbeitet, ohne dass er bei jedem mkdir um Erlaubnis frägt. Nur läuft dieser Agent auf einer Maschine oft mit Mitarbeiter-Rechten, und er kann in den nächsten drei Stunden alles sehen und alles anfassen, bis jemand das nächste Mal hinschaut — die SSH-Keys, die .env mit den Production-Credentials, das halbe Home-Verzeichnis, den AWS-Token, der noch in der Shell-History klebt, und eventuell hat er Daten in der Datenbank geändert.

(Man fragt sich sowieso warum Agenten praktisch überall aus Bequemlichkeit Admin Rechte bekommen, niemand würde einem Junior Developer Vollzugriff auf alles geben - ein anderes Thema.)

Und genau hier hört es auf, ein Entwickler-Thema zu sein, und wird ein CTO Thema.

Ab wann ist das denn dein Problem?

Die meisten Entwickler, mit denen ich rede, wählen eine von zwei schlechten Optionen. Entweder volles YOLO und blindes Vertrauen in die AI (mutig oder dumm, such dir eins aus), oder sie klicken hundertmal am Tag „ja" weil sie vorsichtig sein wollen. Das eine ist fahrlässig, das andere ist langsam, und keins von beidem besonders gut. Und das weil die Firma keine klaren Vorgaben macht.

Der Blast Radius wenn etwas schiefgeht verantwortet nicht der Entwickler. Wenn der Agent auf dem Laptop eines Engineers etwas Dummes tut und dabei an einem Token hängt, der bis in die Produktion reicht, dann steht am Ende nicht der Engineer vor dem CEO, sondern du, der CTO (VP Engineering, usw.) Der Entwickler optimiert auf seine eigene Geschwindigkeit, IMHO völlig zu Recht, denn das ist sein Job und wird von ihm erwartet (Business pressure to deliver). Auf den möglichen Schaden für die ganze Firma zu schauen, ist aber ein Management Job.

Die Landschaft der AI-Gefängnisse

Ich hab mir vor Kurzem angeschaut, was es an Sandboxen überhaupt gibt, und das meiste davon ist halbfertig.

Die einfachen Wrapper — Bubblewrap, Landrun, Claude Sandbox auf dem Mac — funktionieren so, wie chroot-Jails seit zwanzig Jahren arbeiten (ich bin so alt :-( dass ich mich erinnern kann wie begeistert ich war als ich von jails gelesen habe): einschränken, was der Prozess sieht, begrenzen, was er lesen und ändern darf. Bubblewrap kann mit --unshare-net das Netz zwar komplett kappen - sicher aber unpraktisch. Landrun kontrolliert nur das Binden von TCP-Ports - praktischer aber nur sicher damit ein Agent keinen lokalen Server öffnet. Anthropics eigene Sandbox Runtime bringt einen Proxy mit Domain-Regeln und Lese-/Schreibsperren fürs Dateisystem mit. Alles brauchbar, aber alles fummelig — und fummelig heißt: Der Entwickler konfiguriert es einmal falsch und merkt es nicht - bis was passiert.

Die ambitionierten Tools sind interessanter und frustrierender zugleich. Sandcat fährt Docker Compose mit einem MITM-Proxy hoch, fängt den ganzen Traffic ab und tauscht Secrets erst auf Proxy-Ebene ein. Matchlock startet echte Firecracker-microVMs. Auf dem Papier ist das genau das, was du willst — in der Praxis ist nichts davon ein fertiges Produkt, das du deinem Team einfach hinstellst.

Und dann tummeln sich noch die vielen anderen, Docker sgx und Cloudflare (Stand Mitte 2026) - auch alle halbfertig.

Und keins dieser Tools kann das eine, das eigentlich zählt: Sicherheit garantieren, alle Secrets wirklich vor der AI verstecken, ihr die Credentials nur dort unterschieben, wo sie wirklich gebraucht werden, und sauber mitschreiben, was rein- und rausgeht. Zumachen kannst du mit viel Handarbeit, und Handarbeit an Sicherheit geht irgendwann schief aus meiner Erfahrung.

Wann sich eine Sandbox lohnt — und wann nicht

Für den Solo-Entwickler mit Side-Project ist die ganze Sandbox-Maschinerie Overkill (kann ich aber auch falsch liegen). Für jedes Team, dessen Agents in Reichweite von Production-Credentials, CI-Pipelines oder Kundendaten laufen, ist das Fehlen einer Sandbox Fahrlässigkeit.

KI Agenten sind greedy, sie finden auch API Keys ausserhalb des Projektes, oder in Git logs - wenn sie theoretisch an Keys rankommen, dann finden Sie dies auch wie zahlreiche Horrorstories zeigen.

Was daher zählt, ist der Blast Radius. Stell dir als CTO die eine Frage: Wenn dieser Agent drei Stunden lang unbeaufsichtigt arbeitet und dabei das Dümmste tut, was möglich ist — was ist kaputt, wenn du zurückkommst? Wenn deine Antwort ist: „ein Branch, den ich wegwerfe" lautet, brauchst du keine microVM. Wenn die Antwort „die Prod-Datenbank" lautet oder „der Stripe-Key liegt jetzt in einem Log", dann schon.

Was ein Harness deinem Team sonst bringt

Ein Devcontainer ist aber mehr als ein Käfig - sondern ist überall hilfreich. Nehmen wir Onboarding. Viele meiner Kunden haben nicht das optimale Onboarding (Miterbeiter deployed Bugfix am ersten Tag). Mit Devcontainer? Neuer Entwickler im Team? Er öffnet das Projekt, ist drin, fertig — kein „installier diese Node-Version, setz die Datenbank auf, konfigurier diese drei Environment-Variablen", kein verlorener erster Tag. Eine definierte Umgebung statt fünfzehn leicht unterschiedlicher Laptops.

Dein Preis dafür ist, dass diese Umgebung jemandem ownen muss. Du willst tmux im Container (ich brauche tmux!), dazu ripgrep, fd, fzf, einen Language Server (LSP) — also baust du das ein. Dann pusht der Maintainer des Containers ein Update, deine Anpassungen sind weg, und jemand merged wieder Dockerfile-Fragmente von Hand. (Mich hat das so genervt, dass ich mir ein kleines Plugin-System dafür gebaut habe — beziehungsweise Claude hat es gebaut, ich hatte nur die zwei richtigen Begriffe im Prompt.) Ich halte das nicht für ein Detail, sondern ein weiterer Overhead Punkt, die ein Team-Harness kostet, und jemand - eine Rolle - muss sie ownen.

Der Trade-off, den nur du setzen kannst

Jede Sicherheitsschicht macht den Agent ein bisschen langsamer. Der Proxy, das eingeschränkte Dateisystem, das Netz, das erst freigeschaltet werden muss — das alles bringt mehr Reibung. Und jedes bisschen Geschwindigkeit, das du zurückholst, indem du eine Schicht weglässt, vergrößert den Blast Radius. Das ist your call, nicht der des Entwicklers - Mitarbeiter optimieren eher lokal und Manager sind eher geneigt global zu optimieren.

Womit ich nicht sage, dass ich eine fertige Antwort habe. Ich nutze z.B. Sandcat, die Teams, mit denen ich arbeite, nehmen Anthropics Variante, und für nicht-interaktive One-Shot-Prompts wahrscheinlich bald Landrun. In einem Jahr heißt das alles anders, und die Hälfte der Tools gibt es dann nicht mehr weil Anthropic eine Standard Lösung anbieten wird.

Eine offene Frage

Manche deiner Entwickler setzen KI-Agents längst in YOLO-Mode ein, eventuell mit deinen Production-Credentials in Reichweite. Das läuft schon.

Offen ist nur, ob du es so entschieden hast oder ob es einfach passiert.