Zum Hauptinhalt springen
Wenn Sie ein Firewall-Event oder einen Guardrail-Match lesen, sagt Ihnen die Zeile, was das Gateway entschieden hat — deny, sanitize, [EMAIL]. Diese Seite ist die Nachschlagetabelle für diese Wörter: was jedes bedeutet, was es mit dem Aufruf macht und wohin Sie für die vollständige Mechanik gehen. Halten Sie sie offen, während Sie Regeln verfassen oder den Events-Feed triagieren. Zwei Control-Planes erzeugen zwei Vokabulare. Die Firewall steuert Tool-Aktionen und erzeugt ein Verdikt. Guardrails screenen Prompt- und Antwort-Text und erzeugen eine Aktion plus, bei einer Maske, einen typisierten Masking-Tag. Sie teilen sich nie ein Wort — ein Guardrail sagt nie deny, eine Firewall sagt nie mask.
Dies ist ein Referenzindex, kein How-to. Für den Anwendungsfall hinter jeder Kontrolle siehe Guardrails vs. Firewall; für die HTTP-Bodys siehe Sicherheits-Fehlercodes.

​
1. Das Firewall-Verdikt-Glossar

Eine Firewall-Regel (oder das default_verdict der Policy) löst jeden Tool-Call zu genau einem dieser sechs Verdikte auf. Die Engine durchläuft die Regeln in Prioritätsreihenfolge, erster Treffer gewinnt, und fällt auf den Default zurück, wenn nichts matcht.
Der Aufruf fährt zum Tool fort. Trotzdem als Firewall-Event geloggt, sodass er in Runs und im Events-Feed auftaucht. Das ist, was Sie für Tools wollen, denen ein Agent ausdrücklich vertraut wird.
Identischer Traffic wie allow, aber als etwas geflaggt, das Sie beobachten wollten. Es ist das empfohlene default_verdict: alles beobachten, nichts blockieren, bis Ihre Regeln getunt sind. Die balanced-Autonomie-Stufe liefert das PII-Shield-Guardrail als flag-only (audit), sodass PII aufgezeichnet wird, ohne den Aufruf zurückzuhalten.
Der Aufruf erreicht das Tool nie. Auf der inbound-Surface gibt dies HTTP 400 firewall_blocked zurück; durch das MCP-Gateway kommt es als Tool-Fehler (firewall deny: <reason>) zurück, sodass das Modell reagieren kann, statt abzustürzen. Als skip-retry markiert. Kostet keine Modell-Tokens.
Ersetzt gematchte Teilstrings (Secrets, PII) in den Tool-Call-Argumenten durch ein [redacted:<preset>]-Token und leitet dann den Aufruf mit den bereinigten Argumenten weiter. Es redigiert nur Argumente — nie den Inhalt, den ein Tool zurückgibt. Auf der inbound-Surface, wo es noch keine Aufruf-Argumente gibt, eskaliert sanitize zu einem deny.
Der Aufruf wird zur Überprüfung eingereiht und der Agent erhält eine held-Antwort, die eine Approval-ID trägt (HTTP 400 firewall_approval_pending). Ein Prüfer löst sie in der Konsole oder über einen HMAC-Webhook-Callback auf; der Agent pollt die ID und reicht einmal mit einem einmal nutzbaren Approval-Header erneut ein. Siehe Menschliche Freigabe.
Verfasst als Regel mit einer Pro-Regel-Cent-Obergrenze. Es löst sich zu allow auf, während der Agentenlauf im Budget ist, und zu deny, sobald die kumulierten Ausgaben die Obergrenze überschreiten — sodass ein Event allow oder deny zeigt, nicht das wörtliche cap_cost. Ein Schutzschalter für außer Kontrolle geratene Schleifen.
Im Shadow-Mode werden deny / sanitize / pending_approval allesamt auf audit herabgestuft und dem Grund wird [shadow] would … vorangestellt. Das Event zeichnet das Verdikt auf, das gefeuert hätte, aber der Traffic ist unverändert — das ist der ganze Sinn eines sicheren Ausrollens.

​
Default-Verdikt

default_verdict akzeptiert nur die drei nicht-interaktiven Verdikte:
WertBedeutung, wenn keine Regel matcht
allowNicht abgedeckte Tool-Calls stillschweigend erlauben.
auditErlauben, aber aufzeichnen — der Default.
denyAlles blockieren, was keine Regel ausdrücklich erlaubt (Default-Deny-Haltung).
Die tight-Autonomie-Stufe setzt default_verdict: deny; balanced und der ausgelieferte Default verwenden audit.

​
2. Guardrail-Aktionen

Eine Guardrail-Regel feuert eine von fünf Aktionen. Sie sind das Text-Plane- Äquivalent zu Verdikten — und eine Guardrail-Regel erzeugt nie ein Firewall-Verdikt.
AktionWas sie tutKontingent
blockDen gesamten Request mit HTTP 400 guardrail_blocked ablehnen.Keine — Input-Blocks feuern vor der Messung; Output-Blocks erstatten.
maskJeden Treffer zu einem typisierten Tag redigieren (siehe §3) und den bereinigten Text weiterleiten.Normal — der Aufruf läuft weiter.
flagNur loggen. Zeichnet einen Treffer auf; ändert nichts am Traffic.Normal.
annotateNicht blockierend. Hängt eine menschenlesbare Notiz an den Request an (upstream als Sicherheitshinweis injiziert), ohne den Text zu maskieren oder zu blockieren.Normal.
spotlightNicht blockierend. Schließt den gematchten (nicht vertrauenswürdigen) Text in Delimiter ein und sagt dem Modell, die abgegrenzte Region als Daten, nie als Anweisungen zu behandeln — die Prompt-Injection-„Spotlighting”-Verteidigung.Normal.
Ein blockierter Guardrail-Request ist als skip-retry markiert — denselben Prompt gegen einen anderen Channel erneut auszuführen würde einfach wieder blockieren.
Verwenden Sie flag, um eine neue Regel gegen echten Traffic zu messen, bevor Sie sie auf block oder mask umschalten. Der Matches-Feed zeigt, was gefangen worden wäre, mit null Traffic-Auswirkung — das Guardrail-Pendant zum Firewall-Shadow-Mode.
Eine einzelne pii-Regel kann verschiedene Aktionen auf verschiedene Entitäten mit entity_actions anwenden — E-Mails und Telefonnummern maskieren, aber auf credit_card und ssn blockieren, aus einer Regel. Keys müssen eine auf der Regel aktivierte Entität sein; Werte müssen block / mask / flag / annotate sein.

​
3. Das Masking-Tag-Glossar

Bei einer mask-Aktion wird jede gematchte Entität inline durch einen typisierten Tag ersetzt — [<GROSSBUCHSTABEN_ENTITÄTSNAME>] — sodass das Modell (Input-Stage) oder der Aufrufer (Output-Stage) die Form der Daten ohne den Wert sieht. Masking läuft auf beiden Stages, einschließlich gestreamter Antworten: Ein token-bewusster Stream-Scanner maskiert Treffer, die Chunk-Grenzen überspannen, bevor sie den Client erreichen.
EntitätTag
email[EMAIL]
phone[PHONE]
credit_card[CREDIT_CARD]
ssn[SSN]
ip[IP]
iban[IBAN]
mac_address[MAC_ADDRESS]
jwt[JWT]
aws_access_key[AWS_ACCESS_KEY]
api_key_openai[API_KEY_OPENAI]
bitcoin_address[BITCOIN_ADDRESS]
Drei regionale Identifikatoren werden zusätzlich zum Basis-Set ausgeliefert:
EntitätTagRegion
jp_mynumber[JP_MYNUMBER]Japan
kr_rrn[KR_RRN]Südkorea
cn_resident_id[CN_RESIDENT_ID]China
Eigene Entitäten folgen derselben Konvention. Eine eigene Entität namens employee_id maskiert zu [EMPLOYEE_ID], sofern Sie keinen expliziten mask_with-Ersatz setzen. Bis zu 25 eigene Entitäten pro Regel, jede ein RE2-Regex mit einer optionalen luhn-Prüfsumme. Siehe PII-Erkennung.

​
4. Ein durchgearbeitetes Beispiel

Ein einzelner db.query-Tool-Call, von oben nach unten gelesen, berührt beide Vokabulare: 
firewall verdict : sanitize        # secret stripped from the SQL argument
guardrail action : mask            # an email in the prompt redacted
masking tag      : [EMAIL]         # what the model actually receives
Das Firewall-sanitize bereinigte die Tool-Argumente; das Guardrail-mask bereinigte den Prompt-Text; der [EMAIL]-Tag ist, was das Modell anstelle der Adresse sieht. Derselbe Request, drei verschiedene Ebenen, drei Wörter aus diesem Glossar.

​
5. Haltungs-Wörter, die Sie neben Verdikten sehen

Diese sind keine Verdikte oder Aktionen, aber sie entscheiden, ob ein Verdikt überhaupt durchgesetzt wird — sodass sie in denselben Events- und Einstellungsansichten auftauchen.
WortPlaneBedeutung
Shadow-ModeFirewallPro-Policy-Flag. Stuft jedes durchsetzende Verdikt auf audit herab, stellt dem Grund [shadow] would … voran.
Observe-ModeFirewallWorkspace-Einstellung. Wenn keine Policy aufgelöst wird, erlaubt den Aufruf, loggt ihn aber als Abdeckungslücke (Discovered tools).
EnforceFirewallShadow aus + eine Policy angehängt: Verdikte treten in Kraft.
Fail-openGuardrailsDefault für fortgeschrittene Regeln (llm_judge, grounding, external) — ein Timeout wird beobachtet, der Request läuft weiter. Schalten Sie pro Regel auf fail-closed.
Log raw contentGuardrailsStandardmäßig aus. Wenn aus, zeichnet ein Match auf, dass eine Regel gefeuert hat, aber nicht den gematchten Teilstring.
Für die Deny-vs-audit-vs-shadow-Unterscheidung in der Tiefe siehe Enforcement-Modes.

​
6. Wo jedes Wort definiert ist

SurfaceVokabularHome-Seite
Firewall-Policyallow audit deny sanitize pending_approval cap_costFirewall
Firewall-Regel-Matchingtool_name_glob, args_match, egress, sequenceFirewall-Regeln
Guardrail-Regelblock mask flag annotate spotlightGuardrails
Guardrail-PIIEntitätsnamen + Masking-TagsGuardrails
MCP & SkillsSkill-Risikobänder, quarantine / block ModiFirewall-MCP, Firewall-Skills
HTTP-Fehler-Bodysguardrail_blocked, firewall_blocked, firewall_approval_pendingFehlercodes
Jeder Begriff hier erscheint auch im breiteren Konzept-Glossar, das Identitäts-, Scope- und Bedrohungsbegriffe hinzufügt. Diese Seite ist die schmale, entscheidungsfokussierte Scheibe — nur Verdikte, Aktionen und Masking-Tags.

​
7. Verwandte Lektüre

Warum wurde das blockiert?

Verfolgen Sie einen einzelnen abgelehnten Aufruf zurück zu der exakten Regel und dem Verdikt, das ihn gestoppt hat.

Enforcement-Modes

Wie audit, shadow, observe und enforce zusammenhängen — und wie man sicher ausrollt.

Guardrails vs. Firewall

Welche Plane welche Entscheidung besitzt und warum ein Request durch beide laufen kann.

Gefährliche Tool-Calls

Die Bedrohung, gegen die die Verdikte deny und sanitize existieren.