3 Min. Lesezeit

KI-Agenten brauchen eine Sandbox, keinen Standard-Bypass

AI-агентыконтейнеризацияsandboxкибербезопасность

Vorfälle mit gelöschten Festplattenpartitionen zeigen, warum KI-Agenten standardmäßig keine umfassenden Rechte erhalten dürfen. Eine sichere Architektur kombiniert eine isolierte Sandbox, minimale Privilegien, stark begrenzten Netzwerkzugriff und menschliche Freigaben für destruktive Aktionen. Der Bypass-Modus gehört nur in streng abgegrenzte Umgebungen mit reversiblen Vorgängen.

Ein Container muss Schäden begrenzen, nicht Sicherheit vortäuschen

Nach Vorfällen mit gelöschten Festplattenpartitionen würde ich nicht über Berechtigungseinstellungen diskutieren, solange der Agent den Host überhaupt sehen kann. Die wichtigste Erkenntnis ist einfach: Autonomie ist nur innerhalb einer Umgebung vertretbar, in der ein Fehler nicht zum Verlust einer Partition, von Geheimnissen oder der Systemkonfiguration führen kann.

In der Diskussionszusammenfassung, auf der diese Notiz basiert, werden weder die Organisation noch das Originaldokument genannt. Zum 6. September 2026 sind auch die Daten der Vorfälle nicht angegeben. Deshalb betrachte ich das Thema als Architekturanalyse und nicht als aktuelle Produktmeldung. Besprochen werden zwei Modi: Online-Zugriff nach menschlicher Freigabe und standardmäßig aktivierte bypass permissions.

Ein Container allein löst das Problem nicht. Eine belastbare Grenze umfasst den Betrieb ohne root, das Entfernen unnötiger Linux-Capabilities, ein schreibgeschütztes Dateisystem und genau ein beschreibbares Arbeitsverzeichnis. Zur stärkeren Isolierung nennt die Zusammenfassung außerdem gVisor, microVMs, Landlock, AppArmor und Mechanismen auf SELinux-Ebene.

Dem Netzwerk sollte man genauso wenig vertrauen wie der Festplatte. Ausgehende Verbindungen dürfen nur zu freigegebenen Diensten führen; Zugangsdaten sollten pro Aufgabe mit engem Geltungsbereich ausgegeben und danach widerrufen werden. Getrennte Identitäten für Modell, Agenten-Controller und Werkzeuge verkleinern den Schadensradius, wenn eine Ebene kompromittiert wird.

Ich würde außerdem den Socket der Container-Runtime, übergeordnete Verzeichnisse, eingebundene Geheimnisse und jede Möglichkeit prüfen, den Netzwerkzugriff über ein verfügbares Werkzeug auszuweiten. Durch genau solche Lücken wird aus einem Container schnell keine Sandbox mehr, sondern eine dekorative Schachtel.

Bypass ist nur für vorab begrenzte Aktionen sinnvoll

Der richtige Ausgleich liegt nicht zwischen vollständiger Autonomie und ständigen Bestätigungsfenstern. Ein Agent kann Dateien automatisch lesen, Daten im Arbeitsverzeichnis bearbeiten und reversible Befehle ausführen, wenn diese Vorgänge den Host physisch nicht berühren können.

Dateilöschungen, Änderungen an Partitionen, Zugriff auf Geheimnisse, Systemeinstellungen und Verbindungen außerhalb der Netzwerk-Allowlist müssen durch eine Policy Engine und eine menschliche Freigabe gehen. Die Berechtigung sollte an eine konkrete Aktion gebunden sein, nicht an die gesamte Sitzung: Die Zustimmung zu einem Befehl darf nicht zu einem dauerhaften Freifahrtschein werden.

Die Kosten menschlicher Kontrolle sind offensichtlich: Der Agent arbeitet langsamer und hält häufiger an. Ein umfassender Bypass ohne strikte Isolierung tauscht jedoch nur Komfort gegen einen größeren Ausfallradius. Autonomie beginnt nicht mit einer Auto-Allow-Schaltfläche, sondern mit dem Nachweis, dass der Agent fast nichts beschädigen kann.

Wir haben zuvor Pydantic Monty untersucht, einen sicheren Python-Interpreter zur Ausführung von LLM-generiertem Code ohne Container. Dieser Ansatz hilft, die Isolierung einer Umgebung mit den Risiken umgangener Berechtigungen bei KI-Agenten zu vergleichen.