Вход на сайт

Просмотр новости

Найдите то, что Вас интересует

Docker Sandboxes: isolierte Einweg-Umgebungen für KI-Agenten

Дата публикации: 10-08-2026 12:55:40

Docker Sandboxes sperren jeden KI-Coding-Agenten in eine eigene MicroVM mit eigenem Kernel und eigenem Docker-Daemon. Der Host bleibt damit außer Reichweite. Für Zugangsdaten und...

Основное содержимое страницы с новостью.

Docker Sandboxes sperren jeden KI-Coding-Agenten in eine eigene MicroVM mit eigenem Kernel und eigenem Docker-Daemon. Der Host bleibt damit außer Reichweite. Für Zugangsdaten und Quellcode im freigegebenen Projektordner gilt das nicht, dort verläuft die eigentliche Grenze.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

Docker Sandboxes starten seit Ende März eine eigene MicroVM pro Agentensitzung, und das Kommandozeilenwerkzeug sbx gibt Docker kostenlos ab.[2] Wie dringend Entwicklerteams diese Grenze brauchen, zeigte der August 2025: Manipulierte npm-Pakete des Build-Systems Nx riefen auf fremden Rechnern die lokal installierten KI-Assistenten auf.

Das Wichtigste in Kürze
  • Jede Agentensitzung bekommt eine eigene MicroVM mit eigenem Kernel und eigenem Docker-Daemon.
  • Die MicroVM begrenzt den Schaden am Rechner, nicht den Abfluss von Daten über das Netz.
  • Ab dem 11. September 2026 verlangt der Cyber Resilience Act binnen 24 Stunden eine Frühwarnung.
Warum reicht ein Container nicht mehr aus? Ein Einmachglas mit einem Papierroboter, Konfetti, dem Text „Bleibt hier drin“ und einem SchlüsselDocker Sandboxes isolieren Coding-Agents mit eigenen MicroVMs, Kerneln und Docker-Daemons statt nur Container zu teilen

Container teilen den Kernel des Hosts. Sobald ein Coding-Agent selbst Images bauen und Container starten soll, braucht er erhöhte Rechte oder den Docker-Socket des Rechners, und damit fällt die Trennung in sich zusammen. Docker Sandboxes geben deshalb jeder Sitzung eine eigene MicroVM samt eigenem Kernel und eigenem Docker-Daemon.[1]

Einen eigenen VMM hat Docker geschrieben, statt Amazons Firecracker zu übernehmen. Srini Sekaran und Craig Gumbley begründen das mit der Plattformfrage: Firecracker setzt auf Linux und KVM, Coding-Agenten laufen aber auf Entwickler-Laptops. Der Docker-VMM spricht deshalb Hypervisor.framework, Windows Hypervisor Platform und KVM aus einer Codebasis an.[1]

Neun Werkzeuge laufen bereits darin, darunter Claude Code, Codex und die Gemini CLI.[2] Neu ist die Idee nicht: Amazon hat MicroVMs für KI-Agenten schon als Dienst in AWS Lambda verpackt, und Clawk stellt dem Agenten eine Wegwerf-VM hin. Neu ist der volle Docker-Daemon darin.[3]

Wo endet der Schutz der MicroVM?

Der Netzzugang bleibt die offene Flanke. Die MicroVM begrenzt, was ein entgleister Agent auf dem Rechner anrichtet, nicht aber, was er nach draußen schickt. Simon Willison hat die drei Bedingungen dafür schon im Juni 2025 zusammengeführt: Zugriff auf private Daten, Kontakt mit fremden Inhalten und ein Kanal nach außen.[4] In einer Coding-Sandbox liegen alle drei nebeneinander. Genau darauf zielt jede Prompt Injection.

Zugangsdaten für die eingebauten Dienste schiebt ein Proxy erst in die ausgehende Anfrage. Zwei Lücken nennt die Dokumentation trotzdem. Eigene Umgebungsvariablen aus /etc/sandbox-persistent.sh liest der Agent im Klartext, und die Zwischenablage des Hosts bleibt nur ohne ausdrückliche Freigabe verschlossen.[3] Ein einziger offener Kanal genügt, wie der Datenabfluss über Atlassian Rovo zeigte.

Docker formuliert den Kern in einem Satz: „Ein Sprachmodell, das seine eigenen Sicherheitsgrenzen festlegt, ist kein Sicherheitsmodell.“[1] Die Grenze gehört in die Infrastruktur, nicht in den Systemprompt, und darüber entscheidet die Geschäftsführung.

Docker Sandboxes verkleinern den Schadensradius auf dem Entwicklerrechner. Den Abfluss von Zugangsdaten verhindert erst eine harte Netzregel, und die setzt die IT-Leitung, nicht der Agent.

— Markus Seyfferth, Chefredakteur Dr. Web

Symbol Prozessor

1 Kernel

je Agentensitzung

Jede Sandbox erhält eine eigene MicroVM samt eigenem Docker-Daemon.

Symbol gestapelte Flächen

3 Hypervisoren

aus einer Codebasis

Der eigene VMM von Docker spricht Hypervisor.framework, Windows Hypervisor Platform und KVM an.

Symbol Kommandozeile

9 Agenten

laufen bereits darin

Darunter Claude Code, Codex, die Gemini CLI, die Copilot CLI, OpenCode und Kiro.

Symbol Schlüssel

2.349

erbeutete Zugangsdaten

So viele Zugangsdaten sammelte der s1ngularity-Angriff im August 2025 auf 1.079 Entwicklerrechnern ein.

Symbol Uhr

24 Stunden

Frühwarnfrist ab 11.09.2026

So schnell verlangt der Cyber Resilience Act die Meldung einer ausgenutzten Schwachstelle.

Die offene Flanke bleibt der Netzzugang

Die MicroVM begrenzt den Schaden auf dem Entwicklerrechner. Den Abfluss von Zugangsdaten über eine erlaubte Verbindung hält die MicroVM nicht auf.

Was müssen Teams in Deutschland jetzt regeln?

Der Präzedenzfall liegt vor. Am 26. August 2025 landeten manipulierte Nx-Versionen auf npm; das Postinstall-Skript rief lokale KI-Assistenten mit Schaltern wie --yolo und --trust-all-tools auf. GitGuardian zählte danach 2.349 erbeutete Zugangsdaten von 1.079 Rechnern.[5] Eine MicroVM hätte den Rechner geschützt, den GitHub-Token im eingebundenen Projekt jedoch nicht. Dieselbe Angriffsklasse traf zuletzt das npm-Paket Keyv.

Ab dem 11. September 2026 greift zudem die Meldepflicht des Cyber Resilience Act (Verordnung (EU) 2024/2847, Artikel 14): Wird eine Schwachstelle aktiv ausgenutzt, geht binnen 24 Stunden eine Frühwarnung an das zuständige CSIRT und an die ENISA.[6] Code aus einem unbeaufsichtigten Agenten fällt unter dieselbe Pflicht wie handgeschriebener. Ein Schwachstellen-Scan im Coding-Agenten verkürzt dabei den Weg zum Befund.

Zwei Stellschrauben gehören vor den ersten unbeaufsichtigten Lauf geklärt. Der Agent bekommt eine Positivliste erlaubter Zieldomains statt offenen Netzzugangs, und persönliche Zugangsdaten wandern aus den Umgebungsvariablen in einen Tresor mit kurzlebigen Token. Wie oft die menschliche Kontrolle sonst versagt, zeigt eine Untersuchung zur Freigabe von KI-Agenten.

Ein Pilotlauf klärt die Lage schneller als jede Richtlinie. Installieren Sie sbx gerne auf einem Rechner und lassen Sie einen Agenten in der schärfsten Netzeinstellung an einem unkritischen Repository arbeiten. Das Verbindungsprotokoll zeigt danach, wie viel Autonomie Ihr Team verantworten kann.

Quellen

[1] Docker: „Why MicroVMs: The Architecture Behind Docker Sandboxes“, 16. April 2026

[2] Docker: „Docker Sandboxes: Run Agents in YOLO Mode, Safely“, 31. März 2026

[3] Docker Docs: „Docker Sandboxes FAQ“

[4] Simon Willison: „The lethal trifecta for AI agents“, 16. Juni 2025

[5] GitGuardian: „The Nx s1ngularity Attack: Inside the Credential Leak“

[6] Verordnung (EU) 2024/2847 (Cyber Resilience Act), Artikel 14 (Meldepflichten der Hersteller)

Mehr Newshunger?

Схожие новости

#Наименование новостиТональностьИнформативностьДата публикации
1Python in a Sandbox With MicroPython and WASM07.1628-06-2026
2OpenSandbox - sandbox platform for AI applications01016-03-2026
3Ausbruch aus der Sandbox: Darum hätte OpenAI den Angriff auf Hugging Face kommen sehen müssen011.529-07-2026
4Хватит засовывать всё в контейнеры: возвращаем комфорт в локальную разработку08.8427-06-2026
5agentfield - Kubernetes for AI Agents01019-03-2026
6Собираем Docker-шаблон для Python с Poetry: шаг за шагом018.1706-01-2026
7Slim Down Python Docker Containers07.701-06-2026
8Giant Swarm öffnet KI-Agenten-Plattform in Kubernetes-Umgebungen für Kunden0509-07-2026
9AI Agent Governance: Securing Autonomous Agents in Production010.4124-07-2026

Классификация: Мнения. Схожих патентов: 0. Схожих новостей: 9. Тональность: 0. Информативность: 18.06. Источник: www.drweb.de.