Von Soft Trust zu Hard Walls: Wie sichere Agent-Autonomie wirklich aussieht

In Claude Code gibt es ein Flag namens --dangerously-skip-permissions. Der Name sagt es direkt: Es gibt dem Agent vollen Zugriff auf dein System — Dateischreibvorgänge, Shell-Befehle, Netzwerkaufrufe — ohne nachzufragen. Manche Entwickler schwören drauf. Die haben sich Aliases gebaut, ganze Projekte damit automatisiert, neun Stunden am Stück laufen lassen, Production-Code geshipped während sie geschlafen haben.

Den Reiz verstehe ich. Ich kenne ihn selbst. Jeder Permission-Prompt, der einen Flow-State unterbricht, ist eine Steuer auf das, was Agents eigentlich wertvoll macht: Autonomie. Aber ich habe auch genug Zeit mit Production-Systemen verbracht, um zu wissen, was passiert, wenn man Sicherheit gegen Geschwindigkeit tauscht, ohne die Fehlermodi wirklich durchzudenken.

Diesen Weg sind wir nicht gegangen. Stattdessen haben wir etwas anderes gebaut — ein System aus 18 spezialisierten Agents, jeder mit klar definierten Anweisungen, operativem Logging und einem Optimizer, der das Verhalten aller Agents kontinuierlich weiterentwickelt. Läuft seit Monaten. Funktioniert gut.

Und ich vertraue ihm trotzdem nicht vollständig.

Was wir tatsächlich gebaut haben

Unser Entwicklungs-Workflow läuft über einen Orchestrator, der an spezialisierte Agents delegiert. Jeder Agent hat eine bestimmte Rolle und klare Grenzen:

• Ein Git-Agent, der Commits, Pushes und Branch-Management übernimmt — aber keine Anweisungen hat, Source Code zu bearbeiten
• Ein Code-Reviewer, der Änderungen analysiert und Probleme benennt — aber keine Dateien schreiben kann
• Ein Implementierer, der Kotlin oder TypeScript schreibt — aber keine Git-Operationen ausführt
• Ein Test-Runner, der Tests ausführt und Ergebnisse meldet — aber weder debuggt noch fixt
• Ein Jenkins-Handler, der CI-Fehler diagnostiziert — mit reinem Lesezugriff auf Build-Logs

Achtzehn Agents insgesamt, die den kompletten Lebenszyklus vom Jira-Ticket bis zum produktionsreifen PR abdecken. Der Orchestrator entscheidet, wer woran arbeitet. Jeder Agent schreibt bemerkenswerte Ereignisse in themenbasierte operative Logs. Ein Meta-Agent liest diese Logs regelmäßig, erkennt Muster und aktualisiert die Anweisungen der anderen Agents.

Das ist ein echtes System. Es bearbeitet echte Tickets. Es spart Stunden stumpfer Arbeit pro Session.

Und jede einzelne dieser Grenzen ist ein Vorschlag.

Das Problem mit Soft Constraints

Was ich mit Soft Constraints meine: Wenn die Anweisungen des Git-Agents sagen „bearbeite niemals Source Code”, dann ist das Text in einer Markdown-Datei, die in den Kontext des Agents geladen wird. Keine Dateisystemberechtigung. Kein Docker-Volume-Mount. Eine höfliche Bitte an ein Sprachmodell.

Heute funktioniert das. Die Agents halten ihre Anweisungen zuverlässig ein. Der Git-Agent committet und pusht, ohne Source-Dateien anzufassen. Der Code-Reviewer schreibt seine Analyse, ohne die Codebase zu verändern. Die Grenzen halten.

Aber ich weiß genau, warum sie halten — und keiner der Gründe ist dauerhaft.

Modell-Updates können Verhalten verschieben. Wir laufen auf Claude. Wenn Anthropic eine neue Modellversion ausrollt — und das passiert regelmäßig — kann sich die Interpretation der Anweisungen durch den Agent subtil verändern. Nicht dramatisch, nicht absichtlich. Aber die Art von schleichendem Verhaltensdrift, den man nicht bemerkt, bis etwas schiefgeht. Ein Agent, der auf einer Modellversion zuverlässig in seiner Spur blieb, könnte „hilf bei Git-Operationen” auf der nächsten etwas großzügiger verstehen.

Agent-Optimierung erzeugt Drift. Unser Meta-Agent aktualisiert die Anweisungen der anderen Agents auf Basis beobachteter Muster. Das ist mächtig — unsere Agents lernen und werden besser. Es bedeutet aber auch, dass sich ihr Verhalten im Laufe der Zeit auf schwer vorhersagbare Weise entwickelt. Eine Optimierung, die den Implementierer hilfreicher macht, könnte ihn auch bereitwilliger machen, über seinen ursprünglichen Scope hinauszugehen. (Wie dieser Optimizer designt ist — und warum Agents aufzeichnen, während der Optimizer denkt — steht in Agents Record, Optimizer Thinks.)

Kontextdruck biegt Regeln. Sprachmodelle sind probabilistisch. Gib einem Agent eine komplexe Aufgabe mit ausreichend Kontext, und weiche Grenzen werden zu Vorschlägen. Nicht weil das Modell bösartig ist — weil es versucht, hilfreich zu sein. Und „hilfreich” bedeutet manchmal, aus der Box herauszutreten, die man um es gezeichnet hat.

Das habe ich selbst erlebt. Nicht katastrophal — wir fangen solche Fälle ab, weil wir den Agent-Output reviewen. Aber genau das macht Soft Constraints so gefährlich: dass sie meistens funktionieren. Sie bauen falsches Vertrauen auf. Man hört auf zu prüfen. Und dann hält die Grenze ausgerechnet dann nicht, wenn es am meisten zählt.

Was —dangerously-skip-permissions richtig macht

Ich will fair sein zu den Entwicklern, die das Flag nutzen. Die haben ein echtes Problem erkannt.

Permission-Prompts reißen aus dem Flow. Wenn man mit einem Agent eine Codebase erkundet und er für ein simples ls um Erlaubnis fragen muss, ist das Reibung ohne jeden Sicherheitswert. Wenn er für das Anlegen eines Verzeichnisses wartet, zahlt man eine Aufmerksamkeitssteuer für eine risikofreie Operation.

Die Entwickler, die das Flag sinnvoll einsetzen, machen dabei etwas Kluges: Sie isolieren ihre Umgebung zuerst. Docker-Container. Dedizierte VMs. Wegwerf-Workspaces. Sie geben dem Agent nicht vollen Zugriff auf ihre Maschine — sie geben ihm vollen Zugriff auf eine Sandbox, in der der Schaden bei einem Fehler begrenzt ist.

Das ist die Erkenntnis, die zählt: Die Frage ist nicht, ob man dem Agent vertraut. Die Frage ist, was passiert, wenn das Vertrauen falsch war.

Wenn die Antwort „ein Docker-Container wird zerstört und ich baue ihn in dreißig Sekunden neu” lautet, ist das ein handhabbares Risiko. Wenn die Antwort „er hat meine Git-Historie gelöscht” oder „er hat Credentials in ein öffentliches Repo gepusht” lautet, ist sie es nicht.

Warum wir Hard Walls brauchen

Soft Constraints sagen dem Agent, was er tun soll. Hard Walls legen fest, was er tun kann.

Der Unterschied ist wichtig, weil wir Systeme bauen, die stundenlang laufen, über mehrere Sessions hinweg, mit Agents, die ihr Verhalten ständig weiterentwickeln. Kein Pair Programming, bei dem ein Mensch jede Aktion beobachtet. Wir orchestrieren — wir geben die Richtung vor und reviewen die Ergebnisse. Dazwischen trifft der Agent hunderte Entscheidungen selbstständig.

In diesem Kontext reicht „der Agent hält sich meistens an seine Anweisungen” nicht aus. Wir brauchen:

Dateisystem-Isolation. Ein Agent, der Build-Logs lesen soll, sollte keinen Schreibzugriff auf Source Code haben. Nicht weil wir ihm das verboten haben — weil das Dateisystem es schlicht nicht zulässt. Ein schreibgeschützt gemountetes Volume ist eine Grenze, die keine noch so hilfreiche Neuinterpretation aushebeln kann.

Netzwerk-Grenzen. Ein Agent, der Code analysiert, sollte keine ausgehenden HTTP-Requests an beliebige Endpunkte schicken können. Nicht weil seine Anweisungen das verbieten — weil die Network Policy des Containers es blockiert.

Credential-Trennung. Agents mit GitHub-Zugriff sollten keine AWS-Credentials sehen. Agents, die Jira lesen, sollten keinen Schreibzugriff auf Produktionsdatenbanken haben. Heute verlassen wir uns darauf, dass Agents nichts anfassen, was sie nichts angeht. Morgen wollen wir, dass sie es schlicht nicht können.

Zeit- und Ressourcenlimits. Ein Agent, der neun Stunden läuft, ist beeindruckend. Es sind auch neun Stunden unbeaufsichtigter autonomer Aktion. Harte Limits für Laufzeit, CPU, Speicher und Festplattennutzung sind keine Vertrauensfrage — sie begrenzen den Schaden bei jedem Fehler, einschließlich der, die man sich noch nicht vorstellen kann.

Was wir als Nächstes bauen

Wir haben das noch nicht umgesetzt. Ich bin ehrlich: Wir haben Soft Constraints, die heute funktionieren, und eine klare Vorstellung von den Hard Walls, die wir morgen brauchen.

Aber es gibt ein praktisches Problem, das wir zuerst angehen müssen.

Die Realität: Alles läuft in einem Prozess

Heute laufen unser Orchestrator und alle 18 Sub-Agents in derselben Claude-Code-Terminalsession. Gleicher Prozess. Gleiches Dateisystem. Gleiche Benutzerrechte. Wenn der Orchestrator einen Git-Agent oder einen Code-Reviewer startet, ist dieser Agent ein Kindprozess mit demselben Zugriff auf alles auf der Maschine.

Die AGENT.md-Anweisungen schaffen Rollentrennung. Die Runtime nicht.

Das bedeutet: Selbst wenn wir perfekte Docker-Isolation für einzelne Agents bauen würden, müssten wir zuerst ein schwierigeres Problem lösen — wie startet man einen Sub-Agent in seinem eigenen Container, wenn das Orchestrierungs-Framework erwartet, dass alles als Kindprozesse in derselben Session läuft?

Wir haben darüber nachgedacht. Und festgestellt: Der richtige Ansatz ist nicht, mit dem schwierigsten Problem anzufangen. Sondern mit dem Schritt, der den höchsten Effekt bei geringstem Aufwand hat — und dann iterieren.

Der Drei-Stufen-Plan

Stufe 1: Die gesamte Session containerisieren. Statt einzelne Agents zu sandboxen, die komplette Claude-Code-Session — Orchestrator und alle Sub-Agents — in einen einzigen Docker-Container packen. Nur das Projekt mounten, an dem man gerade arbeitet. Nur die Credentials injizieren, die die Session braucht. Network Policies auf Container-Ebene anwenden.

Das ist einfach zu implementieren: ein Dockerfile, ein Launch-Script mit projektspezifischen Profilen und Volume-Mounts, die pro Projekt begrenzt sind. Es isoliert die Agents nicht voneinander, aber es isoliert das gesamte Agent-System vom Rest der Maschine. Die anderen Projekte, die AWS-Credentials, die SSH-Keys für Produktionsserver — nichts davon ist zugänglich.

Stufe 2: Per-Agent-Profile innerhalb des Containers. Linux Namespaces oder eingeschränkte Shell-Umgebungen nutzen, um verschiedenen Agents verschiedene Berechtigungen innerhalb desselben Containers zu geben. Der Git-Agent bekommt Netzwerkzugriff auf GitHub. Der Implementierer bekommt Schreibzugriff auf Source-Dateien, aber kein Netzwerk. Der Code-Reviewer bekommt Lesezugriff auf alles.

Das ist anspruchsvoller, erfordert aber kein Neuschreiben der Orchestrierungsschicht. Die Agents laufen weiterhin als Kindprozesse — ihre Systemberechtigungen unterscheiden sich trotzdem.

Stufe 3: Agent-per-Container mit API-Kommunikation. Die vollständige Vision: Jeder Agent läuft in seinem eigenen isolierten Container. Der Orchestrator kommuniziert über API-Calls statt Kindprozesse zu starten. Jeder Container hat eigene Dateisystem-Mounts, Network Policies, Credentials und Ressourcenlimits.

Das ist am aufwändigsten, bietet aber die stärkste Isolation. Dort soll die Architektur am Ende landen.

So sieht der Zielzustand aus — Soft Trust und Hard Walls, die zusammenarbeiten:

Der Container ersetzt die Anweisungen des Agents nicht — er umschließt sie. Die AGENT.md steuert das Verhalten. Der Container regelt, was passiert, wenn die Anweisung nicht ausreicht.

Und auf der vollständigen Isolationsstufe bekommen verschiedene Agents verschiedene Containment-Profile:

Ein Code-Reviewer, der nur liest, bekommt eine minimale Sandbox. Ein Implementierer, der Code schreibt, eine großzügigere. Ein Git-Agent, der auf Remote pusht, die engsten Netzwerkkontrollen.

Warum Stufe 1 am meisten bringt

Stufe 1 — die gesamte Session containerisieren — liefert 80% des Sicherheitsgewinns mit 20% des Aufwands.

Was das konkret ausschließt: Ein Agent kann nicht mehr das Home-Verzeichnis durchsuchen, Credentials aus anderen Projekten lesen, auf Produktions-SSH-Keys zugreifen oder Daten übers Netzwerk abziehen (außer man erlaubt es explizit). Der mögliche Schaden schrumpft von „alles auf der Maschine” auf „ein Projektverzeichnis”.

Das ist ein massiver Fortschritt. Und es ist ein Dockerfile plus ein Launch-Script.

Wir bauen das zuerst. Wir werden berichten, was funktioniert, was nervt, welchen Performance-Overhead der Container mitbringt, ob sich der Workflow anders anfühlt. Dann iterieren wir in Richtung Per-Agent-Isolation, wenn die Orchestrierungstools dafür reif sind.

Die unbequeme Wahrheit über Vertrauen

Ich betreibe AI-Agents seit Monaten in meinem Entwicklungs-Workflow. Sie haben tausende Zeilen Code geschrieben, dutzende Tickets bearbeitet, Bugs gefunden, die ich übersehen hätte. Sie sind wirklich gut in dem, was sie tun.

Und ich halte es für verantwortungsvoll, davon auszugehen, dass sie irgendwann etwas tun werden, das ich nicht erwartet habe.

Nicht weil die Modelle unzuverlässig sind — sie sind bemerkenswert konsistent. Aber die Kombination aus sich entwickelnden Modellen, sich verändernden Agent-Anweisungen, komplexen mehrstufigen Aufgaben und langen autonomen Laufzeiten schafft einen Raum, in dem unerwartetes Verhalten keine Frage des Ob ist, sondern des Wann.

Die Entwickler, die --dangerously-skip-permissions in Docker-Containern nutzen, haben die richtige Intuition. Sie haben akzeptiert, dass Vertrauen allein nicht reicht, und eine physische Grenze um die Fähigkeiten des Agents gebaut. Nur die Granularität stimmt nicht — alles oder nichts, ein Container für alles.

Graduated Containment. Nicht weil wir unseren Agents nicht vertrauen — sondern weil Vertrauen ohne architektonische Absicherung nur Hoffnung ist.

Was das für Agentic Engineering bedeutet

Wer heute mit AI-Agents arbeitet, befindet sich wahrscheinlich in einer von drei Situationen:

Manueller Modus. Jede Aktion wird genehmigt. Sicher und langsam. Man wird irgendwann an Permission-Prompts ausbrennen und entweder aufhören, Agents zu nutzen, oder anfangen, Reviews zu überspringen.

YOLO-Modus. Alle Berechtigungen übersprungen. Schnell und fragil. Man bekommt beeindruckende Ergebnisse — bis man eines Tages eine beeindruckende Katastrophe bekommt.

Irgendwo dazwischen. Bestimmte Befehle sind vorab genehmigt, ein paar Grenzen gesetzt — aber man weiß, dass die Constraints weich sind und die Umgebung nicht wirklich isoliert ist.

Wir sind in diesem dritten Lager. Ehrlich. Wir haben ein ausgefeiltes Multi-Agent-System mit Logging, Optimierung und klar definierten Rollen — und noch kein hartes Containment. Wir bauen es. Wir werden schreiben, was funktioniert und was nicht.

Die Lektion aus unserem bisherigen Weg: Fang mit Soft Constraints an, weil sie schnell umsetzbar sind und dir zeigen, wo die echten Grenzen liegen müssen. Monatelange Erfahrung mit 18 Agents und anweisungsbasiertem Scoping hat uns gezeigt, wo Vertrauen zusammenbricht und welche Art von Containment jeder Agent-Typ braucht. Ohne diese Erfahrung hätten wir die Docker-Architektur gar nicht entwerfen können. (Ein verwandtes Risiko — Claude Codes Auto-Memory-Feature als weiteres Soft Constraint, das unter autonomem Betrieb driften kann — ist in The Clean Slate Is Gone beschrieben.)

Aber bleib nicht bei Soft Constraints stehen. Das Ziel ist ein System, in dem Agents produktiv und gleichzeitig eingeschränkt sind — in dem der schlimmste denkbare Agent-Fehler ein paar Minuten Arbeit kostet, nicht die Codebase, die Credentials oder die Production-Umgebung.

Wir sind noch nicht da. Wir bauen darauf hin. Und wir teilen, was wir auf dem Weg lernen.