Sandboxing für Coding-Agents: So arbeiten Agents sicher und selbstständig

Coding-Agents schreiben Code, führen Tests aus, installieren Pakete und rufen APIs auf. Je mehr sie selbstständig erledigen, desto wichtiger wird die Frage, wo genau sie das tun dürfen. Sandboxing für Coding-Agents gibt darauf eine technische Antwort: Der Agent bekommt einen eigenen, abgeschotteten Arbeitsbereich mit genau den Werkzeugen, die er braucht. Alles andere bleibt außer Reichweite.

In diesem Artikel zeigen wir, wie wir in einem Kundenprojekt trotz strenger Einschränkungen kontrollierte Autonomie für Coding-Agents ermöglicht haben. Außerdem stellen wir die drei Sandbox-Typen und ihre unterschiedlichen Sicherheitsniveaus vor und zeigen ein konkretes Setup mit Docker Sandboxes. Der Artikel richtet sich an alle, die Coding-Agents im Team einführen wollen, ohne bei Sicherheit und Compliance Abstriche zu machen.

Im Frühjahr 2026 hat einer unserer Kunden den Einsatz von KI in der Entwicklung freigegeben. Diese Freigabe war allerdings an Bedingungen geknüpft, wie sie viele Teams in regulierten Umfeldern oder mit sensiblen Daten kennen:

• Nur freigegebene Repositories: Der Agent darf ausschließlich auf Repositories zugreifen, für die KI ausdrücklich erlaubt ist.
• Keine Produktionsdaten: keine Datenbankzugriffe, keine Aufrufe von Endpunkten, die produktive Daten liefern.
• Keine Secrets: Credentials und Tokens auf dem Rechner des Entwicklers sind für den Agenten tabu.

Zu Beginn des Projekts haben wir die Bedingungen zunächst pragmatisch umgesetzt. Die Repositories mit KI-Freigabe kamen in einen eigenen Ordner, alle anderen in einen zweiten. In der Konfiguration des Coding-Agents haben wir festgelegt, dass er im gesperrten Ordner weder starten noch schreiben darf. Zusätzlich wurde er per Instruktion angewiesen, diesen Bereich nicht anzufassen.

Solche Regeln sind ein naheliegender Einstieg. Fast jeder Coding-Agent bietet Berechtigungen, Allowlists oder Freigabedialoge, mit denen sich Zugriffe einschränken lassen. Eure Vorgaben mögen anders aussehen, etwa eine Vorgabe, nur bestimmte Netzwerkziele zu erlauben. Das Grundmuster bleibt gleich: Die Grenze steht in der Konfiguration des Agenten.

Dabei zeigt sich ein Verhalten, das typisch für Coding-Agents ist: Sie sind darauf trainiert, ihr Ziel zu erreichen. Stoßen sie auf eine Blockade, suchen sie sich einen anderen Weg. Das haben wir auch im Projekt beobachtet: Als ein Zugriff abgelehnt wurde, versuchte der Agent, die Sperre über ein selbst geschriebenes Skript zu umgehen. Für uns war das das Signal, dass Regeln in der Agent-Konfiguration allein auf Dauer nicht ausreichen.

Ohne echte Isolation bleibt nur eins: dem Agenten ständig über die Schulter schauen. Jeder Tool-Aufruf will geprüft und genehmigt werden. Das kostet Zeit und Nerven. Wir nennen das Approval Friction.

Daraus entsteht schnell ein Risiko. Nach der zwanzigsten Prüfung klickt man einfach nur noch "OK", ohne noch genau nachzuvollziehen, was der Agent gerade tut. Damit ist die Kontrolle formal noch da, praktisch aber verschwunden.

Dahinter steckt ein Zielkonflikt zwischen Geschwindigkeit und Sicherheit:

• Wer jeden Schritt prüft, bremst den Agenten aus und verliert den Produktivitätsgewinn.
• Wer alles durchwinkt, gibt dem Agenten faktisch die Rechte des eigenen Benutzerkontos.

Die Verantwortung für das, was der Agent tut, bleibt beim Menschen. Die Frage ist also, wie du sie trägst, ohne jeden Schritt selbst zu prüfen. Unser Ziel war deshalb kontrollierte Autonomie: Der Agent arbeitet selbstständig, aber in einer Umgebung, deren Grenzen technisch sicher durchgesetzt werden. Genau dafür ist Sandboxing für Coding-Agents gedacht.

Eine Sandbox gibt dem Agenten eine abgegrenzte Arbeitsumgebung. Darin kann er selbstständig arbeiten, Dateien lesen und schreiben, Tests ausführen und Pakete installieren. Die Grenzen dieser Arbeitsumgebung setzt die Sandbox durch, ganz gleich, welchen Ausweg der Agent einschlägt.

Dafür regelt jede Sandbox drei Dinge. Sie isoliert das Dateisystem und bestimmt, welche Dateien und Repositories der Agent überhaupt sieht. Sie isoliert das Netzwerk und legt fest, welche Ziele er erreichen darf, meist über eine Allowlist. Und sie bestimmt die Ausführungsumgebung, also wo die Tools laufen, die der Agent nutzt.

Die Ausführungsumgebung ist dabei die wichtigste Komponente. Keine Isolation ist unüberwindbar, sei es durch eine Fehlkonfiguration oder eine Schwachstelle. Die Ausführungsumgebung entscheidet über den Blast Radius, also darüber, was nach einem Ausbruch aus der Sandbox ungeschützt bleibt. Laufen die Tools des Agenten auf deinem Rechner, ist im schlimmsten Fall alles darauf auch gefährdet. Laufen sie in einer anderen Umgebung, bleibt der Schaden dort.

Wie stark diese Trennung ausfällt, hängt vom Sandbox-Typ ab. Im nächsten Abschnitt stellen wir die drei gängigen Varianten vor. Wenn dich direkt die technisch strikteste Isolation interessiert, spring zu Docker Sandboxes in der Praxis.

Grundsätzlich gibt es drei Arten, einen Coding-Agent zu isolieren. Sie unterscheiden sich vor allem darin, wo die Tools des Agenten laufen und wie groß damit der Blast Radius ausfällt.

Stell dir vor, du gibst einem neuen Kollegen einen eigenen Benutzeraccount auf deinem Rechner. Du legst fest, welche Ordner er sehen darf und welche Websites erreichbar sind.

Technisch arbeitet eine OS-Sandbox mit den Berechtigungen des Betriebssystems: eigener Benutzer, eigene Gruppe, eingeschränkte Rechte. Dazu kommt eine Art Firewall, die festlegt, welche Ziele im Netz der Agent erreichen darf. Gängige Coding-Agents wie Claude Code, Codex oder OpenCode bringen diese Funktion bereits mit. Du musst sie allerdings meist ausdrücklich aktivieren.

Der Haken: Die Isolation liegt nur um den Coding-Agent herum. Alles andere läuft weiter direkt auf deinem Rechner, auch die Tools, die der Agent nutzt. Damit bleiben auch alle Sicherheitslücken deines Systems bestehen. Gelingt dem Agenten ein Ausbruch, ist er mitten in deiner Arbeitsumgebung.

Containerisierung ist in der Softwareentwicklung ein alltägliches Werkzeug (etwa mit Docker, Podman oder Dev Containers). Eine Container-Sandbox nutzt genau diesen Mechanismus: Der Agent wird mit seinen Tools in eine eigene Box gesteckt, und dein Code wird dort hineingereicht. Die Tools liegen damit in dieser Box und nicht mehr direkt auf deinem Rechner. Das macht die Umgebung besser kontrollierbar und für das ganze Team gleich. Welche Ziele der Agent im Netz erreichen darf, regelst du auch hier über eine vorgeschaltete Firewall.

Zwei Punkte bleiben kritisch. Erstens ist die Box weniger dicht, als sie wirkt: Alle Container teilen sich das Herzstück des Betriebssystems (den Kernel) mit deinem Rechner. Zweitens will der Agent für Tests oft selbst Container starten. Dafür braucht er Zugriff auf die Container-Verwaltung deines Rechners, und genau dieser Zugang wird schnell zur Hintertür nach draußen.

Stell dir vor, du richtest für einen neuen Kollegen sein eigenes Notebook ein, auf dem alle nötigen Tools installiert und die Dateien abgelegt sind, die er für seine Aufgabe braucht. Eine Firewall legt fest, welche Ziele er im Netz erreichen darf. Alles, was er tut, passiert auf diesem Gerät, und dein eigener Rechner bleibt davon unberührt.

Der Preis dafür: Eine Micro-VM ist etwas schwergewichtiger als eine OS-Sandbox oder ein Container. Sie ist im Grunde ein kleiner eigener Rechner auf deinem Rechner, mit fest zugeteilter Rechenleistung und eigenem Arbeitsspeicher (dedizierte CPU und RAM) sowie einer eigenen Dateiverwaltung. Dadurch braucht sie mehr Ressourcen und startet etwas langsamer.

Dafür ist die Trennung so stark wie bei keiner anderen Variante. Zwischen der Micro-VM und deinem Rechner steht eine besonders gut abgesicherte Schutzschicht (die Hypervisor Boundary). Selbst wenn der Agent aus seiner Umgebung ausbricht, bleibt er innerhalb der Schutzschicht und kommt nicht an deine Daten.

Micro-VMs bieten von den drei Varianten die stärkste Trennung. Eine Möglichkeit, sie für Coding-Agents einzusetzen, ist Docker Sandboxes. Wir haben Docker Sandboxes in unserem Kundenprojekt eingesetzt, um den besonderen Projektanforderungen an sichere KI Nutzung gerecht zu werden.

Trotz des gemeinsamen Namens setzt es auf eine andere Technik als das bekannte Docker Desktop: Docker Desktop arbeitet mit Containern, Docker Sandboxes mit Micro-VMs, in denen dann wiederum eine eigene Docker Engine für Container läuft. Jede Sandbox läuft dabei als eigene Micro-VM mit eigenem Kernel, eigenem Netzwerk und eigener Container-Verwaltung. Weitere Optionen findest du in den FAQ am Ende des Artikels.

Die Grafik zeigt die Bausteine von Docker Sandboxes im Überblick. Der Coding-Agent arbeitet in der Micro-VM mit eigenem Workspace, eigener Docker Engine und eigenen Tools. Auf deinem Rechner regeln Network Proxy und Credential Store den Weg nach außen, das MCP Gateway die Anbindung externer Tools, der Skill Store gemeinsame Anleitungen für den Agenten und Kits die Konfiguration der Sandbox. In den folgenden Abschnitten gehen wir auf die wichtigsten Bausteine genauer ein.

Am Beispiel einer Anfrage an den Modellprovider zeigen wir, welchen Weg Netzwerk-Anfragen aus der Sandbox nehmen und wie dabei Secrets wie dein API-Key geschützt werden.

Der Coding-Agent in der Micro-VM kennt deinen echten API-Key nicht. In der Sandbox steht nur ein Platzhalter. Würde der Agent damit direkt den Modellprovider aufrufen, würde die Anfrage abgelehnt.

Deshalb laufen alle Anfragen nach außen über einen Network Proxy auf deinem Rechner. Er übernimmt zwei Aufgaben. Zuerst prüft er per Allowlist, ob das Ziel überhaupt erreicht werden darf. Dann schaut er im Credential Store nach, in dem die echten Keys liegen. Ist für die Ziel-Domain ein Key hinterlegt, fügt der Proxy ihn in die Anfrage ein. Der Agent bekommt die Antwort des Modellproviders, sieht den Key aber nie.

Für uns ist das der wichtigste Baustein: Die Secrets bleiben auf deinem Rechner, auch wenn der Agent in der Sandbox selbstständig arbeitet.

Ein Coding-Agent soll arbeiten können wie jeder andere Entwickler im Team. Dazu gehört, die eigene Anwendung im Zusammenspiel mit anderen Systemen zu testen (Integrationstests). Der Agent muss also die Infrastruktur hochfahren können, die ihr im Unternehmen nutzt, etwa Datenbanken, Message Broker oder benachbarte Services, und darauf seine Tests ausführen. In den meisten Teams läuft diese Infrastruktur lokal in Containern. Deshalb braucht der Agent eine eigene Container-Verwaltung.

Docker Sandboxes gibt dafür jeder Sandbox eine eigene Docker Engine. Der Agent kann darin Images pullen und Container starten, genau wie auf einem normalen Entwicklerrechner. Auf die Container-Verwaltung deines Rechners hat er dagegen keinen Zugriff. Damit entfällt ein weiteres Sicherheitsrisiko, das wir bei Container-Sandboxes beschrieben haben.

Über MCP-Server (Model Context Protocol) bekommen Coding-Agents Zugriff auf weitere Tools und Datenquellen. Im normalen Arbeitsalltag heißt das: Für jeden neuen MCP-Server musst du die Konfiguration des Agenten anpassen. In einer Sandbox ist das noch umständlicher, weil diese Konfiguration fest zum Setup der Sandbox gehört.

Das MCP Gateway nimmt diese Hürde. Es läuft außerhalb der Sandbox auf deinem Rechner. Dort registrierst oder importierst du MCP-Server und legst Sicherheitsregeln fest. Der Agent in der Sandbox kennt nur das Gateway. Er fragt bei Bedarf ab, welche Server verfügbar sind, und lädt den passenden dynamisch nach. Am Setup der Sandbox musst du dafür nichts ändern. Nebenbei bleiben auch die Zugangsdaten und Secrets für die MCP-Server sicher außerhalb der Sandbox.

Zwei MCP-Beispiele aus der Praxis:

• GitLab MCP: Der Agent soll Tickets bearbeiten, Merge Requests erstellen und direkt auf der Git-Infrastruktur arbeiten. Dafür haben wir der GitLab-API einen MCP-Server vorgeschaltet und ihn im Gateway registriert. Über die freigegebenen Projekte legen wir dabei fest, dass der Agent nur auf erlaubte Repositories zugreifen darf.
• Context7 MCP: Dieser MCP-Server liefert dem Agenten aktuelle Dokumentation zu Bibliotheken und Frameworks. Statt ihn in jeder Agent-Konfiguration einzutragen, steht er über das Gateway bereit, sobald der Agent ihn braucht.

Erinnerst du dich an das Beispiel vom neuen Kollegen, dem du sein Notebook einrichtest? Genau dieselben Fragen stellen sich beim Aufsetzen einer Sandbox: Auf welche Daten gibst du dem Agenten Zugriff? Welche Tools braucht er für seine Aufgaben, welche Adressen im Netz darf er erreichen, und mit welchen Zugangsdaten und Secrets arbeitet er?

Bei einer Docker Sandbox legst du diese Dinge über Kits und Templates fest. Ein Kit bündelt die Konfiguration einer Sandbox für einen bestimmten Einsatzzweck. Die Grundlage dafür bilden Konfigurationsdateien wie spec.yaml, in denen du unter anderem definierst:

• welche Tools installiert werden, als Benutzer oder mit sudo,
• welche Netzwerkziele erlaubt sind,
• welche Authentifizierungen der Credential Store ersetzen soll,
• welcher Coding-Agent läuft.

Kits lassen sich auch kombinieren. Ihre Konfigurationen werden beim Erzeugen der Sandbox zusammengeführt und bilden gemeinsam die Basis der Sandbox. Kits können in einem Git-Repository liegen oder über eine Container Registry im Team geteilt werden. Unterstützt dein gewünschter Coding-Agent Docker Sandboxes noch nicht, kannst du ihn über ein eigenes Template in die Sandbox integrieren.

Besonders wertvoll ist der Ansatz für Teams, die unter einer dieser Bedingungen arbeiten:

• Regulierte Umfelder, in denen KI nur auf ausgewählten Repositories oder ohne Zugriff auf Produktionsdaten eingesetzt werden darf.
• Gemischte Codebasen, in denen freigegebene und gesperrte Repositories nebeneinander liegen.
• Lokale oder interne Infrastruktur, etwa Endpunkte im VPN, interne Registries oder selbst gehostete Modelle, die der Agent gezielt erreichen oder meiden soll.
• Teams mit vielen Secrets auf Entwicklerrechnern, von Cloud-Credentials bis zu Tokens für interne Systeme.

Coding-Agents finden Wege um Sperren und Hindernisse herum. Wer sie produktiv einsetzen will, braucht deshalb Grenzen, die durch eine Umgebung technisch durchgesetzt werden und die der Agent nicht einfach umgehen kann.

Welche Isolation zu euch passt, hängt davon ab, welches Risiko ihr tragen wollt. Für Teams mit strengen Vorgaben ist eine Micro-VM wie Docker Sandboxes heute die sicherste Wahl für die lokale Entwicklung: Sie trennt den Agenten am stärksten von deinem Rechner, hält Secrets auf dem Host und lässt neue Tools nachladen, ohne dass ihr das Setup ändern müsst.

Für dein Team bedeutet das: Der Agent kann selbstständig arbeiten, ohne dass jemand jeden Schritt freigeben muss. Die Verantwortung bleibt beim Menschen, die Kontrolle übernimmt die Umgebung.

1. Vorgaben klären: Welche Repositories, Daten und Systeme darf der Agent nutzen, welche nicht? Schreib das so konkret auf, dass es sich in eine Konfiguration übersetzen lässt.
2. Mit einem Pilot-Projekt starten: Eine Sandbox für ein Projekt, klare Netzwerkregeln, Zugangsdaten außerhalb der Sandbox. Klein anfangen und aus dem Experiment lernen.
3. Die Sandbox-Konfiguration im Team teilen: Eine gemeinsame, versionierte Konfiguration sorgt dafür, dass alle mit denselben Grenzen arbeiten.

Wenn du Coding-Agents in deinem Team einsetzen möchtest, ohne bei Sicherheit und Compliance Abstriche zu machen, aber noch nicht sicher bist, wie ihr dabei konkret vorgeht, helfen wir dir gerne. Teile mit uns, welche Fragen und Herausforderungen du gerade hast. Wir melden uns zeitnah mit einer Antwort bei dir. Wenn du möchtest, können wir auch ein kostenloses Beratungsgespräch mit einem unserer Experten für Agent-Setups vereinbaren, der gezielt auf eure Situation schaut.