Regeln im Prompt sind keine Grenze: Agenten-Richtlinien außerhalb des Agenten durchsetzen

Die meisten Agenten werden mit ihren Regeln im Systemprompt ausgeliefert. Du bist ein hilfreicher Assistent. Sende niemals Kundendaten aus dem Unternehmen. Frage immer, bevor du etwas löschst. Danach hofft das Team, dass das Modell sich daran hält, und meistens tut es das.

Das Security-Review fragt nicht, ob das Modell sich meistens daran hält. Es fragt, ob Sie nachweisen können, dass der Agent keine Daten nach außen senden kann. Ein Satz im Prompt ist keine Antwort auf diese Frage, und keine bessere Formulierung macht eine daraus.

Das Modell ist die falsche Schicht, um seine eigenen Regeln durchzusetzen

Ein Sprachmodell erzeugt die wahrscheinlichste Fortsetzung von allem, was in seinem Kontext steht. Die Regeln gehören zu diesem Kontext, und ebenso jede Webseite, die der Agent liest, jedes Tool-Ergebnis, das er verarbeitet, und jedes Ticket, das ein Kunde geschrieben hat. Enthält eines davon eine Anweisung, die dem Systemprompt widerspricht, wägt das Modell beide ab. Manchmal gewinnt die eingeschleuste. Das ist kein Fehler, den ein neueres Modell behebt; es ist, was ein Modell ist.

Die Frage ist also nicht, wie die Regel formuliert wird. Sie lautet, wo die Regel läuft. Läuft sie in dem Prozess, der nicht vertrauenswürdigen Text liest, lässt sie sich ausreden. Läuft sie außerhalb dieses Prozesses, gibt es niemanden, mit dem man reden könnte.

Durchsetzung außerhalb des Prozesses

Das Muster ist in Betriebssystemen alt und bei Agenten neu: Was die Richtlinie durchsetzt, ist nicht das, was überwacht wird. Sam Witteveens Durchgang durch NVIDIA OpenShell zeigt es sauber. Ein Supervisor startet vor dem Agenten, bereitet die Sandbox vor, lädt die Richtlinie und startet den Agenten dann als eingeschränkten Kindprozess. Öffnet der Agent eine Verbindung, schreibt eine Datei oder ruft ein Modell auf, prüft der Supervisor die Anfrage gegen die Richtlinie, bevor sie irgendetwas Echtes erreicht.

Die Folge ist die, auf die es im Review ankommt: Ist der Agent vollständig kompromittiert, durch einen Jailbreak oder eine präparierte Seite, gilt die Richtlinie weiter, weil sie nie in dem steckte, was kompromittiert wurde.

Meinen eigenen Coding-Agenten betreibe ich so. Er startet in einer OpenShell-Sandbox (Artikel auf Englisch), arbeitet auf einer Arbeitskopie des Repositorys, und seine Ergebnisse erreichen das echte Projekt nur über ein separates Gate. Keine dieser Grenzen ist ein Satz im Prompt.

Was der Durchsetzer besitzen muss

Ein Agent berührt die Welt durch vier Türen. Eine Richtlinie, die eine davon dem Prompt überlässt, lässt sie offen.

Netzwerk, standardmäßig gesperrt. Nichts verlässt die Sandbox, außer das Ziel steht auf einer Allowlist: die Such-API, der Modell-Endpunkt, das eine System, in dem der Agent arbeitet. Alles andere wird außerhalb der Reichweite des Agenten blockiert, er kann sich also nicht zu einer neuen Domain durchargumentieren.

Dateien, ohne Host-Mounts. Der Agent liest und schreibt in einem eigenen Arbeitsbereich. Home-Verzeichnisse, SSH-Schlüssel und Umgebungsdateien sind nicht eingehängt, also findet eine ganze Klasse von Zugangsdaten-Diebstahl nichts zu stehlen. In OpenShell ist der Dateisystem-Teil der Richtlinie beim Start der Sandbox festgelegt; ihn zu ändern heißt, die Sandbox neu anzulegen, und das ist gewollt.

Modellaufrufe über einen lokalen Endpunkt. Der Agent spricht mit einer verwalteten Adresse innerhalb der Sandbox, und der Supervisor entscheidet, wohin jeder Aufruf tatsächlich geht. Der Schlüssel des Anbieters ist für den Agenten nie sichtbar, und der Wechsel zwischen lokalem und gehostetem Modell ist eine Routing-Änderung, keine Code-Änderung.

Zugangsdaten zur Laufzeit eingespielt, nie auf der Platte. Schlüssel kommen bei der Bereitstellung der Sandbox an, laufen nur über die Pfade, die die Richtlinie nennt, und hinterlassen nichts. Wer den Agenten kompromittiert, bekommt einen laufenden Prozess, keinen Ordner voller Schlüssel.

Die Antwort, die Ihr Security-Review lesen kann

Die Richtlinie ist eine Datei in einem Repository. Sie geht durch einen Pull Request, hat einen Diff und eine prüfende Person, und wer wissen will, was der Agent erreichen kann, liest sie. Fragt Compliance, ob der Agent Daten nach außen senden kann, ist die Antwort keine Demo und kein Versprechen über das Modell. Sie ist der Netzwerk-Abschnitt dieser Datei, mit Sperre als Standard und einer kurzen Liste benannter Ziele.

Deshalb können auch Harness und Modell wechseln, ohne dass ein neues Review nötig wird. OpenShell betreibt dieselbe Laufzeitumgebung unter verschiedenen Agenten-Schleifen und verschiedenen Modellen; die Richtlinie kümmert sich nicht darum, was oben läuft, weil sie den Agenten nie um etwas gebeten hat.

Wo diese Grenze endet

Eine Sandbox entscheidet, was der Agent erreichen kann. Sie entscheidet nicht, ob ein Schreibzugriff, den der Agent machen durfte, auch landen soll. Ein Agent mit erlaubter Verbindung zu Ihrem CRM kann trotzdem den falschen Kunden aktualisieren, und ein Agent, der E-Mails senden darf, kann trotzdem die falsche senden. Das sind die nächsten Grenzen, und sie liegen am selben Ort, außerhalb des Modells: der Tap einer Person vor jedem Schreibzugriff, der das Haus verlässt, eine Trennung nach Umkehrbarkeit mit dem vorherigen Wert an jedem Datensatz, und eine Zuordnung, die der Agent nicht auf Verdacht treffen kann.

Der Test für jede Regel, der Ihre Agenten heute folgen, ist dieselbe eine Frage: Wenn das Modell beschlösse, sie zu ignorieren, was würde es aufhalten? Wo die Antwort lautet „nichts, sie steht im Prompt", ist diese Regel das Erste, was umziehen muss. Der Selbstcheck geht die zwölf Stellen durch, an denen Sie nachsehen sollten.