Ein Coding-Agent installiert Abhängigkeiten, öffnet Netzwerkverbindungen, greift auf Zugangsdaten zu und arbeitet weiter, wenn sein Auftraggeber längst in einem anderen Projekt steckt. Sobald ein Programm solche Vollmachten bekommt, ist es kein Werkzeug mehr, das geduldig auf Eingaben wartet, sondern ein Akteur, der Entscheidungen trifft und in seiner Umgebung handelt.
Auf der Konferenz WeAreDevelopers North America hat Docker-Präsident Mark Cavage in rund dreißig Minuten gezeigt, wie sich diese Vollmachten einfangen lassen. Sein Vortrag liefert keine Zukunftsvision, sondern drei Bausteine: eine harte Grenze um jeden Agenten, eine reproduzierbare Beschreibung seiner Rechte und die Möglichkeit, dieselbe Umgebung vom Laptop in die Cloud zu verschieben. Wer heute überlegt, wie viel Vertrauen ein autonomer Agent bekommen soll, findet dort ein Modell, das die Frage nicht mit guten Vorsätzen beantwortet, sondern mit Architektur. Als Bild dafür dient eine Werkstatt, die man einem Handwerker übergibt – samt Werkzeug, Material und einem Schlüsselbund, dessen Umfang der Auftraggeber festlegt, nicht der Handwerker selbst.
Eine Einordnung vorab: Grundlage ist eine Zusammenfassung der Keynote im Docker-Firmenblog, geschrieben vom Produktmarketing. Alle Leistungsversprechen stammen also vom Anbieter selbst, unabhängige Tests der Sandboxes liegen bislang nicht vor.
Warum Container für Agenten zu klein geworden sind
Container wurden gebaut, um Anwendungen voneinander zu trennen. Eine Datenbank soll nicht in die Dateien der Webanwendung greifen, ein Build-Prozess nicht die Umgebungsvariablen eines anderen Dienstes sehen. Das funktioniert seit Jahren zuverlässig, auch bei Agenten – nur nicht weit genug. Ein Agent läuft nicht einfach, er handelt: Er entscheidet selbst, welches Paket er installiert, welche Schnittstelle er aufruft und welches Werkzeug er als nächstes benutzt. Damit verschiebt sich die Grenze, die man ziehen muss, von der Anwendung auf die gesamte Umgebung, die der Agent erreichen kann.
Cavage hat diesen Punkt in einer Live-Demonstration sichtbar gemacht. Der Container verhielt sich exakt so, wie er konstruiert war; das Problem lag nicht an einem Fehler in der Isolation, sondern daran, dass der Agent über die Grenzen hinausgriff, die für ein klassisches Programm ausreichen. In der Werkstatt-Analogie ist ein Container ein abschließbarer Raum, in dem ein einzelnes Gerät steht. Ein Agent dagegen ist der Handwerker, der durch die Werkstatt läuft, Schubladen öffnet und selbst entscheidet, welche Maschine er anwirft. Wer ihn einsperren will, muss nicht das Gerät sichern, sondern die ganze Halle – inklusive Stromkreis, Schlüsselbund und Zugang zur Straße.
Docker Sandboxes: eine eigene Maschine pro Agent
Diese Halle liefern die Docker Sandboxes. Jeder Agent bekommt seine eigene isolierte MicroVM mit eigenem Kernel, getrennt von der Umgebung des Entwicklers auf dem Hostsystem. Innerhalb dieser Maschine darf der Agent arbeiten, ausprobieren und scheitern, ohne dass ein Fehler bis auf den Laptop oder die Firmeninfrastruktur durchschlägt. Der Entwickler wählt, welchen Agenten, welches Modell und welche Werkzeuge der Auftrag braucht – die Sandbox schreibt keinen Anbieter vor, sondern nur den Rahmen.
Innerhalb dieses Rahmens gelten klare Regeln. Der Zugriff auf Dateien, Netzwerke und Geheimnisse wie API-Schlüssel wird explizit definiert, und diese Richtlinien liegen außerhalb der Reichweite des Agenten. Er kann sie nicht umschreiben, nicht erweitern und nicht versehentlich aushebeln. Erst das Zusammenspiel aus isolierter Maschine und extern verwalteter Policy macht autonome Arbeit verantwortbar. Die Docker Sandboxes sind schon heute über eine kostenlose, eigenständige CLI verfügbar, mit der du bestehende Agenten-Workflows isoliert ausführen kannst, ohne deine Arbeitsweise umzukrempeln.
Docker Sandbox Kits machen Berechtigungen reproduzierbar
Eine starke Grenze schützt, sagt aber noch nichts darüber aus, was innerhalb der Grenze passieren soll. Wer einen Agenten in einem Team betreibt, braucht eine wiederholbare Antwort auf zwei Fragen: Was läuft hier, und worauf darf es zugreifen? Dafür hat Cavage die nächste Generation der Docker Sandbox Kits angekündigt, die jetzt als gewöhnliche OCI-Images gebaut werden. Ein Kit bündelt den Agenten, seine Werkzeuge und die Regeln für seine Reichweite in einem einzigen versionierten Artefakt.
Die Bündelung ist der unscheinbarste Teil der Ankündigung, und der wichtigste. Kits lassen sich über dieselben Arbeitsabläufe teilen, die du schon für Container-Images benutzt, und jede Änderung an den Vollmachten eines Agenten wird dadurch sichtbar und prüfbar. Man muss nicht mehr rekonstruieren, welcher Kollege welchen Schlüssel wann in welcher Konfiguration hinterlegt hat, weil die Antwort im Artefakt selbst steckt. Docker bringt es so auf den Punkt: Dockerfiles machten Software reproduzierbar, Kits machen jetzt die Vollmachten reproduzierbar. Docker hat angekündigt, die Spezifikation unter neutrale Governance zu stellen und das Ökosystem zum Mitschreiben einzuladen.
Docker Cloud Sandboxes: vom Laptop in die Cloud
Manche Agentenaufträge beginnen und enden auf dem Entwickler-Laptop: ein Refactoring, ein Testlauf, eine Analyse. Andere brauchen Ausdauer oder Parallelität und laufen weiter, wenn der Entwickler den Rechner zuklappt und nach Hause geht. Für diesen Fall hat Docker die Cloud Sandboxes vorgestellt, die dieselbe microVM-basierte Isolation von der lokalen Maschine auf verwaltete Compute-Kapazität übertragen. Der Unterschied liegt nicht im Sicherheitsmodell, sondern im Ort, an dem es ausgeführt wird.
Der Ablauf bleibt vertraut. Mit dem bekannten sbx-Workflow startest du lokal, verschiebst die Arbeit mit einem Befehl in die Cloud und lässt sie dort weiterlaufen; bei Bedarf auch mehrere Aufgaben gleichzeitig, ohne selbst Infrastruktur zu provisionieren oder zu pflegen. Abgerechnet wird nach Verbrauch. Wichtiger als die Bequemlichkeit ist die Kontinuität: Die Vertrauensentscheidung, die du lokal getroffen hast, gilt in der Cloud unverändert weiter, weil es dieselbe Technik mit denselben Policies ist. Es ist kein Umzug, sondern ein durchgereichtes Sicherheitsmodell.
Offene Standards und Partner im Ökosystem
Ein offenes Agenten-Ökosystem braucht zwei Dinge gleichzeitig: Auswahl für Entwickler und gemeinsame Formate, auf die sich die Branche verlassen kann. Beides war auf der Bühne zu sehen. Nous Research zeigte Hermes als Kit in Docker Sandboxes – ein Agent eines Drittanbieters, verpackt für eine gemeinsame Umgebung, während Docker die darunterliegende Isolation und Kontrolle liefert. Du kannst also den Agenten wählen, der zu deiner Aufgabe passt, ohne die vertrauenswürdige Ausführungsschicht jedes Mal neu zu bauen.
Die zweite Hälfte betrifft den Standard selbst. Docker hat zugesagt, die Kits-Spezifikation an die Cloud Native Computing Foundation zu übergeben, jene herstellerneutrale Heimat für cloudnative Software. Chris Aniszczyk, CTO der CNCF, lobt das in einer Stellungnahme: Kaum ein Unternehmen verstehe so gut wie Docker, dass Standards ein Ökosystem schnell wachsen lassen, ohne es zu zersplittern; mit Kits als Standard-OCI-Images bekomme die Branche einen offenen, wiederholbaren Weg, einen KI-Agenten samt Werkzeugen und Leitplanken als ein Artefakt zu verpacken. Der Hinweis auf OCI ist mehr als ein Detail: Wer auf einem Standard aufsetzt, der die gesamte Cloud-Native-Welt trägt, erreicht diese Welt mit einem Schritt statt mit Dutzenden von Einzelintegrationen.
Vertrauen entsteht aus dem System um den Agenten
Zusammengenommen ergeben die Ankündigungen kein Sortiment, sondern ein System, das sich gegenseitig stützt. Sandboxes liefern eine deterministische Grenze, Kits machen Umgebung und Berechtigungen reproduzierbar, Cloud Sandboxes dehnen dasselbe Vertrauensmodell auf dauerhafte Kapazität aus. Das Ergebnis ist mehr Freiheit für den Agenten bei gleichbleibender Kontrolle darüber, was er anfassen und verändern darf. In der Werkstatt bleibt der Handwerker frei in seiner Arbeit, während der Auftraggeber weiterhin bestimmt, welche Türen sein Schlüssel öffnet.
Daraus folgt eine einfache Konsequenz: Vertrauen in autonome KI-Agenten ist kein Gefühl, das man dem Modell entgegenbringt, sondern eine Eigenschaft der Umgebung, in der es läuft. Solange diese Umgebung nicht definiert ist, bleibt jede Freigabe ein Glücksspiel, egal wie überzeugend die Zwischenergebnisse aussehen. Docker Sandboxes verhindern deshalb keine Fehler – sie sorgen dafür, dass ein Fehler einen begrenzten Raum hat, einen nachvollziehbaren Ursprung und eine Grenze, die der Agent nicht selbst verschieben kann. Wer heute mit der CLI startet, kann diesen Unterschied im eigenen Workflow ausprobieren, statt ihn theoretisch zu diskutieren.
Für Teams, die Agenten in größerem Maßstab einsetzen wollen, verschiebt sich damit die eigentliche Arbeit. Nicht das Modell ist die knappe Ressource, sondern die Frage, wie sich Rechte sauber beschreiben, versionieren und überprüfen lassen. Wer das löst, kann Agenten laufen lassen, ohne bei jedem Schritt mitzählen zu müssen. Wer es nicht löst, wird früher oder später eine Grenze ziehen, die zu spät kommt.
Quelle: docker.com
