Zum Hauptinhalt springen
Secrets landen, wo sie nicht hingehören. Ein Entwickler fügt eine .env-Datei in einen Prompt für „Hilfe beim Debuggen” ein. Ein abgerufenes Dokument trägt einen eingebetteten API-Key. Ein Modell, gebeten, „die Config zu zeigen”, echot einen AWS-Access-Key direkt an den Client zurück. Ein Agent konstruiert einen Tool-Call mit einem aktiven Token, der in die Argumente eingebacken ist. Jedes davon ist ein Pfad, auf dem eine Anmeldedaten-Information entkommen kann — in die Logs eines Upstream-Anbieters, in ein Client-Transkript oder in ein Drittanbieter-Tool. Diese Seite behandelt, wie OrcaRouters Guardrails und die Agent-Firewall Ihnen ermöglichen, sich gegen LLM-Secret-Leakage zu verteidigen — ohne Ihren Anwendungscode zu ändern.
Die Erkennung erfolgt am Gateway, vor jedem gebundenen Key — sodass eine einzige Policy jeden Anbieter, jedes Modell und jeden Agenten ohne SDK-Änderung abdeckt.

​
1. Wo Secrets leaken

Eine Anmeldedaten-Information kann an drei distinkten Punkten eines Requests entkommen:
Die Anmeldedaten sind im Request, bevor das Modell je läuft — ein eingefügter Key, ein .env-Snippet, ein Token in einem abgerufenen RAG-Chunk. Ungeprüft erreicht es den Upstream-Anbieter und kann in seinen Logs landen. Stoppen Sie es mit dem Secrets-Blocker-Input-Guardrail (§2).
Das Modell gibt ein Secret an Ihren Client zurück — es würgt einen Key aus seinem Kontext heraus oder halluziniert einen anmeldedaten-förmigen String. Fangen Sie es mit einer Output-Secrets-Regel ab (§3).
Ihr Agent baut einen Tool-Call mit einem Token in den Argumenten. Das sanitize-Verdikt der Firewall redigiert gematchte Teilstrings aus den Argumenten, bevor der Aufruf dispatcht wird (§4).
Die ersten beiden sind Inhaltsprüfungen (Guardrails); die dritte ist eine Aktionsprüfung (Firewall). Schichten Sie alle drei für Defense in Depth.

​
2. Secrets-Blocker — Anmeldedaten im Prompt stoppen

Der Secrets-Blocker ist ein Guardrail-Preset unter der secrets-Kategorie, das auf der input-Stage läuft. Er scannt den Request nach Anmeldedaten-Formen — AWS-Access-Keys, OpenAI-förmige Keys und GitHub-Tokens — und blockiert den Aufruf, bevor er das Gateway verlässt. Die Anmeldedaten erreichen nie ein Modell. Verfassen Sie es einmal in der Konsole, hängen Sie einen Key an, und jeder Request durch diesen Key wird gescreent:
1

Das Guardrail erstellen

Öffnen Sie in der Konsole /console/guardrails, klicken Sie auf New guardrail und wenden Sie das Secrets & API-Key Blocker-Preset aus der secrets-Kategorie an. Es seedet ein Guardrail mit Block-Regeln auf der Input-Stage für die gängigen Anmeldedaten-Formen — bearbeiten Sie von dort aus frei.
2

Einen Key anhängen

Öffnen Sie /console/token, bearbeiten Sie einen API-Key und wählen Sie das Guardrail aus dem Guardrail-Dropdown — oder setzen Sie es als Workspace-Default, sodass jeder nicht angehängte Key es erbt.
3

Einen Request senden

Rufen Sie das Gateway genau wie zuvor mit diesem sk-orca-...-Key auf:
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "why is AKIAIOSFODNN7EXAMPLE rejected"}
    ]
  }'
Die AWS-Key-Form löst das Guardrail aus, und der Request wird mit HTTP 400 guardrail_blocked abgelehnt. Der Key erreicht das Modell nie.
Ein blockierter Request kostet kein Kontingent — ein Block auf der Input-Stage feuert vor der Messung — und ist als skip-retry markiert, sodass das erneute Ausführen desselben Prompts einfach wieder blockiert, statt einen Fallback-Channel zu verbrennen.
Brauchen Sie breitere Abdeckung? Die secrets-Kategorie liefert auch ein Private Keys & Cloud Tokens-Preset, das PEM-Private-Keys, Slack- und Stripe-Tokens, Google-API-Keys und JWTs blockiert. Wenden Sie beide an — ein Guardrail kann beliebig viele Regeln halten. Um JWTs und Anmeldedaten-Formen als typisierte Entitäten abzufangen (mit [JWT] / [AWS_ACCESS_KEY]-Tags), ist eine pii-Regel, die jwt, aws_access_key und api_key_openai abdeckt, die entitätsgetriebene Alternative; siehe die Guardrails-Referenz.
Das tight-Autonomie-Level der Firewall schaltet das Secrets-Blocker-Guardrail als Teil seiner Haltung ein, neben PII-Shield und Destructive-Shell-Ablehnungen. Wenn Sie einen Schalter statt von Hand verfasster Regeln wollen, ist das der schnelle Weg. Die Anmeldedaten-Prüfung selbst ist immer das Guardrail — nicht der Argument-Scanner der Firewall.

​
3. Secrets in der Modell-Ausgabe blockieren

Ein Secret kann auch in der Antwort abgehen — das Modell echot einen Key aus seinem Kontext oder gibt einen anmeldedaten-förmigen String aus. Fügen Sie eine Regel auf der output-Stage hinzu, um die Antwort des Modells zu screenen, bevor sie an den Client zurückkehrt. Die secrets-Kategorie liefert genau hierfür ein Code Secret in Output-Preset: Block-Regeln auf der Output-Stage für PEM-Private-Keys, AWS-Access-Keys und OpenAI-förmige Secret-Tokens. 
{
  "type": "regex",
  "stage": "output",
  "action": "block",
  "pattern": "AKIA[0-9A-Z]{16}"
}
Output-block wird auf nicht-streamenden und streamenden Antworten durchgesetzt — bei einem Stream schneidet ein Scanner die Antwort mitten im Flug, bevor blockierter Inhalt den Client erreicht. Ein Output-Block erstattet das vorab verbrauchte Kontingent.
Output-Maskierung (einen Treffer durch ein typisiertes Tag ersetzen, statt die ganze Antwort abzulehnen) gilt derzeit nur für nicht-streamende Antworten. Für Anmeldedaten in der Ausgabe ist die block-Aktion die zuverlässige Wahl auf streamendem Traffic. Beweisen Sie Ihre Stage/Stream-Kombination im Guardrail-Test-Tab, bevor Sie sich darauf verlassen.

​
4. Secrets aus Tool-Call-Argumenten bereinigen

Wenn Ihr Agent einen Tool-Call konstruiert, kann eine Anmeldedaten-Information in den Argumenten mitreisen. Das sanitize-Verdikt der Firewall redigiert gematchte Teilstrings aus den Tool-Call-Argumenten und leitet den bereinigten Aufruf weiter — auf den response- und mcp-Surfaces, wo es Aufruf-Zeit-Argumente zum Umschreiben gibt. Eine sanitize-Regel benennt in ihrer sanitize_json-Config, welche Detektoren zu redigieren sind — ein Set eingebauter Presets plus optionale benutzerdefinierte Regexes. Gematchtes Material wird durch [redacted:<preset>] ersetzt (benutzerdefinierte Treffer mit [redacted:custom]): 
{
  "priority": 10,
  "label": "Redact AWS keys from tool args",
  "stage": "response",
  "tool_name_glob": "*",
  "verdict": "sanitize",
  "sanitize_json": {
    "presets": ["aws_access_key", "aws_secret_key", "openai_key", "anthropic_key", "bearer_token"],
    "custom": []
  }
}
Die für einen Sanitizer verfügbaren Secret-Form-Presets sind aws_access_key, aws_secret_key, openai_key, anthropic_key und bearer_token (plus email, ssn_us und credit_card für PII). Eine Sanitize-Regel muss mindestens ein Preset oder benutzerdefiniertes Pattern benennen — ein leerer Sanitizer wird beim Speichern abgelehnt.
Sanitize redigiert Argumente, nicht Ergebnisse. Es bereinigt die Argumente eines Tool-Calls, den Ihr Agent verfasst hat; es schrubbt nicht den Inhalt, den ein Tool zurückgibt. Und auf der inbound-Surface — wo es noch keine Aufruf-Zeit-Argumente gibt — eskaliert sanitize zu einem deny. Siehe die Firewall-Regeln-Referenz für die Matching-Sprache.
Das Secrets-Blocker-Guardrail (§2) bleibt Ihre primäre Verteidigung für Anmeldedaten im Request-Body — der Firewall-Sanitizer ist das Aktionsebenen-Komplement für Secrets, die speziell innerhalb von Tool-Call-Argumenten auftauchen.

​
5. Die drei Verteidigungen schichten

Wo das Secret istEbene, die es stopptAktion
Im PromptSecrets-Blocker (Input-Guardrail)block
In der Antwort des ModellsOutput-Secrets-Regel (Output-Guardrail)block
In einem Tool-Call-ArgumentFirewall-Sanitizersanitize
Rollen Sie jede neue Regel zuerst im Shadow-Mode (Firewall) oder mit der flag-Aktion (Guardrail) aus. Beobachten Sie den Events- / Matches-Feed, um zu bestätigen, dass sie auf echte Anmeldedaten feuert und nicht auf harmlose Doppelgänger, und wechseln Sie dann zur durchsetzenden Aktion.

​
6. Beobachten, was gefeuert hat

Jede Guardrail-Regel, die feuert, zeichnet einen Match auf — Regeltyp, Aktion, Stage und einen Detail-String — auf dem Workspace-Matches-Feed (GET /api/guardrail/match, Member). Der gematchte Teilstring wird nur aufgezeichnet, wenn „Log raw content” an ist, was standardmäßig aus ist — die datenschutzkonservative Haltung, damit der Matches-Feed nicht selbst zu einem Ort wird, an dem sich Secrets ansammeln. Lassen Sie ihn für Anmeldedaten-Regeln aus, es sei denn, Sie brauchen den Teilstring ausdrücklich für die Triage. Firewall-Sanitize-Entscheidungen landen im Firewall-Events-Feed (GET /api/workspace/firewall/events, Developer+), wobei Secrets und Regel-Blobs nie geloggt werden.

​
7. Wohin als Nächstes

Guardrails-Referenz

Regeltypen, PII-Entitäten, Presets, die Test-Sandbox und das Eval-Harness im Vollen.

Firewall-Regeln-Referenz

Die Matching-Sprache — Tool-Globs, Argument-Klauseln und Sanitizer.

PII-Offenlegung

Die Geschwister-Inhaltsbedrohung: persönliche Daten in Prompts und Antworten.

Datenexfiltration

Wenn eine geleakte Anmeldedaten-Information zur Nutzlast eines ausgehenden Exfil-Aufrufs wird.

Guardrails vs. Firewall

Welche Ebene welche Klasse von Leck stoppt und wie sie komponieren.

Secure-Agents-Baseline

Die Ausgangshaltung, die diese Verteidigungen zusammen einschaltet.