Passer au contenu principal
Les secrets finissent là où ils n’ont pas leur place. Un développeur colle un fichier .env dans un prompt pour « aider au débogage ». Un document récupéré transporte une clé API intégrée. Un modèle, à qui l’on demande d’« afficher la config », renvoie une clé d’accès AWS directement au client. Un agent construit un appel d’outil avec un token actif embarqué dans les arguments. Chacun de ces cas est un chemin par lequel un identifiant peut s’échapper — vers les journaux d’un fournisseur amont, vers une transcription client, ou vers un outil tiers. Cette page couvre comment les Guardrails et l’Agent Firewall d’OrcaRouter vous permettent de défendre contre la fuite de secrets llm — sans changer le code de votre application.
La détection se produit à la passerelle, devant chaque clé liée — de sorte qu’une seule politique couvre chaque fournisseur, chaque modèle et chaque agent sans changement de SDK.

​
1. Où fuient les secrets

Un identifiant peut s’échapper en trois points distincts d’une requête :
L’identifiant est dans la requête avant que le modèle ne s’exécute — une clé collée, un extrait .env, un token à l’intérieur d’un chunk RAG récupéré. Laissé sans contrôle, il atteint le fournisseur amont et peut atterrir dans leurs journaux. Stoppez-le avec le guardrail d’entrée Secrets Blocker (§2).
Le modèle émet un secret vers votre client — il régurgite une clé depuis son contexte, ou hallucine une chaîne en forme d’identifiant. Attrapez-le avec une règle de secrets en sortie (§3).
Votre agent construit un appel d’outil avec un token dans les arguments. Le verdict sanitize du Firewall redacte les sous-chaînes correspondantes des arguments avant que l’appel ne se dispatche (§4).
Les deux premiers sont des contrôles de contenu (Guardrails) ; le troisième est un contrôle d’action (Firewall). Superposez les trois pour une défense en profondeur.

​
2. Secrets Blocker — stopper les identifiants dans le prompt

Le Secrets Blocker est un preset de guardrail sous la catégorie secrets qui s’exécute à la surface input. Il scanne la requête à la recherche de formes d’identifiants — clés d’accès AWS, clés de style OpenAI, et tokens GitHub — et bloque l’appel avant qu’il ne quitte la passerelle. L’identifiant n’atteint jamais un modèle. Rédigez-le une fois dans la console, attachez une clé, et chaque requête à travers cette clé est filtrée :
1

Créer le guardrail

Dans la console, ouvrez /console/guardrails, cliquez sur New guardrail, et appliquez le preset Secrets & API-Key Blocker depuis la catégorie secrets. Il amorce un guardrail avec des règles de block côté entrée pour les formes d’identifiants courantes — éditez librement à partir de là.
2

Attachez une clé

Ouvrez /console/token, éditez une clé API, et choisissez le guardrail dans le menu déroulant Guardrail — ou définissez-le comme défaut de l’espace de travail afin que chaque clé non attachée en hérite.
3

Envoyez une requête

Appelez la passerelle exactement comme avant avec cette clé sk-orca-... :
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"}
    ]
  }'
La forme de clé AWS déclenche le guardrail et la requête est rejetée avec une HTTP 400 guardrail_blocked. La clé n’atteint jamais le modèle.
Une requête bloquée ne coûte aucun quota — un block côté entrée se déclenche avant la mesure — et est marquée skip-retry, de sorte que ré-exécuter le même prompt ne fait que bloquer à nouveau au lieu de brûler un canal de repli.
Besoin d’une couverture plus large ? La catégorie secrets livre aussi un preset Private Keys & Cloud Tokens qui bloque les clés privées PEM, les tokens Slack et Stripe, les clés API Google, et les JWT. Appliquez les deux — un guardrail peut contenir un nombre quelconque de règles. Pour attraper les JWT et les formes d’identifiants comme entités typées (avec des tags [JWT] / [AWS_ACCESS_KEY]), une règle pii couvrant jwt, aws_access_key, et api_key_openai est l’alternative pilotée par les entités ; voir la référence des Guardrails.
Le niveau d’autonomie tight du Firewall active le guardrail Secrets Blocker dans le cadre de sa posture, aux côtés de PII Shield et des refus de shell destructeur. Si vous voulez un seul interrupteur au lieu de rédiger des règles à la main, c’est le chemin rapide. Le contrôle d’identifiant lui-même est toujours le guardrail — pas le scanner d’arguments du firewall.

​
3. Bloquer les secrets dans la sortie du modèle

Un secret peut aussi sortir dans la réponse — le modèle renvoie en écho une clé depuis son contexte ou émet une chaîne en forme d’identifiant. Ajoutez une règle à la surface output pour filtrer la réponse du modèle avant qu’elle ne revienne au client. La catégorie secrets livre un preset Code Secret in Output pour exactement cela : des règles de block côté sortie pour les clés privées PEM, les clés d’accès AWS, et les tokens secrets de style OpenAI. 
{
  "type": "regex",
  "stage": "output",
  "action": "block",
  "pattern": "AKIA[0-9A-Z]{16}"
}
Le block en sortie est appliqué sur les réponses non-streaming et streaming — sur un flux, un scanner coupe la réponse en vol avant qu’aucun contenu bloqué n’atteigne le client. Un block en sortie rembourse le quota pré-consommé.
Le masquage en sortie (remplacer une correspondance par un tag typé plutôt que rejeter la réponse entière) s’applique actuellement aux réponses non-streaming uniquement. Pour les identifiants en sortie, l’action block est le choix fiable sur le trafic en streaming. Prouvez votre combinaison surface/flux dans l’onglet Test du guardrail avant d’en dépendre.

​
4. Assainir les secrets hors des arguments d’appels d’outils

Lorsque votre agent construit un appel d’outil, un identifiant peut voyager avec dans les arguments. Le verdict sanitize du Firewall redacte les sous-chaînes correspondantes des arguments de l’appel d’outil et transmet l’appel nettoyé — sur les surfaces response et mcp, où il y a des arguments en direct au moment de l’appel à réécrire. Une règle sanitize nomme quels détecteurs redacter dans sa config sanitize_json — un ensemble de presets intégrés plus des regex custom optionnelles. Le matériel correspondant est remplacé par [redacted:<preset>] (les correspondances custom par [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": []
  }
}
Les presets de forme de secret disponibles pour un assainisseur sont aws_access_key, aws_secret_key, openai_key, anthropic_key, et bearer_token (plus email, ssn_us, et credit_card pour la PII). Une règle sanitize doit nommer au moins un preset ou un motif custom — un assainisseur vide est rejeté à l’enregistrement.
Sanitize redacte les arguments, pas les résultats. Il nettoie les arguments d’un appel d’outil que votre agent a rédigé ; il ne nettoie pas le contenu qu’un outil renvoie. Et sur la surface inbound — où il n’y a pas encore d’arguments au moment de l’appel — sanitize escalade en un deny. Voir la référence des règles de firewall pour le langage de correspondance.
Le guardrail Secrets Blocker (§2) reste votre défense principale pour les identifiants dans le corps de la requête — l’assainisseur du firewall est le complément côté action pour les secrets qui apparaissent spécifiquement à l’intérieur des arguments d’appels d’outils.

​
5. Superposer les trois défenses

Où se trouve le secretCouche qui le stoppeAction
Dans le promptSecrets Blocker (guardrail d’entrée)block
Dans la réponse du modèleRègle de secrets en sortie (guardrail de sortie)block
Dans un argument d’appel d’outilAssainisseur du firewallsanitize
Déployez toute nouvelle règle en mode shadow (firewall) ou avec l’action flag (guardrail) d’abord. Surveillez le flux events / Matches pour confirmer qu’elle se déclenche sur de vrais identifiants et non sur des sosies bénins, puis passez à l’action appliquante.

​
6. Observer ce qui s’est déclenché

Chaque règle de guardrail qui se déclenche enregistre une correspondance — type de règle, action, surface, et une chaîne de détail — dans le flux Matches de l’espace de travail (GET /api/guardrail/match, Member). La sous-chaîne correspondante est enregistrée uniquement lorsque « Log raw content » est activé, ce qui est désactivé par défaut — la posture respectueuse de la vie privée, afin que le flux Matches ne devienne pas lui-même un endroit où les secrets s’accumulent. Laissez-le désactivé pour les règles d’identifiants sauf si vous avez spécifiquement besoin de la sous-chaîne pour le triage. Les décisions sanitize du firewall atterrissent dans le flux Events du Firewall (GET /api/workspace/firewall/events, Developer+), avec les secrets et les blobs de règles jamais journalisés.

​
7. Où aller ensuite

Référence des Guardrails

Types de règles, entités PII, presets, le sandbox de test, et le harnais d’éval au complet.

Référence des règles de firewall

Le langage de correspondance — globs d’outils, clauses d’arguments, et assainisseurs.

Exposition de PII

La menace de contenu sœur : données personnelles dans les prompts et les réponses.

Exfiltration de données

Quand un identifiant fuité devient la charge utile d’un appel d’exfiltration sortant.

Guardrails vs Firewall

Quel plan stoppe quelle classe de fuite, et comment ils se composent.

Référentiel Secure Agents

La posture de départ qui active ces défenses ensemble.