Detection Vault
Wie Outgate erkannte sensible Werte speichert, was den Vault befüllt und was zu erwarten ist, wenn sich darin etwas ändert.
Was der Vault ist
Ein organisationsweiter Speicher von Fingerprints für Werte, die im Traffic anonymisiert werden sollen.
Wenn Guardrails sensiblen Inhalt erkennen — eine E-Mail-Adresse, einen API-Schlüssel, eine Telefonnummer — ersetzt Outgate diesen durch einen Platzhalter wie [EMAIL_1], bevor die Anfrage das Modell erreicht. Der Detection Vault speichert die Zuordnung zwischen Originalwert und Platzhalter, damit das Gateway denselben Wert in jeder weiteren Anfrage konsistent ersetzt und Originale in der Antwort wiederherstellen kann.
Der Vault ist Ihrer Organisation zugeordnet und liegt in der Region, die die Anfrage verarbeitet hat. Er enthält Fingerprints — Token-Mengen und Hashes — keinen Klartext (außer in einem expliziten Debug-Modus, der ausschließlich für Incident-Triage in selbst gehosteten Regionen genutzt wird).
- Pro Organisation: alle Mitglieder einer Organisation teilen sich denselben Vault innerhalb einer Region.
- Pro Region: jede Region führt ihren eigenen Vault; Einträge wandern nicht automatisch in andere Regionen.
- TTL-begrenzt: Einträge laufen standardmäßig nach sieben Tagen Inaktivität ab. Ein Treffer setzt die TTL zurück.
- Hash-first: Produktiv-Deployments speichern nur Hashes plus tokenisierte Fingerprints — der Klartext verlässt die Gateway-Grenze nicht.
Anonymisierung vs. Erkennung
Der Vault ist nur für Kategorien relevant, bei denen die Guardrail-Policy auf Anonymisieren steht. Erkennungen, die blockieren oder nur warnen, schreiben nicht in den Vault — es gibt keinen Wert, der zurückgemappt werden müsste.
Kategorien und Quellen
Jeder Eintrag ist nach Kategorie und Quelle gekennzeichnet.
Einträge werden entlang zweier Achsen geordnet. Die Kategorie beschreibt, was der Wert ist — sein Risikotyp. Die Quelle beschreibt, wie er in den Vault gelangt ist.
| Kategorie | Standardverhalten |
|---|---|
| personal_information | Anonymisieren (in neuen Policies standardmäßig aktiv) |
| credentials | Anonymisieren (in neuen Policies standardmäßig aktiv) |
| Quelle | Wie Einträge entstehen |
|---|---|
| auto-detect | Automatisch während einer Live-Anfrage durch das Gateway erkannt. |
| kv-scan | Durch einen Scan-Lauf gefunden — entweder via og-cli scan oder Console-getriggert über historischen Traffic. |
| manual | Direkt über die Console oder die og-cli Vault-Befehle hinzugefügt. |
Die Quelle ist wichtig beim Leeren des Vaults. Console und CLI bieten gezielte Flushes pro Quelle, sodass Sie automatische Erkennungen löschen können, ohne manuell gepflegte Einträge zu verlieren.
Befüllen über die Console
Einträge unter Gateway → Guardrails → Detection Vault anlegen, beschriften und leeren.
Die Console zeigt den Vault unter Gateway → Guardrails → Detection Vault. Dort sehen Sie alle gesammelten Einträge der Organisation, eine Zusammenfassung von Kategorien und Quellen, können Einträge manuell hinzufügen und gezielt leeren.
- Hinzufügen: Kategorie wählen, Wert einfügen und optional ein kurzes Tag zur Gruppierung anhängen. Die Quelle wird auf manual gesetzt. Die Console hasht den Wert clientseitig, bevor der Eintrag zum regionalen Guardrail-Service geht.
- Pro Quelle leeren: auto-detect, kv-scan, manual oder all. Nützlich, um Automatisierungs-Rauschen zu löschen, ohne kuratierte Einträge zu verlieren.
- Statistik: Gesamtzahl Einträge, Trefferquote und Zeitpunkt des letzten Scans. Operator-Sicht, nicht für Endnutzer gedacht.
Sichtbarkeit
Die Vault-Seite in der Console ist organisationsweit. Jede Person mit Console-Zugriff auf die Organisation sieht jeden Eintrag. Behandeln Sie Tags wie öffentliche Labels innerhalb der Organisation, nicht wie private Notizen.
Befüllen über og-cli
Mit og scan Einträge erzeugen und mit og vault add/list/rm pflegen.
Das CLI bietet zwei Wege in den Vault. og scan führt die Erkennung im Dry-Run aus — die Anfrage erreicht das Modell nicht, aber jede Erkennung wird unter der Quelle kv-scan in den Vault geschrieben. og vault ist ein kleines Set an CRUD-Befehlen zur direkten Pflege.
# Dry-Run-Scan gegen einen guardrail-aktivierten Provider; füllt den Vault
og scan --provider my-provider path/to/file
# Einträge direkt pflegen
og vault add "sk-ant-abc123def456" --category credentials --tag staging
og vault list --category credentials
og vault rm --tag staging- og scan nutzt den Gateway-Endpunkt des ausgewählten Providers und durchläuft dieselbe Erkennungspipeline wie eine Live-Anfrage — nur ohne Weiterleitung an das Modell.
- og vault add speichert den Wert unter der Quelle manual mit optionalem Tag. Das Tag ist eine freie Beschriftung mit bis zu 200 Zeichen.
- og vault rm mit --tag entfernt jeden Eintrag, dessen Tag den angegebenen Substring enthält.
Wohin das CLI schreibt
og vault und og scan zielen auf das regionale Gateway, das über --provider gewählt wurde. Erstreckt sich Ihre Organisation über mehrere Regionen, werden Einträge nicht automatisch repliziert — scannen Sie einmal pro Region, in der das Gateway den Wert erkennen soll.
Befüllen über API-Traffic
Live-Anfragen durch das Gateway sind die Hauptquelle für Vault-Wachstum.
Die meisten Einträge entstehen ohne explizite Aktion. Wenn Sie eine Anfrage an einen guardrail-aktivierten Endpunkt senden, läuft die Validierung, erkannte Werte werden vor dem Weiterleiten an das Modell durch Platzhalter ersetzt, und die entstehenden Fingerprints werden asynchron in den Vault geschrieben. Die nächste Anfrage mit demselben Wert trifft den bestehenden Fingerprint, statt das Modell erneut zur Erkennung zu bemühen.
Auf dem Antwortpfad schlägt das Gateway die Platzhalter im Vault nach und setzt die Originalwerte wieder ein, sodass Ihre Anwendung den rehydrierten Text sieht. Das passiert transparent für normale Completion- und Chat-APIs.
- Die Quelle wird als auto-detect gespeichert.
- Die TTL wird bei jedem Treffer zurückgesetzt — wiederkehrende Werte bleiben im Vault, solange sie mindestens alle sieben Tage gesehen werden.
- Streaming-Antworten werden für den Rehydrationsdurchlauf gepuffert; Platzhalter dringen nicht mid-stream zum Client durch.
Anzeige im Chat
Wie chat.outgate.ai Vault-Treffer hervorhebt, ohne Klartext im Browser preiszugeben.
Die Chat-App hat pro Thread einen Schalter "Erkennungen anzeigen", der Stellen einer Nachricht hervorhebt, die mit Vault-Einträgen übereinstimmen. Ist der Schalter aktiv, fragt das Chat-Backend beim regionalen Guardrail-Service nach den relevanten Erkennungen für diesen Thread — aber nur als Hashes und Token-Muster, niemals als Klartext. Der Browser hält keine Rohwerte; er gleicht lediglich den lokalen Nachrichtentext gegen die Fingerprints ab.
- Der Schalter ist pro Thread und wird lokal gemerkt.
- Standardmäßig werden personal_information und credentials angezeigt; weitere Kategorien lassen sich pro Thread aktivieren.
- Ein Vault-Flush über die Console entfernt die Hervorhebungen, lässt die Chat-Nachrichten selbst aber unangetastet.
Auswirkungen und Randfälle
Was zu erwarten ist, wenn sich der Vault ändert, abläuft oder mit Ihnen wandert.
Ein paar Dinge sollte man im laufenden Betrieb von Outgate im Kopf behalten.
Ein Vault-Flush schreibt alte Nachrichten nicht um.
Eine Anfrage, die vor dem Flush anonymisiert wurde, enthält weiterhin Platzhalter wie [EMAIL_1]. Ohne passenden Vault-Eintrag bleiben diese Platzhalter in historischen Ansichten als Literale stehen. Neue Anfragen starten frisch.
Cross-Region-Traffic baut getrennte Vaults auf.
Hat Ihre Organisation Gateways in zwei Regionen und derselbe Wert erscheint in beiden, hält jede Region ihren eigenen Fingerprint. Ein Flush in einer Region wirkt sich nicht auf die andere aus; ein Scan in einer Region befüllt die andere nicht.
Hash-only als Standard.
Produktive Regionen speichern Fingerprints, keinen Klartext — weder Betreiber noch kompromittierte Infrastruktur können den Originalwert allein aus dem Vault rekonstruieren. Selbst gehostete Regionen können optional einen Debug-Speichermodus aktivieren, der Klartext für kurze Incident-Triage hält — lassen Sie ihn im Normalbetrieb aus.
Die TTL hält den Vault klein.
Einträge laufen nach sieben Tagen ohne Treffer ab. Verschwindet ein Wert für mehr als eine Woche aus Ihrem Traffic und erscheint dann erneut, erkennt das Gateway ihn neu und legt einen neuen Eintrag an. Der Platzhalter-Index kann sich von früher unterscheiden.
Tags sind innerhalb der Organisation sichtbar.
Sie sind nützlich zum Strukturieren — etwa um Staging-Zugangsdaten anders zu markieren als Produktion — sollten aber als öffentliche Labels innerhalb der Organisation behandelt werden.
Öffentliche API
Den Vault programmatisch mit einem API-Key verwalten.
Jede Aktion in der Console oder über og-cli hat einen passenden HTTP-Endpunkt — CI-Jobs, interne Tools und SDKs können den Vault ohne Mensch in der Schleife verwalten. Authentifiziert wird mit demselben organisationsweiten API-Key, den Sie unter Console → Gateway → API Keys anlegen (Wert beginnt mit `gw_`). Der Key wird als Bearer-Token gesendet; das Gateway leitet aus ihm Ihre Organisation ab und nutzt den X-Region-Id-Header zur Regionsauswahl.
Der Zugriff wird über zwei Scopes geregelt. Wählen Sie die Scopes beim Erzeugen des Keys aus — sie erscheinen als Checkboxen im Anlege-Dialog.
| Scope | Erlaubt |
|---|---|
| outgate.vault.read | GET /api/v1/vault/stats, GET /api/v1/vault/detections |
| outgate.vault.write | POST /api/v1/vault/detections, DELETE /api/v1/vault/detections/{hash}, DELETE /api/v1/vault/detections/by-tag/{tag}, POST /api/v1/vault/flush |
Nur Hashes
Listen-Endpunkte liefern Hashes und Token-Muster, niemals Klartext. Dieselbe Einschränkung, die das Chat-UI vor Rohwerten schützt, gilt für die öffentliche API.
Beispiele. Ersetzen Sie `gw_…` durch Ihren Key und `reg-…` durch die Region-ID, die Sie ansprechen wollen.
# Vault-Statistik
curl https://api.outgate.ai/api/v1/vault/stats \
-H "Authorization: Bearer gw_…" \
-H "X-Region-Id: reg-…"
# Einträge listen (paginiert, nur Hashes)
curl "https://api.outgate.ai/api/v1/vault/detections?category=credentials&limit=100" \
-H "Authorization: Bearer gw_…" \
-H "X-Region-Id: reg-…"
# Eintrag manuell hinzufügen
curl -X POST https://api.outgate.ai/api/v1/vault/detections \
-H "Authorization: Bearer gw_…" \
-H "X-Region-Id: reg-…" \
-H "Content-Type: application/json" \
-d '{"value":"sk-ant-abc123","category":"credentials","tag":"staging"}'
# Eintrag per Hash löschen
curl -X DELETE https://api.outgate.ai/api/v1/vault/detections/<hash> \
-H "Authorization: Bearer gw_…" \
-H "X-Region-Id: reg-…"
# Alle Einträge löschen, deren Tag 'staging' enthält
curl -X DELETE https://api.outgate.ai/api/v1/vault/detections/by-tag/staging \
-H "Authorization: Bearer gw_…" \
-H "X-Region-Id: reg-…"
# Nur automatisch erkannte Einträge leeren
curl -X POST https://api.outgate.ai/api/v1/vault/flush \
-H "Authorization: Bearer gw_…" \
-H "X-Region-Id: reg-…" \
-H "Content-Type: application/json" \
-d '{"scope":"auto"}'- Fehlender X-Region-Id-Header → 400 region_required.
- Ungültiger oder widerrufener Key → 401 unauthorized.
- Key ohne den nötigen Scope → 403 mit Angabe des fehlenden Scopes.
- Region nicht aktiv für die Organisation → 403 forbidden.
Für die Kommandozeile lieber das CLI
og-cli bietet `og vault add/list/rm` für dieselben Operationen, ohne dass Sie curl, Header und JSON-Bodies selbst zusammenbauen müssen. Die öffentliche API ist die richtige Wahl für Automatisierung und SDKs; das CLI ist die richtige Wahl für Ad-hoc-Aufgaben im Terminal.