Guardrails — Überblick

Guardrails laufen im Gateway-Pfad, bevor Traffic ein Modell erreicht.

Guardrails sind die Art, wie Outgate sensible Werte schützt, während Traffic durch das Gateway läuft.

Wenn ein Provider Guardrails aktiviert hat, inspiziert das Gateway POST-Request-Bodies, bevor sie nach upstream weitergegeben werden. Die Anfrage wird an den regionalen Guardrail-Service geschickt, der nach Werten wie PII und Zugangsdaten sucht und eine Entscheidung an das Gateway zurückgibt.

Das Gateway erlaubt die Anfrage dann, blockiert sie oder schreibt sensible Werte in Outgate-Platzhalter um, bevor das Upstream-Modell sie sieht. Der Client ruft denselben Endpoint auf — der Anfragepfad enthält jetzt nur einen zusätzlichen Schutzschritt.

Wie Validierung läuft

Das Gateway liest den Request-Body und lässt den Guardrail-Service ihn prüfen.

Guardrail-Validierung läuft im Gateway, bevor die Upstream-Anfrage gemacht wird. Das Gateway liest den Request-Body, fügt Provider-, Organisations-, Policy-, Methode-, Pfad-, Content-Type-, User-Agent- und Client-IP-Kontext bei und ruft den regionalen Guardrail-Service unter /validate auf.

Wenn der Guardrail-Service nicht erreichbar ist oder unerwartet antwortet, läuft die Anfrage im Fail-Open-Modus weiter. Outgate protokolliert den Fehler für die Observability, blockiert produktiven Traffic aber nicht allein deshalb, weil der Validierungs-Service nicht antworten konnte.

Bei normalem Provider-Traffic läuft die Validierung nur für POST-Anfragen mit Body. Bei Dry-Run-Scans gibt das Gateway das Erkennungsergebnis direkt zurück, statt die Anfrage ans Upstream-Modell weiterzuleiten.

Erkennung und Vault-Matching

Outgate kombiniert frische Analyse mit Fingerabdruck-Treffern für bekannte Werte.

Der Guardrail-Service extrahiert text-tragende Inhalte aus der Anfrage und bewertet sie mit dem konfigurierten Guardrail-Modell. Gleichzeitig prüft er den Detection Vault — einen Redis-gestützten Fingerabdruck-Speicher für Werte, die Outgate schon einmal gesehen hat.

Der Vault speichert Hashes und tokenisierte Fingerabdrücke, im Produktivmodus keine Klartext-Werte. Wenn ein bekannter Wert wieder auftaucht, kann der Service ihn erkennen, ohne das Modell ihn neu entdecken zu lassen.

Neue Detections werden nach erfolgreicher Validierung asynchron in den Vault zurückgeschrieben. Das macht künftige Anfragen schneller und hilft Outgate, wiederkehrende PII oder Zugangsdaten über Prompts, Dateien, Tool-Ausgaben und Agent-Sessions hinweg wiederzuerkennen.

Policy-Verhalten

Policies legen fest, was passiert, wenn PII oder Zugangsdaten erkannt werden.

Eine Guardrail-Policy steuert, wie Outgate mit PII und Zugangsdaten umgeht. Für jede dieser Kategorien kann die Policy die Anfrage erlauben, blockieren, den Trefferwert anonymisieren und den Roh-Treffer aus den Guardrail-Aufzeichnungen redacten.

Blockieren stoppt die Anfrage, bevor sie den Upstream-Provider erreicht. Anonymisierung lässt die Anfrage weiterlaufen, ersetzt den sensiblen Wert aber zuvor durch einen Outgate-Platzhalter.

Redaction steuert, was in den Guardrail-Aufzeichnungen erscheint. Bei aktivierter Redaction behält Outgate genug Kontext, um die Entscheidung zu erklären, ohne den vollständigen Roh-Treffer in Logs oder Policy-Ergebnissen zu speichern.

Anonymisierung und Wiederherstellung in der Antwort

Sensible Werte werden vor dem Weiterleiten ersetzt und auf dem Rückweg wiederhergestellt.

Wenn der Guardrail-Service eine Anonymisierungs-Map zurückliefert, schreibt das Gateway den upstream-bound Request-Body um. Jeder erkannte Wert wird durch einen stabilen Platzhalter wie OG_PII_… oder OG_CREDENTIAL_… ersetzt.

Das Gateway hängt der Anfrage außerdem eine kurze Anweisung an, damit das Modell diese Platzhalter als Werte behandelt, die exakt erhalten bleiben sollen. Das hilft Agenten und Modell-Providern, Platzhalter durch Tool-Calls und Antworten zu reichen, ohne sie umzudeuten.

Auf dem Antwortpfad nutzt das Gateway die gespeicherte Anonymisierungs-Map, um Platzhalter durch die Originalwerte zu ersetzen, bevor die Antwort an den Aufrufer zurückgeht. Der Upstream-Provider sieht Platzhalter; der Aufrufer bekommt die erwartete Antwortform zurück.

Guardrails beobachten

Guardrail-Entscheidungen werden in Gateway-Logs und -Metriken geschrieben.

Das Gateway erfasst Guardrail-Latenz, -Entscheidung, -Schweregrad, -Block-Status, Anonymisierungs-Anzahl, Vault-Treffer und Cache-Statistiken. Der Log-Manager fasst diese Felder zu Metriken zusammen, sodass Teams sehen, wie Guardrails Traffic über die Zeit beeinflussen.

Blockierte Anfragen werden als Alerts geloggt. Nicht blockierende Detections werden als Detection-Events geloggt — so verstehen Teams, was geschützt wurde, ohne die Anwendung zu unterbrechen.

Alles zusammengeführt

Guardrails schützen den Anfragepfad, ohne Client-Code zu ändern.

Sobald Guardrails an einem Provider aktiv sind, ruft Ihre Anwendung weiter denselben Endpoint auf. Das Gateway validiert die Anfrage, wendet die Policy an, ersetzt sensible Werte bei Bedarf, leitet die sichere Variante nach upstream weiter und stellt Platzhalter in der Antwort wieder her.

Das gibt Teams einen zentralen Ort, um PII und Zugangsdaten zu schützen — und erhält gleichzeitig den Entwickler-Workflow und die Provider-APIs, die sie ohnehin nutzen.