Zum Hauptinhalt springen
Wenn ein Agent ein Tool aufruft, sind die Argumente, die er übergibt, so riskant wie der Prompt, der sie erzeugt hat — ein sk-…-Key, der in ein command-Feld geraten ist, eine Kunden-SSN, die in einen body eingefügt wurde, ein interner Token in einem Request-Header. Das Firewall-sanitize-Verdikt fängt dieses Material in den Tool-Call-Argumenten ab, ersetzt es durch ein typisiertes Redaktions-Token und leitet den bereinigten Aufruf weiter — sodass die Aktion noch läuft, das Secret aber das Gateway nie verlässt.
„Tool-Output bereinigen” meint die Aufruf-Argumente, nicht das Tool-Ergebnis. Leute suchen nach sanitize tool output und erwarten, dass die Firewall das bereinigt, was ein Tool zurückgibt. Das sanitize-Verdikt rührt Tool-Ergebnisse nicht an — es redigiert die Argumente, die Ihr Agent in einen Tool-Call hineinsendet. Wenn Sie den Text screenen müssen, den ein Tool oder Modell zurückgibt, ist das eine Aufgabe der Guardrails-Output-Stage, keine Firewall-sanitize-Regel.
Dies ist ein Verdikt in der Matching-Sprache der Firewall. Für die vollständige Menge siehe Verdikte und die Regel-Referenz; diese Seite ist der fokussierte Leitfaden zum Verfassen und Durchdenken von sanitize.

​
1. Was sanitize tut — und was es nie anrührt

Eine Regel mit verdict: sanitize lässt eine Redaktions-Engine über die Tool-Call-Argumente laufen, bevor der Aufruf dispatcht wird. Jeder Treffer wird durch ein kanonisches Token ersetzt, und der Aufruf läuft mit den bereinigten Argumenten weiter — das Tool führt noch aus, nur ohne das rohe Secret darin.

Redigiert

Die JSON-Argumente eines vom Modell ausgegebenen tool_call oder eines MCP-tools/call — command, body, headers, jedes String-Feld, in dem ein Secret oder PII gelandet ist.

Redigiert nie

Den Inhalt, den ein Tool zurückgibt, den Prompt, den Antworttext des Modells. Sanitize ist ein reiner Argument-Redactor. Text-Screening ist eine Guardrail-Angelegenheit.
Der Redactor ersetzt jeden Treffer durch ein typisiertes Token: Ein Preset-Treffer wird zu [redacted:<preset>] (z. B. [redacted:openai_key]), und ein Custom-Pattern-Treffer wird zu [redacted:custom]. Die Form des Arguments bleibt erhalten — nur der sensible Teilstring ändert sich — sodass ein Tool, das valides JSON erwartet, weiterhin valides JSON empfängt.

​
2. Die eingebauten Detektor-Presets

Eine sanitize-Regel benennt ein oder mehrere Presets (bekannte Secret-/PII-Formen) und/oder custom-Regex-Muster. Die eingebauten Presets:
PresetFängt ab
aws_access_keyAWS-Access-Key-ID (AKIA… / ASIA… + 16 Zeichen)
aws_secret_keyEin 40-Zeichen-AWS-Secret (grenzbewusst)
openai_keysk- + ≥32 Zeichen
anthropic_keysk-ant- + ≥40 Zeichen
bearer_tokenBearer + ein ≥16-Zeichen-Token (Keyword beibehalten)
emailEine E-Mail-Adresse
ssn_usEine US-SSN in 3-2-4-Form
credit_cardEine 13–19-stellige Ziffernfolge, die eine Luhn-Prüfung besteht
Eine sanitize-Regel muss mindestens ein Preset oder Custom-Muster deklarieren — ein leerer Sanitizer wird abgelehnt, wenn Sie die Regel speichern. Ein credit_card-Treffer wird zusätzlich Luhn-geprüft, sodass eine gleich lange Zahl, die keine valide Karte ist, unberührt bleibt, statt über-redigiert zu werden.

​
3. Ein konkretes Beispiel

Verfassen Sie dies im Regel-Editor der Konsole. Das Beispiel redigiert einen OpenAI-Key und jede E-Mail aus den Argumenten jedes http.*-Tool-Calls, den Ihr Agent ausgibt, und leitet dann den bereinigten Aufruf weiter: 
{
  "label": "strip secrets from http tool args",
  "stage": "response",
  "tool_name_glob": "http.*",
  "verdict": "sanitize",
  "sanitize_json": "{\"presets\":[\"openai_key\",\"email\"],\"custom\":[]}"
}
Wenn das Modell einen Aufruf wie diesen ausgibt: 
{ "name": "http.post", "arguments": { "url": "…", "body": "key=sk-AAAA…BBBB user=jo@acme.com" } }
leitet das Gateway ihn weiter, mit dem Body umgeschrieben zu key=[redacted:openai_key] user=[redacted:email] — der Request läuft noch, das Secret und die Adresse verlassen das Gateway nie.
Pinnen Sie die Regel auf die response-Stage (vom Modell ausgegebene tool_calls) oder lassen Sie die Stage leer, um auch die mcp-Surface abzudecken. Das sind die Surfaces, die Argumente zur Aufrufzeit tragen — genau das, was sanitize redigiert.

​
4. Auf der inbound-Surface eskaliert sanitize zu deny

Die inbound-Surface wertet die Tools aus, die ein Agent auf einem Request anbietet — Tool-Definitionen, die noch keine Argumente zur Aufrufzeit tragen. Dort gibt es nichts zu redigieren, sodass ein sanitize-Verdikt auf der inbound-Surface zu einem deny eskaliert (fail-closed): Der Request wird mit firewall_blocked blockiert, statt unredigiert weitergeleitet zu werden.
Verfassen Sie keine sanitize-Regel in der Erwartung, dass sie eine inbound-Tool-Werbung bereinigt — sie wird sie blockieren. Wenn Sie wollen, dass eine Tool-Definition aus dem Request verschwindet, verwenden Sie ein explizites deny. Reservieren Sie sanitize für die response- und mcp-Surfaces, wo echte Argumente existieren.

​
5. Sanitize vs. die anderen Wege, ein Secret zu behandeln

Drei Ebenen können auf ein Secret reagieren, das ein Agent gleich leaken will — wählen Sie nach was und wo:
Streicht das Secret aus den Argumenten eines Tool-Calls heraus und führt den Aufruf trotzdem aus. Verwenden Sie es, wenn die Aktion legitim ist, der Agent aber etwas Sensibles in ein Feld gesetzt hat. Nur auf der Argument-Ebene.
Stoppt den Aufruf vollständig. Verwenden Sie es, wenn die Aktion selbst gefährlich ist, nicht nur ein Argument. Das ist auch das, wozu sanitize auf der inbound-Surface wird. Siehe Tools blockieren.
Die Secrets-Blocker- und PII-Guardrails screenen den Text eines Requests oder einer Antwort (einschließlich, auf der Output-Stage, modellgenerierter Inhalte). Das ist die Ebene für „was ein Tool oder Modell zurückgibt” — genau das, was sanitize nicht tut.
Testen, bevor Sie durchsetzen. Sanitize schreibt die Argumente eines Live-Aufrufs auf den response- und mcp-Surfaces um. Verfassen Sie Ihre sanitize-Regeln zuerst unter dem Shadow-Mode und beobachten Sie den Events-Feed, um zu bestätigen, dass sie matchen, was Sie erwarten, bevor irgendein Argument tatsächlich umgeschrieben wird.

​
6. Wo sanitize in Ihrer Spur auftaucht

Wie jedes Verdikt wird eine sanitize-Auswertung als Firewall-Event aufgezeichnet — filterbar nach Verdikt, Surface, Tool und Run im Events-Log und aufgerollt in Analytics. Im Shadow-Mode wird ein sanitize-Verdikt (wie jedes durchsetzende Verdikt) auf audit herabgestuft, und dem Grund wird [shadow] would … vorangestellt, sodass Sie die Wirkung messen können, bevor irgendein Argument tatsächlich umgeschrieben wird.

​
Wohin als Nächstes

Alle Verdikte

allow, audit, deny, sanitize, pending_approval, cap_cost.

Argumente validieren

Einen Aufruf danach matchen, was in seinen Argumenten steht — die JSONPath-Klausel-Grammatik.

Tools blockieren

Wenn die Aktion selbst das Problem ist, den ganzen Aufruf verweigern.

Firewall + Guardrails

Den Text screenen, den ein Tool oder Modell zurückgibt — die Ebene, die sanitize nicht abdeckt.
Für die Bedrohungen, die sanitize einzudämmen hilft, siehe Datenexfiltration und Gefährliche Tool-Calls. Für die vollständige Regel-Grammatik hinter dem Verdikt siehe die Firewall-Regel-Referenz.