Modelle schlagen vor. Code entscheidet.

Zwei verschiedene Aufgaben#

Ein Sprachmodell kann aus unvollständigem Kontext plausible Vorschläge ableiten. Es kann Absichten erkennen, mögliche Schritte ordnen und eine passende Werkzeugnutzung formulieren. Genau diese Flexibilität macht Modelle nützlich. Sie ist aber kein Ersatz für eine kontrollierte Ausführung.

Probabilistische Modellausgabe und deterministische Ausführung haben unterschiedliche Aufgaben. Das Modell darf vorschlagen, was passieren könnte. Kontrollierter Code entscheidet, was tatsächlich passieren darf. Werden beide Ebenen vermischt, wird aus einer sprachlichen Einschätzung unmittelbar ein privilegierter Seiteneffekt.

Die Trennung ist keine Aussage gegen Modelle. Sie ist die Bedingung dafür, ihre Stärken dort zu nutzen, wo Unsicherheit erlaubt ist, ohne dieselbe Unsicherheit in Berechtigungen und Systemzustände zu übertragen.

Die Vertrauensgrenze liegt vor dem Seiteneffekt#

Ein Vorschlag kann falsch, mehrdeutig oder unvollständig sein. Deshalb sollte die Vertrauensgrenze nicht erst hinter dem Werkzeug liegen. Sie muss dort liegen, wo aus Text eine konkrete Aktion wird.

Deterministischer Code kann prüfen, welches Werkzeug angesprochen wird, welche Berechtigung für die Aktion nötig ist und ob der angeforderte Seiteneffekt innerhalb der erlaubten Aufgabe liegt. Das Modell liefert dabei Kontext und Vorschläge. Es hält aber nicht selbst die Entscheidungshoheit über privilegierte Aktionen.

Diese Grenze macht auch Fehler klarer. Ein Modellfehler bleibt zunächst ein fehlerhafter Vorschlag. Erst eine explizite, kontrollierte Entscheidung kann daraus eine Änderung an einem externen System machen.

Tokens gehören nicht in das Modell#

Tokens sind Fähigkeiten in kompakter Form. Wer sie besitzt, kann die damit freigegebenen Aktionen ausführen. Sie gehören deshalb in kontrollierten Code und nicht in den Kontext eines Sprachmodells.

Das Modell muss nicht den geheimen Wert kennen, um eine fachlich sinnvolle Aktion vorzuschlagen. Der ausführende Code kann das passende Credential halten, die Berechtigung prüfen und die Aktion in einem begrenzten Pfad ausführen. Damit bleibt der Token außerhalb der probabilistischen Verarbeitung und außerhalb frei formulierbarer Ausgaben.

Dasselbe gilt für privilegierte Aktionen selbst. Ein Modell kann beschreiben, dass eine Änderung nötig sein könnte. Ob sie erlaubt ist, hängt von Regeln ab, die nicht durch die Formulierung des Modells verändert werden dürfen.

Least Privilege als fachliche Entscheidung#

Nicht jede Agent-Umgebung braucht dieselben Fähigkeiten. Schreibzugriff sollte nur dort vergeben werden, wo die Aufgabe ihn tatsächlich benötigt. Lesender Zugriff bleibt standardmäßig lesend. Eine Fähigkeit wird nicht vorsorglich freigeschaltet, nur weil sie später nützlich sein könnte.

Least Privilege ist dabei mehr als eine technische Liste von Rechten. Die fachliche Aufgabe bestimmt die kleinste sinnvolle Menge an Werkzeugen und Seiteneffekten. Ein Agent für Recherche braucht andere Grenzen als ein Agent, der einen klar definierten Datensatz aktualisieren soll.

Diese Begrenzung sollte auch dann bestehen bleiben, wenn ein Modell eine weitergehende Aktion überzeugend begründet. Sprachliche Plausibilität ist kein Berechtigungsnachweis. Die kontrollierte Schicht muss die erlaubte Aufgabe und die tatsächlich vorhandene Fähigkeit unabhängig davon zusammenführen.

Kontrolle ist Teil der Architektur#

Guardrails, Trust Boundaries und Berechtigungen sind keine nachträglichen Filter für ein ansonsten autonomes Modell. Sie sind Teil der Architektur. Das Modell bleibt innerhalb dieser Architektur ein leistungsfähiger Vorschlagsmechanismus.

Die praktische Leitlinie ist deshalb schlicht: Modelle schlagen vor. Code entscheidet. Je privilegierter der mögliche Seiteneffekt, desto weniger darf seine Freigabe von probabilistischer Ausgabe abhängen.

TODO: Konkrete, veröffentlichbare Beispiele für kontrollierte Ausführung ergänzen, sobald ihre technischen Details freigegeben sind.