Was im Code leben muss

Die Gating-Seite argumentierte, dass Code den Schwellenwert besitzen sollte. Diese Seite geht eine Stufe weiter: manche Prüfungen sollte man dem Modell gar nicht stellen.

Die stärkste Grenzaussage, die öffentlich ist

Die härteste Linie kommt aus einer Agent-Loop-Implementierung:

Ein Tool-Aufruf mit einem hohen Risiko-Score erzwingt menschliche Autorisierung, und keine Wahrscheinlichkeit kann sie überschreiben.

„Keine Wahrscheinlichkeit kann sie überschreiben” verdient es, herausgehoben zu werden. Es wird nicht gesagt „die Konfidenz muss sehr hoch sein” — es wird gesagt, diese Regel liegt nicht im Wahrscheinlichkeitsraum. Die Unterscheidung ist wichtig:

• „Automatisch genehmigen bei ≥ 0.95” ist eine Schwellenwert-Regel — prinzipiell würde eine ausreichend hohe Wahrscheinlichkeit sie passieren.
• „Hohes Risiko erfordert menschliche Genehmigung” ist eine strukturelle Regel — wahr unabhängig davon, was das Modell sagt.

Diese sind nicht gleich verlässlich. Dein System sollte ausdrücklich sagen, welche Prüfungen welche Art sind, und es sollte so viele strukturelle Regeln wie möglich geben.

Führe zuerst deterministische Regeln aus, gib dem Modell nur die Grauzone

Eine andere Formulierung desselben Musters:

Führe zuerst deterministische Regeln aus: Was entschieden werden kann, wird direkt blockiert oder erlaubt, und das Modell ist nur ein optionales Backend. Routine-Befehle werden lokal entschieden und gar nicht erst an das Modell geschickt.

Regeln zuerst auszuführen hat einen unterschätzten Nutzen: es verkleinert die Angriffsfläche. Ein Judge, der rein vom Modell abhängt, verhält sich unter Prompt-Injection unvorhersehbar; ein Judge, der zuerst Regeln ausführt, beschränkt die Injection auf den kleinen Ausschnitt, den die Regeln nicht entscheiden können.

Ein veröffentlichter Injection-Test berichtet 300 Injection-Versuche und sagt unumwunden, was das Gate abgefangen hat und was durchgeschlüpft ist. Das ist weit nützlicher als eine bloße Behauptung von „Injection-Schutz”.

Secrets und sensible Daten: zuerst lokal blockieren

Ein Secret-Detektor legt die Reihenfolge klar dar:

Zwei Entscheidungen zum Merken:

• Maskierung kommt zuerst. Du kannst nicht etwas an einen externen Dienst schicken, um herauszufinden, ob es ein Secret ist. Die Prüfung selbst leakt.
• Ein totes Modell fragt trotzdem einen Menschen, statt zu erlauben. Das ist fail-closed in konkreter Form — die Nichtverfügbarkeit eines Dienstes ist kein Grund, die Sicherheitslatte still zu senken.

Gemessen: 6/6 Secrets blockiert, 0/6 harmlose Eingaben fälschlich blockiert.

Budget-Obergrenzen, signierte Belege, Audit

Manche Prüfungen haben nichts damit zu tun, was das Modell sagt, müssen aber im selben System leben:

• Eine Laufzeitumgebung übergibt Blockierung gefährlicher Befehle und Budget-Obergrenzen an deterministischen Code und zeichnet jedes Urteil in einer Ed25519-signierten Belegkette auf.
• Eine andere beschränkt den Risiko-Score auf eine code-kontrollierte 0–100-Skala und signiert jedes Urteil mit ES256 (540 Aufrufe, 99.76% und 0 Falsch-Positive bei einem Schwellenwert von 65–75).

Der Sinn des Signierens ist nicht der Schutz vor dem Modell — sondern dass du danach sagen kannst, was passiert ist. Wenn eine automatisierte Entscheidung einen Vorfall verursacht, muss „was das Modell gesagt hat und was der Code dagegen getan hat” unabhängig verifizierbar sein statt eine Frage des Vertrauens in die Logs.

Filtere Injection an zwei Stellen

Das Design einer Guard-Layer verdient eine eigene Erwähnung, weil es zwei leicht übersehene Stellen benennt:

Filtere einmal bevor ein Tool-Aufruf ausgeführt wird, und noch einmal bevor ein Tool-Ergebnis vom Agenten gelesen wird.

Die zweite ist die, die Leute vergessen. Filtere nur die Eingabe, und ein Angriff kann sich in dem verstecken, was das Tool zurückgibt — eine abgerufene Seite, der Inhalt einer Datei —, was in den Kontext gelangt, nachdem es die Prüfung auf der Eingabeseite vollständig umgangen hat.

Eine verwandte Regel aus einer retrieval-augmentierten Implementierung: gib niemals eine Zahl aus, die nicht in den zitierten Quellen vorkommt.

Sandboxing und Berechtigungen

Neben dem Filtern von Inhalten ist die andere Schicht die Begrenzung des Wirkungsradius: geschützte Pfade gehen immer über menschliche Bestätigung; die Agent-Ausführung läuft in isolierten Arbeitsbereichen (eine Implementierung nutzt Docker); die Berechtigungen von Sub-Agenten sind von denen des Parents getrennt.

Eine Referenztabelle

Die mittlere Spalte ist der Punkt: je näher an oben, desto weniger sollte das Modell beteiligt sein.

In einem Satz

Eine Prüfung, die von einer Wahrscheinlichkeit überschrieben werden kann, wird irgendwann überschrieben werden. Entscheide zuerst, welche Prüfungen nicht überschrieben werden dürfen; stimme erst dann die Schwellenwerte ab.