Warum steht die Grenze eines Agenten nicht in seinem Prompt?
Eine Regel in SOUL.md bindet den Agenten über den Prompt. Ein Guard-Rail greift fail-closed am Broker, an der Aktionsschicht und an der Freigabe.
Ein Agent bekommt eine Grenze, und der naheliegende Ort dafür ist seine Konfiguration. In SOUL.md steht dafür der Abschnitt ## Limits. Darin findet sich ein Satz wie dieser: „Keine Aktionen, die Kundendaten ohne Freigabe löschen."
Der Satz ist nicht wirkungslos, da er im Systemprompt jedes Laufs liegt und dort das Verhalten steuert.
Dann kommt ein Ticket herein, dessen Text wie eine Anweisung klingt. Oder eine Mail, die jemand präpariert hat. Die Regel steht weiter da, nur eben als ein Satz unter anderen Sätzen.
Eine Regel im Prompt bindet nur den, der sie befolgen will
Die Spezifikation nennt solche Grenzen selbstbindend: Sie steuern Verhalten und sind wertvoll, ohne eine Sicherheitsgrenze zu sein. Ein Prompt kann umgangen oder per Injection ausgehebelt werden.
Der Grund dafür liegt bei dem, der den Text auslegt: Eine Injection kompromittiert genau das Denken des Agenten, und dasselbe Denken entscheidet über die Regel.
Deshalb liegen die harten Grenzen außerhalb der Laufzeit, sodass der Agent sie weder lesen noch wegdiskutieren noch umgehen kann. Er merkt nur, dass eine Aktion verweigert wurde.
Der Prompt verschwindet deshalb nicht, denn beide Schichten zusammen ergeben das, was die Spezifikation Defense in Depth nennt.
Sieben Stellen, an denen die Plattform ohnehin sitzt
Neue Kontrollpunkte braucht ein Guard-Rail nicht, da er an sieben Orten greift, an denen Control Plane und Daemon den Datenfluss ohnehin führen.
Der Secrets-Broker entscheidet, für welches System und welchen Scope ein Agent überhaupt ein Token bekommt. Der Egress entscheidet, mit wem die Sandbox reden darf. In der Tool- und Aktionsschicht des Daemons entscheidet sich, welche Aktion läuft.
Dazu kommen vier weitere: die Freigabe-Warteschlange, Rate- und Kostengrenzen, ein Inhaltsfilter für PII und das Style-Gate.
Auf drei Ebenen gelten die Regeln: global für alle Agenten, für eine Rolle oder für einen einzelnen Agenten. Additiv-restriktiv heißt das Prinzip dahinter. Eine engere Ebene darf verschärfen, und eine globale Verweigerung bleibt für sie verbindlich.
Verwaltet werden sie von der Rolle Security und Compliance, absichtlich getrennt von denen, die die Agenten besitzen. Sonst könnte ein einzelner Teamleiter die organisationsweiten Grenzen lockern.
Im Zweifel wird verweigert
Fail-closed ist der Standard: Was nicht erlaubt ist, ist verboten. Im Zweifel wird eine Aktion blockiert oder an die Freigabe gegeben.
Die Voreinstellungen nach der Installation zeigen das Muster: Eine ausgehende Antwort an einen Kunden braucht eine Freigabe, und HR-Systeme sind gesperrt. Alles, was delete heißt, ist hart verweigert.
Die Freigabe beendet den Lauf nicht: Der Daemon meldet sie über request_approval an, die Control Plane hält die Aktion an, und der Agent steht so lange in blocked. Er wartet, ohne Rechenzeit zu verbrauchen. Sobald die Entscheidung da ist, macht er weiter.
Das Budget pro Agent folgt derselben Logik, nur gegen einen anderen Fehler. Es misst die kumulierten Kosten und wirkt damit als Lebenszeit-Obergrenze. Ist sie erreicht, wird der Agent pausiert und die laufende Aufgabe geht zurück ins Backlog. Eine Grenze pro Lauf oder pro Zeitraum haben wir nicht gebaut.
Ändern kann der Agent daran nichts, denn die Regeln liegen in der Control Plane und nicht in seiner Konfiguration. Ein Mensch mit der passenden Rolle ändert sie, und diese Änderung steht danach im Audit-Trail.
Das Style-Gate misst, was hinausgeht
Ein eigener Guard-Rail-Typ heißt style_gate, und er zeigt, dass der Mechanismus nicht nur Sicherheit ist.
Ein TONE.md beschreibt die Stimme eines Agenten, und wie jede Prompt-Regel ist auch sie selbstbindend. Nichts prüft den Text, der die Sandbox verlässt, gegen sie. Genau das übernimmt das Style-Gate. Es misst den freien Text einer Aktion, bevor die Aktion läuft, etwa einen GitLab-Kommentar oder eine Mail.
Der Maßstab ist der Profilblock in TONE.md nach dem Schema covey-style/1: Bänder pro Kennzahl, dazu absolute Grenzen wie ein Satz über 35 Wörter. Das Gate reagiert auf einen HIGH-Befund: auf eine Kennzahl eine volle Bandbreite außerhalb ihres Bands oder über einer absoluten Grenze. Texte unter 60 Wörtern misst es nicht, da ein einzeiliger Kommentar keinen Stil hat.
Bei deny wird die Aktion verweigert, und die Befunde sind die Begründung: welcher Absatz, welche Kennzahl, welches Band. Der Agent überarbeitet den Text und versucht es erneut. Nach zwei Ablehnungen zur selben Aufgabe und Aktion geht der Text an die Freigabe. Eine Schleife, die nicht konvergiert, endet so bei einem Menschen statt am Turn-Limit.
Zwei Grenzen sind mit Absicht gezogen. Erstens ist das Gate eine Messung und keine Sicherheitsgrenze: Fehlt das Profil, lässt es die Aktion durch und hält fest, dass es nicht gegriffen hat. Zweitens sitzt es nur auf dem Erlaubt-Pfad, und eine Verweigerung aus einer anderen Regel weicht es nie auf.
Damit ist der Preis benannt, denn ein Gate, das misst statt zu urteilen, verweigert manchmal einen brauchbaren Text.
Was am Ende bleibt, ist nicht nur die verhinderte Aktion. Ein Versuch, der am Guard-Rail scheitert, steht danach mit den Argumenten des Aufrufs als verweigerter Versuch in der Aufzeichnung. Eine Regel im Prompt hinterlässt kein solches Ereignis. Die Aktion selbst steht mit ihren Argumenten in der Aufzeichnung, ohne dass etwas sie dort als Regelbruch ausweist. Wird die Regel in der Control Plane gezogen, entsteht bei jedem Auslösen ein Ereignis.