Zum Hauptinhalt springen
Ein Prompt, der einen AKIA...-Key trägt, eine eingefügte .env, ein Agent, der sein eigenes sk-...-Token wiederholt — all das kann ein lebendes Credential im Klartext an OpenAI, Anthropic oder Google ausliefern, wo es in deren Logs und in Ihren landet. Secrets Blocker stoppt das am Gateway: ein Ein-Klick-Guardrail-Preset, das die Anfrage auf Credential-Formen scannt und den Aufruf mit HTTP 400 ablehnt, bevor ein einziges Byte Ihr Gateway verlässt. Dies ist eine fokussierte Landing für den Secret-Leakage-Anwendungsfall. Für die vollständige Guardrail-Engine — jeder Regeltyp, jedes Feld, jede Route — siehe die Guardrails-Referenz.

​
1. API-Key-Leaks in LLM-Flows in einem Preset verhindern

Der ganze Sinn von prevent api key leak llm-Plumbing ist, das Credential vor dem Upstream-Aufruf abzufangen, nicht nachdem es bereits im Request-Log eines Anbieters liegt. Das Secrets Blocker-Preset tut genau das. Es ist ein kleines Guardrail aus Input-Stage-block-Regeln, jede eine Regex für eine bekannte Credential-Form:
AKIA gefolgt von 16 großgeschriebenen alphanumerischen Zeichen — die kanonische AWS-Access-Key-ID-Form.
Ein sk--Präfix gefolgt von einem langen Token-Body — die Form, die OpenAI und mehrere ähnlich aussehende Anbieter-Keys verwenden.
Ein ghp_-Präfix gefolgt von einem 36-Zeichen-Body.
Wenn irgendeine Regel matcht, wird die Anfrage blockiert — das Gateway leitet sie nie weiter. Die Policy lebt im Gateway, nicht in Ihrer Anwendung, sodass Ihre App /v1/chat/completions weiterhin genau wie zuvor aufruft, ohne SDK-Änderung und ohne Redeploy.
Input-Stage, vor der Messung. Secrets Blocker prüft, was Sie senden. Ein Match lehnt den Aufruf ab, bevor das Modell aufgerufen wird, sodass das Credential den Anbieter nie erreicht und ein blockierter Request kein Kontingent kostet. Um auch ein Secret abzufangen, das ein Modell zurück an den Client emittiert, paaren Sie es mit einem Output-Block-Preset — siehe §5.

​
2. Das Preset in der Konsole anwenden

Jeder Schritt hier ist eine Konsolen-Aktion auf dem gehosteten Gateway unter Ihrer eigenen Session. Das Erstellen und Bearbeiten von Guardrails erfordert Developer+ im Workspace. Nur der finale /v1/*-Aufruf verwendet einen sk-orca-...-Relay-Key.
1

Das Template öffnen

Öffnen Sie in der Konsole Guardrails, klicken Sie auf den New guardrail-Splitbutton und wählen Sie Secrets & API-Key Blocker aus der Secrets-Template-Kategorie. Es legt die Input-Stage-Block-Regeln an.
2

Benennen und speichern

Geben Sie ihm einen Namen (≤ 64 Zeichen), z. B. secrets-blocker, und speichern Sie. Ein Preset ist ein Keim, keine Sperre — fügen Sie Regeln danach frei hinzu oder bearbeiten Sie sie (siehe §4).
3

Es testen

Öffnen Sie den Tab Test, fügen Sie ein Beispiel-Credential an der input-Stage ein und führen Sie die Policy lokal aus — kein Upstream-Aufruf, kein Kontingent (siehe §3).
4

Einen Key anhängen

Bearbeiten Sie einen API-Key und wählen Sie secrets-blocker aus dem Dropdown Guardrail (setzt guardrail_id auf dem Key) oder markieren Sie es als Workspace-Default. Siehe An einen Key anhängen und Account-Default.

​
3. Vor dem Anhängen testen

Beweisen Sie, dass die Regel feuert, bevor irgendein Key auf sie zeigt. Öffnen Sie den Tab Test im Editor, fügen Sie ein Dummy-Credential ein, wählen Sie die input-Stage und führen Sie aus: 
Here is my key: AKIAIOSFODNN7EXAMPLE
Die Sandbox evaluiert die aktuelle Policy lokal — nichts wird nach Upstream gesendet, nichts gemessen — und gibt das block-Verdikt zurück, das die ausgelöste Regel benennt. Für ein A/B-Raster gegen einen Korpus aus geleakten-Secret- und harmlosen Samples liegt das Eval-Harness einen Tab weiter.

​
4. Die Abdeckung erweitern

Secrets Blocker deckt die drei verkehrsreichsten Formen ab. Die Secrets-Kategorie liefert Geschwister-Presets, die Sie daneben anwenden können, und Sie können Ihre eigene regex-Regel für jedes Token verfassen, das Ihr Stack ausgibt:

Private Keys & Cloud Tokens

Ein begleitendes Secrets-Preset, das PEM-Private-Keys, Slack- und Stripe-Tokens, Google-API-Keys und JWTs auf der Anfrage blockiert.

Crypto Wallet Block

Blockiert BTC- und ETH-artige Wallet-Adressen auf der Anfrage, wenn sie nie den Anbieter erreichen sollten.
Um ein internes Token-Format zu matchen, fügen Sie eine regex-Regel — RE2-Muster, lineare Zeit, keine Backreferences — an der input-Stage mit Action block hinzu. Schlechte Muster werden beim Speichern abgelehnt, sodass ein Guardrail, das Sie speichern können, immer kompiliert.
Statt zu blockieren, möchten Sie ein geleaktes Secret redigieren und die Anfrage bereinigt durchlassen? Verwenden Sie eine pii-Regel mit einer mask-Action — der eingebaute Detektor-Satz umfasst aws_access_key, api_key_openai und jwt, jeweils zu einem typisierten Tag wie [AWS_ACCESS_KEY] rendernd. Siehe Actions für block vs. mask.

​
5. Secrets auch in der Antwort abfangen

Secrets Blocker prüft die Anfrage. Ein separates Secrets-Preset, Code Secret in Output, prüft die Antwort des Modells auf Private-Keys und AWS-/OpenAI-artige Tokens und blockiert den Aufruf, wenn eines zurückleakt. Output-block wird in beiden Wegen durchgesetzt: bei einer nicht-streamenden Response wird die Antwort geprüft, bevor sie zurückkehrt, und bei einer streamenden Response kappt ein Scanner den Stream, bevor blockierter Inhalt den Client erreicht. Ein Block der Output-Stage erstattet das vorab verbrauchte Kontingent zurück. Siehe Output-Stage-Regeln und Streaming-Abdeckung.

​
6. Wie ein Block aussieht

Ein blockierter Request gibt HTTP 400 mit dem Fehlercode guardrail_blocked und einer Nachricht zurück, die das Guardrail und die ausgelöste Regel benennt: 
{
  "error": {
    "code": "guardrail_blocked",
    "message": "request blocked by guardrail \"secrets-blocker\": regex(...)"
  }
}
Die Anfrage kostet kein Kontingent — ein Block der Input-Stage feuert vor der Messung — und wird als skip-retry markiert, da das erneute Ausführen desselben Prompts gegen einen anderen Channel einfach wieder blockieren würde. Siehe den guardrail_blocked-Fehler.

​
7. Sehen, was gefeuert hat

Jede Regel, die feuert, zeichnet einen Match auf — Regeltyp, Action, Stage und einen Detail-String — zur Oberfläche gebracht im Workspace-Matches-Feed. Der gematchte Teilstring selbst (das Credential) wird nur aufgezeichnet, wenn Log raw content an ist, was standardmäßig aus ist.
Für eine Secrets-Kontrolle ist es meist genau der Punkt, Log raw content aus zu lassen: das Erfassen des gematchten Teilstrings würde das geleakte Credential direkt in Ihre eigene Telemetrie zurückschreiben. Lassen Sie es aus, sofern Sie keinen engen Triage-Bedarf haben, und rotieren Sie jedes Credential, das abgefangen wurde — ein blockierter Request bedeutet, dass das Secret in einem Prompt exponiert war, nicht dass es sicher ist. Siehe Matches-Feed und Logging & Datenschutz.

​
8. Wohin als Nächstes

Regex-Detektoren

Verfassen Sie Ihre eigenen Credential-Muster mit RE2-Regex-Regeln.

Actions

Wählen Sie block, mask, flag, annotate oder spotlight pro Regel — und block, mask, flag oder annotate pro Entity.

PII Shield

Maskieren Sie E-Mails, SSNs und Karten zu typisierten Tags, bevor das Modell sie sieht.

Fehlalarme tunen

Markieren Sie Fehlalarme und verschärfen Sie Detektoren aus dem Matches-Feed.
Secrets Blocker hält Credentials aus dem Inhalt heraus, den Sie senden. Um einen Agenten daran zu hindern, ein Secret über einen Tool-Call zu leaken — Exfiltration an einen vom Angreifer kontrollierten Host — verwenden Sie die Firewall und lesen Sie die Daten-Exfiltrations-Bedrohung und die Secret-Leakage-Bedrohung. Für die vollständige Guardrail-Engine siehe die Guardrails-Referenz.