Zum Hauptinhalt springen
Sicherheitsprüfungen sind nur dann relevant, wenn sie tatsächlich laufen — aber Sie sollten Durchsatz nicht gegen Sicherheit tauschen müssen. Diese Seite beantwortet die Frage, die Entwickler am häufigsten stellen: Wird die Durchsetzung meinen Agenten verlangsamen, und um wie viel? Die kurze Antwort: Eingebaute Regeln kosten nichts Messbares. Erweiterte Regeln kosten höchstens einen begrenzten, parallelen, Fail-open-Modell-Aufruf. Hier ist der Grund und wie man es kontrolliert.

​
1. Zwei Klassen von Prüfungen

Jede Guardrail-Regel und jede Firewall-Auswertung fällt in eine von zwei Klassen.

​
Eingebaute / deterministische Prüfungen

Keyword-Denylist (keyword), Regular Expression (regex), PII-Erkennung (pii) und Max-Länge (max_chars) Guardrail-Regeln sind reine lokale String- und Regex-Operationen — kein Modell-Aufruf, kein Netzwerk-Hop, nichts, das ein Timeout haben kann. Firewall-Regelauswertung (Tool-Name-Glob- Matching, Argument-Prädikate, Egress-Scope) ist dasselbe: deterministisch und lokal. Für praktische Zwecke fügen diese Prüfungen vernachlässigbare Latenz zu Ihrem Request hinzu. Sie sind sicher auf dem Hot-Path ausführbar und bilden die Grundlage der eingebauten Guardrail-Templates.

​
Erweiterte / semantische Prüfungen

llm_judge-, grounding- und external-Anbieter-Regeln delegieren die Prüfung an ein Modell oder einen Anbieter. Sie kosten einen Round-Trip. Drei Eigenschaften begrenzen diese Kosten:
  1. Paralleler Dispatch. Wenn Ihre Policy mehrere erweiterte Regeln hat, werden sie parallel dispatcht — eine langsame Prüfung wird nie hinter einer anderen serialisiert.
  2. Timeout pro Regel. Jede erweiterte Regel hat einen Timeout (judge_timeout_ms / grounding_timeout_ms / timeout_ms). Die Grounding-Prüfung hat einen Standard von ~3 000 ms; der Judge verwendet einen konfigurierbaren Wert (0 → Engine-Standard). Die Regel ist begrenzt — sie kann nicht unbegrenzt hängen.
  3. Fail-open standardmäßig. Wenn eine Regel ein Timeout hat oder ihr Anbieter einen Fehler zurückgibt, wird das Ereignis aufgezeichnet, aber der Request fährt fort. Setzen Sie judge_fail_open: false (Judge) oder fail_open: false (external), um stattdessen auf Fail-closed umzuschalten.
Der Worst-Case für eine beliebige Anzahl erweiterter Regeln ist also der längste einzelne Timeout, nicht die Summe aller Timeouts.

​
2. Auf einen Blick

PrüfungstypFügt Latenz hinzu?Wie es begrenzt wird
keyword-DenylistVernachlässigbar — lokaler String-ScanKein Netzwerk; kein Timeout nötig
regexVernachlässigbar — lokaler RE2-MatchKein Netzwerk; kein Timeout nötig
pii-ErkennungVernachlässigbar — lokaler Regex/Entity-ScanKein Netzwerk; kein Timeout nötig
max_charsVernachlässigbar — ZeichenzählungKein Netzwerk; kein Timeout nötig
Firewall-RegelauswertungVernachlässigbar — Glob + Prädikat-MatchingKein Netzwerk; kein Timeout nötig
llm_judgeEin begrenzter Modell-Aufrufjudge_timeout_ms; Fail-open standardmäßig
groundingEin begrenzter Modell-Aufrufgrounding_timeout_ms (Standard ~3 000 ms); Fail-open standardmäßig
external-AnbieterEin begrenzter Anbieter-Aufruftimeout_ms; fail_open standardmäßig
Mehrere erweiterte RegelnEin begrenzter Round-Trip (paralleler Dispatch)Worst-Case = max. einzelner Timeout, nicht Summe

​
3. Wo im Request-Lebenszyklus Prüfungen laufen

Die Durchsetzung passiert nicht überall zum selben Zeitpunkt. Input- und Output-Prüfung fügen Zeit an verschiedenen Stellen hinzu: 
Client
  │
  ▼
[Input-Guardrail-Prüfung]     ← fügt Zeit HIER hinzu, vor Upstream
  │
  ▼
Upstream-Modell-Aufruf
  │
  ▼
[Output-Guardrail-Prüfung]    ← fügt Zeit HIER hinzu, nach Modell-Antwort
  │
  ▼
Client
Input-Guardrails laufen vor dem Upstream-Modell-Aufruf. Eine eingebaute Input-Regel fügt vernachlässigbaren Overhead davor hinzu. Eine erweiterte Input-Regel (z. B. ein llm_judge, der auf Prompt-Injection prüft) fügt einen begrenzten Modell-Aufruf vor dem Start des Haupt-Modell-Aufrufs hinzu. Output-Guardrails laufen nach der Antwort des Modells. Eine eingebaute Output-Regel fügt vernachlässigbaren Overhead am Ende hinzu. Eine erweiterte Output-Regel (z. B. grounding, das RAG-Treue prüft) fügt einen begrenzten Aufruf nachdem Sie die Antwort des Modells bereits haben hinzu. Firewall-Regelauswertung ist deterministisch und passiert inline beim Tool-Call-Routing — vernachlässigbar, wie oben angemerkt.
Ein blockierter Request kostet keine Modell-Tokens und fügt keine Upstream-Latenz für Input-Stage-Blocks hinzu. Ein Input-Block feuert vor der Messung und vor dem Upstream-Aufruf — Sie zahlen weder Kontingent noch Upstream-Round-Trip-Zeit. Ein Output-Stage-Block erstattet das vorab verbrauchte Kontingent zurück, nachdem die Antwort abgelehnt wurde.

​
4. Wie Timeouts und Fail-open den Worst-Case begrenzen

Erweiterte Regeln haben zwei Einstellmöglichkeiten: Timeout — die maximale Wall-Time, die die Prüfung haben darf. Der Request wartet höchstens so lange auf diese Regel. Paralleler Dispatch bedeutet, dass dieses Limit pro Regel gilt, nicht pro Policy. Wenn Sie drei llm_judge-Regeln mit jeweils 2 000 ms Timeout haben, laufen alle drei gleichzeitig und die Gesamtwartezeit beträgt ~2 000 ms, nicht ~6 000 ms. Fail-open vs. Fail-closed — was zu tun ist, wenn die Regel nicht rechtzeitig abgeschlossen wird (oder der Anbieter fehler):
EinstellungVerhalten bei Timeout / Fehler
fail_open: true (Standard)Ereignis aufzeichnen; Request so weiterlaufen lassen, als ob die Prüfung bestanden hätte
fail_open: falseTimeout / Fehler als Block behandeln; HTTP 400 guardrail_blocked zurückgeben
Fail-open erhält Verfügbarkeit auf Kosten einer verpassten Prüfung. Fail-closed erhält die Policy-Garantie auf Kosten der Verfügbarkeit, wenn der Judge langsam oder nicht erreichbar ist. Wählen Sie basierend darauf, was für Ihren Anwendungsfall wichtiger ist.

​
5. Praktische Empfehlungen

Hot-Path-Regeln eingebaut halten. Wenn Ihr Hauptanliegen PII, Credential-Leakage, Prompt-Länge oder Keyword-Denylist ist — all das sind eingebaute Regeln. Sie fügen keine messbare Latenz hinzu und sollten Ihre Standardwahl für jede Prüfung sein, die Text-Matching bewältigen kann. llm_judge und grounding verwenden, wo Sie Semantik brauchen. Toxizität, Belästigung, Off-Topic-Erkennung, Prompt-Injection-Absicht und RAG-Treue sind genuinely vage — kein Regex erfasst sie zuverlässig. Das sind die richtigen Fälle für eine erweiterte Regel. Akzeptieren Sie, dass jede einen begrenzten zusätzlichen Modell-Aufruf hinzufügt. Timeouts auf Ihr Latenzbudget abstimmen. Wenn Ihr End-to-End-Ziel 1 000 ms ist, setzen Sie judge_timeout_ms: 800 (oder weniger), damit der Judge nicht Ihr gesamtes Budget aufbrauchen kann. Der Standard-Timeout der Engine ist ein sicherer Ausgangspunkt; reduzieren Sie ihn bei strengen Anforderungen. Für Output-Grounding ist der Modell-Aufruf bereits erledigt. Die grounding-Prüfung läuft nachdem das Upstream-Modell geantwortet hat — die zusätzliche Latenz liegt nur am Ende, nicht auf dem kritischen Pfad für Time-to-First-Token. Das macht sie zu einem risikoarmen Ort für semantische Durchsetzung. Mehrere erweiterte Regeln? Die Arbeit verteilen. Da erweiterte Regeln parallel laufen, kostet das Stapeln von drei llm_judge-Regeln ungefähr dasselbe wie eine — der längste individuelle Timeout bestimmt die Wall-Time, nicht die Anzahl. Nutzen Sie das, um semantische Prüfungen zu schichten, ohne additive Kosten.

Enforcement-Modi

Fail-open vs. Fail-closed — die vollständige Referenz zum Abstimmen des Verhaltens Ihrer Policy unter Timeout- und Fehlerbedingungen.

Guardrails

Regeltypen, Judge-Felder, Grounding-Schwellenwerte und die vollständige Guardrail-Konfigurationsreferenz.
Eingebaute Regeln sind auf jedem Pfad vernachlässigbar; erweiterte Regeln kosten einen begrenzten, parallelen, Fail-open-Aufruf — stimmen Sie den Timeout und den Fail-Mode ab, und die Durchsetzung fügt Ihren Agenten keine unkontrollierte Latenz hinzu.