Coding-Agenten sicher betreiben: Sandbox auf Kubernetes einrichten

TL;DR

Ein Coding-Agent auf dem Laptop arbeitet mit den Rechten des Mitarbeiters, inklusive Dateisystem, interner Zugänge und Schlüssel. Die betreibbare Alternative ist eine Sandbox auf dem eigenen Kubernetes-Cluster: frischer Container je Lauf, nur freigegebene Repos, Secrets erst zur Laufzeit, Netzwerk nur nach Allowlist und ein Audit-Log über jede Aktion des Agenten.

Warum der Laptop der falsche Ort ist

Das Problem ist nicht der Mitarbeiter, sondern die Berechtigung. Ein Agent, der Shell-Befehle ausführt und Dateien schreibt, kann im Zweifel auch die falsche Datenbank löschen oder Code an ein externes Ziel schicken. Dazu kommt die Schatten-Nutzung im Home Office mit privaten Accounts, bei der Firmendaten außerhalb jeder Freigabe landen. Mitarbeiter-Überwachung löst das nicht und ist arbeitsrechtlich der falsche Weg. Kontrolliert wird deshalb die Umgebung, in der der Agent läuft.

Architektur der Sandbox

Drei Bausteine reichen für den Start. Erstens ein eigener Namespace je Team oder Aufgabe, in dem Agenten-Container mit Resource Limits und einer Laufzeitbegrenzung starten. Für hohe Ansprüche kommt eine stärkere Runtime-Isolation wie gVisor oder Kata dazu, damit ein Ausbruch aus dem Container nicht auf dem Node endet. Zweitens eine browser-basierte Entwickler-Umgebung im Firmennetz nach dem Coder-Muster: Der Entwickler öffnet eine Session, der Agent arbeitet im Container mit den freigegebenen Repos, lokal liegen keine Secrets und keine direkten Datenbank-Zugänge mehr. Drittens eine eigene Service-Identität je Agenten-Umgebung. Der Agent handelt nicht als der Mitarbeiter, der ihn startet, sondern mit minimalen, im Vorfeld definierten Rechten.

Secrets, Netzwerk und Packages absichern

Secrets gehören nicht in Repo, Prompt oder Laptop. Sie liegen zentral, zum Beispiel in einem Vault, und werden über External Secrets erst zur Laufzeit in den Container gegeben. Connection Strings verwaltet die Plattform, der Agent sieht nur die Verbindung, die er für seine Aufgabe braucht. Beim Netzwerk gilt die Umkehr der üblichen Logik: Standard ist verboten, erlaubt ist nur, was auf der Egress-Allowlist steht, umgesetzt über Network Policies. So kann eine vom Agenten gebaute App nicht unbemerkt nach außen kommunizieren. Für Software- und Python-Packages betreiben Sie eine zentrale, geprüfte Registry mit CVE-Scanning. Der Agent installiert nur von dort. Das schließt die Lücke, über die KI-vorgeschlagene Dependencies zur Supply-Chain-Falle werden.

Überwachung: Der Agent wird geloggt, nicht der Mensch

Jeder Lauf schreibt ein Audit-Log: gestartete Werkzeuge, geänderte Dateien, angesprochene Netzwerkziele, Modell-Aufrufe und Kosten. Technisch ist das Container- und Gateway-Logging, keine Arbeitsplatzüberwachung. Am AI Gateway, der einzigen Tür zu den Modellen, sehen Sie zusätzlich Budgets und Aufrufe je Team. Auffälligkeiten wie ungewöhnliche Netzwerkziele oder Kostensprünge lösen Alerts aus. Damit hat die zentrale IT den Nachweis für Security und Compliance, ohne eine einzige Mitarbeiter-Aktivität zu protokollieren, die nicht vom Agenten stammt.

Betrieb und nächste Schritte

Im Betrieb zählen drei Routinen: Templates und Golden Paths pflegen, damit neue Teams nicht bei null anfangen, Freigaben für Repos, Modelle und Packages in einem festen Rhythmus prüfen und das Audit-Log stichprobenartig mit den Alerts abgleichen. Wer die Plattform nicht selbst betreiben will, lässt sie als Managed Service laufen. Wie das als Gesamtangebot aussieht, zeigt die Seite zur AI-Agenten-Plattform auf Kubernetes unserer Muttergesellschaft Pexon Consulting, inklusive Einstieg über einen Agenten-Risiko-Scan.

Fazit

Die Sandbox auf Kubernetes nimmt dem Agenten die Mitarbeiter-Rechte und gibt der IT die Kontrolle zurück, ohne Mitarbeiter zu überwachen. Isolation, eigene Identität, Secrets zur Laufzeit, Egress-Allowlist und Audit-Log sind kein Großprojekt, sondern eine betreibbare Grundeinstellung auf dem Cluster, den die meisten Häuser schon haben.