← Essays

Grenzen statt Anweisungen: Wie man die Kontrolle über autonome KI-Agenten behält

Warum man die Kontrolle über KI-Agenten nicht auf Anweisungen im Prompt aufbauen kann – und wie man sie auf technischen Grenzen aufbaut. Fünf Vorfälle einer Sitzung.

7 Min. Lesezeit
TelegramOriginal
Grenzen statt Anweisungen: Wie man die Kontrolle über autonome KI-Agenten behält

Je autonomer KI-Agenten werden, desto häufiger versuchen wir, sie auf die gewohnte Weise zu steuern – wir schreiben Regeln in den Prompt: „Fass das nicht an“, „Arbeite nur dort“, „Mach niemals das“. Während eines Experiments mit drei parallelen Agenten habe ich in zwei Tagen eine lebendige Sammlung von Fällen zusammengetragen, in denen diese Methode versagt – und in denen eine andere funktioniert. Die These des Artikels ist einfach: Eine Anweisung ist eine Bitte, die der Agent mit einer gewissen Wahrscheinlichkeit befolgt; eine Grenze ist eine Eigenschaft des Systems, die nicht vom Gehorsam abhängt. Solange es nur einen Agenten gab, der unter Aufsicht arbeitete, schien der Unterschied stilistisch. Als es viele Agenten gab, erwies er sich als architektonisch.

Fünf Vorfälle einer Sitzung

Alle folgenden Fälle ereigneten sich in einer Arbeitssitzung in diesem Blog – sie sind dokumentiert, und jeder illustriert eine eigene Art, wie die Steuerung durch Text versagt.

Es gab keine Anweisung – und es kam zum Unfall. Der Agent führte bei der Vorbereitung seiner Aufgabe git stash im gemeinsamen Verzeichnis aus und nahm meine nicht committeten Dateien, die nichts mit seiner Aufgabe zu tun hatten, in den Stash mit. Niemand hat etwas „verletzt“: Ein Verbot existierte einfach nicht. Das ist eine grundlegende Eigenschaft von Anweisungen – sie werden nach Unfällen geschrieben. Eine vollständige Liste dessen, was ein Agent nicht tun darf, lässt sich nicht schreiben.

Es gab eine Anweisung – und sie griff nicht. Nach dem ersten Unfall fügte ich den Agenten eine ausdrückliche Regel hinzu: „Arbeite strikt in deinem Arbeitsverzeichnis“. Einer der Agenten führte dennoch einen git-Befehl im Hauptverzeichnis aus – er griff einfach über einen absoluten Pfad darauf zu. Nicht aus Bosheit und nicht aus Dummheit: Das Modell ist probabilistisch, und die Einhaltung einer Textregel ist ebenfalls eine Wahrscheinlichkeit, multipliziert mit der Länge des Kontexts und der Zahl der Durchläufe.

Eine technische Grenze griff still. Im selben Experiment ereignete sich nie der am meisten erwartete Unfall – „ein Agent hat allen den Branch umgeschaltet“. Nicht weil die Agenten sorgfältig waren, sondern weil git worktree es physisch unmöglich macht, einen Branch in zwei Arbeitskopien auszuchecken. Der Schutz ist in das Werkzeug eingebaut. Man muss ihn sich nicht merken, man muss ihn nicht befolgen – er ist einfach da.

Eine Anweisung stand dort, wo eine Grenze stehen sollte. Die unangenehmste Entdeckung: Das Prod dieses Blogs wurde von einer Zeile im Prompt bewacht. Ein Push in master löst das Autodeploy aus, und von jedem Agenten trennte ihn nur der Text „kein git push“. Er hielt – aber das war Glück, keine Kontrolle: Die echte Grenze wäre hier Zugriffsrechte, protected branch, ein Token ohne Schreibrecht. Eine Bitte stand an der Stelle eines Schlosses.

Eine Grenze über dem Agenten selbst. Zweimal während der Sitzung stoppte die Laufzeitumgebung nicht die Versuchsagenten, sondern meinen Hauptassistenten: Ein Berechtigungsklassifikator blockierte SSH zum Prod-Server und das massenhafte Löschen nicht committeter Änderungen – Aktionen, die formal aus der Aufgabe folgten, aber ein ausdrückliches menschliches „Ja“ erforderten. Beide Blockierungen waren richtig. Und beide geschahen über der „Disziplin“ des Agenten, der durchaus aufrichtig glaubte, nach Plan zu handeln.

Das Prinzip ist nicht neu – neu ist nur die Entität

Die Ingenieurwissenschaft hat diese Lektion lange vor LLMs gelernt. Im Toyota-Produktionssystem heißt das Prinzip poka-yoke: Ein Fehler wird durch eine Vorrichtung des Prozesses verhindert, nicht durch die Wachsamkeit des Ausführenden. Ein Bauteil, das man nur in der richtigen Ausrichtung einsetzen kann, ist zuverlässiger als ein Plakat „Richtig einsetzen“. In der Plattform-Engineering nennt man dasselbe Guardrails, in der Sicherheit Defense in Depth. Überall derselbe Gedanke: Verlass dich nicht darauf, dass der Ausführende gelesen, verstanden und nicht vergessen hat – sorge dafür, dass die falsche Aktion unmöglich oder teuer ist.

„Eine Anweisung ist eine Bitte. Eine Grenze ist eine Eigenschaft des Systems. Kontrolle, die auf Bitten beruht, ist keine Kontrolle, sondern Glück mit kumulativem Effekt.“

– die zentrale Erkenntnis aus zwei Tagen Arbeit mit parallelen Agenten

Bei KI-Agenten wird dieses alte Prinzip aus drei Gründen schärfer. Es gibt viele Agenten – die Wahrscheinlichkeit des Versagens einer Anweisung multipliziert sich mit jedem Durchlauf jedes Agenten. Agenten sind schnell – zwischen „begann zu irren“ und „hat endgültig kaputtgemacht“ vergehen Sekunden, der Mensch schafft es nicht einzugreifen. Und Agenten sind wörtlich, aber nicht zuverlässig: Sie befolgen den Prompt-Text sorgfältiger als jeder Junior, und dennoch probabilistisch – und probabilistische Regelbefolgung garantiert im Maßstab die Verletzung.

Wie Grenzen in der Praxis aussehen

Die Schichten, die ich nach dieser Sitzung aufgebaut habe – vom Dateisystem bis zur Verifikation:

  • Dateisystem: jeder Agent bekommt eine eigene Arbeitskopie (git worktree, den Anthropic empfiehlt für parallele Sitzungen, in Claude Code ist er eingebaut), und auf OS-Ebene eine Sandbox: Sandboxing in Claude Code isoliert Dateisystem und Netzwerk mit Bordmitteln des Betriebssystems – laut Anthropic reduzierte dies ihre internen Berechtigungsanfragen um 84%, und eine erfolgreiche Prompt-Injection bleibt darin eingesperrt.
  • Schreibrechte: prod und master werden durch Rechte geschützt, nicht durch den Prompt — protected branch, Tokens ohne Push-Recht, separate Konten für Agenten. Bitten, im Prompt zu bleiben, sind möglich, aber als zweite Schicht.
  • Runtime: worktree isoliert keine Datenbanken, Ports und Container — sie sind für alle Kopien gemeinsam. Agenten, die Tests und Server starten, brauchen Einweg-Ressourcen: eine temporäre DB, einen eigenen Port, einen Container pro Agent.
  • Berechtigungen für Aktionen: irreversible Operationen laufen über eine Bestätigung oder einen Klassifikator — wie auto mode in Claude Code, der jede Aktion bewertet, statt entweder alles abzufragen oder nichts abzufragen. Das ist eine Grenze, die sich nur durch eine ausdrückliche menschliche Entscheidung verschiebt.
  • Verifikation anhand von Artefakten: nicht dem Selbstbericht des Agenten vertrauen, sondern den Spuren auf der Festplatte. Mein hängengebliebener Agent sah in der Oberfläche arbeitend aus; die Diagnose stellte das Fehlen neuer Dateien in seiner Kopie über zwanzig Minuten. Commits in den eigenen Branch — dieselbe Idee: ein Ergebnis, das sowohl einen Ausfall als auch den Optimismus des Agenten überlebt.

Anweisungen verschwinden in diesem Schema nicht — sie werden zur letzten Schicht, nicht zur ersten. „Arbeite in deinem Verzeichnis“ im Prompt ist weiterhin nützlich: es senkt die Häufigkeit von Versuchen. Aber zwischen Versuch und Havarie muss eine Grenze stehen, nicht Hoffnung.

Ehrliche Vorbehalte

Die Grenze ist nicht absolut: Sandboxes werden umgangen, Klassifikatoren irren sich, und veröffentlichte Analysen von Umgehungen zeigen das regelmäßig. Deshalb baut man Grenzen in Schichten — wie alles in der Sicherheit. Und eine Grenze kostet am Start mehr als eine Anweisung: worktree, Rechte und Sandbox einzurichten — das sind Stunden, eine Zeile in den Prompt zu schreiben — Sekunden. Die Asymmetrie liegt woanders: eine Grenze wird einmal bezahlt, eine Anweisung — mit der Wahrscheinlichkeit eines Fehlschlags bei jedem Durchlauf. Bei mir hat sich die Einrichtung der Isolation beim ersten Neustart des Experiments bezahlt gemacht, das ohne einen einzigen Konflikt durchlief.

Fazit

Die Frage der Serie — wie man AI-Agenten in die reale Arbeit einbettet, ohne die Kontrolle zu verlieren. Die Antwort dieses Artikels: Kontrolle ist nicht das, was dem Agenten geschrieben steht, sondern das, was um ihn herum eingerichtet ist. Bevor man dem Prompt ein weiteres „mach niemals X“ hinzufügt, sollte man sich fragen: Kann man X technisch unmöglich machen? Wenn ja — dann ist das der richtige Ort für die Anstrengung. Der Prompt soll bitten; das System muss verbieten.

Quellen und Orientierung

← Alle Essays