Passer au contenu principal
Le jour où vous placez un agent devant des utilisateurs est le pire jour pour découvrir qu’un jailbreak traverse directement votre politique de contenu, ou qu’un outil que vous avez oublié de gouverner se déclenche à la première exécution. Un red team pré-lancement transforme ces surprises en un nombre que vous pouvez lire avant de déployer — et OrcaRouter vous donne trois façons de le produire, toutes sans toucher le code de votre agent ni envoyer une seule requête en direct que vous ne vouliez pas. Cette recette est la passe de dry-run : mesurer une politique contre des attaques connues, la shadow contre votre propre trafic, et simuler une posture plus serrée avant de vous y engager.
Tout ici est en lecture seule ou en sandbox — aucun block visible par l’utilisateur, aucun trafic de production affecté. (Les règles mot-clé, regex et PII s’exécutent entièrement en local ; une règle llm_judge appelle quand même son modèle configuré, donc une eval sur une politique de juge fait bel et bien cet appel.) Le but est de casser les choses avant le lancement, selon vos conditions.

​
1. Comment red-teamer un agent IA avant le lancement

Un red team pré-lancement répond à trois questions, et OrcaRouter a un outil pour chacune :

Mon guardrail attrape-t-il les attaques ?

Exécutez le harnais Eval du guardrail contre des corpus adversariaux intégrés et lisez en retour précision / rappel / F1.

Qu'est-ce que mon firewall casserait ?

Activez le mode shadow et regardez quels appels d’outils réels seraient refusés — sans en refuser aucun pour l’instant.

Une posture plus serrée est-elle sûre ?

Simulez un niveau d’autonomie pour prévisualiser exactement ce qu’il changerait contre votre trafic avant de l’appliquer.
Le premier teste vos Guardrails (le plan texte) ; le second et le troisième testent votre Firewall (le plan action). Une vraie checklist de lancement exécute les trois.

​
2. Scorez votre guardrail contre des corpus adversariaux

La façon la plus rapide de savoir si une politique de contenu survit au contact d’un attaquant est de lui lancer un corpus d’attaques connues et de lire le score. L’onglet Eval de l’éditeur de guardrail fait exactement cela : il rejoue chaque échantillon d’un corpus à travers votre politique actuelle et compare le verdict au résultat attendu de chaque échantillon — en rejouant le corpus en local contre vos règles, jamais contre du trafic en direct. OrcaRouter livre des corpus red-team intégrés afin que vous n’ayez pas à sourcer les vôtres. Parmi eux :
CorpusCe que c’est
advbench_harmful_behaviorsLe jeu cible canonique de suffixe adversarial — chaque ligne est une requête non sûre qu’un guardrail devrait bloquer.
anthropic_hh_redteamDe vrais transcripts red-team humains multi-tours contre un assistant.
deepset_prompt_injectionsRequêtes d’injection de prompt vs bénignes étiquetées — une baseline précision/rappel pour un block au stade input.
databricks_dolly_benignUne baseline purement bénigne : une politique trop stricte ne devrait en bloquer aucune.
Associez toujours un corpus d’attaque à un corpus bénin. Une politique qui bloque 100 % des attaques mais bloque aussi databricks_dolly_benign n’est pas sûre — elle est inutilisable. L’exécution bénigne est votre budget de faux positifs.
Exécutez une eval contre le corpus intégré deepset_prompt_injections : 
curl https://api.orcarouter.ai/api/guardrail/123/eval \
  -H "Authorization: Bearer <your-session-token>" \
  -H "X-Workspace-Id: <workspace-id>" \
  -H "Content-Type: application/json" \
  -d '{ "corpus_name": "deepset_prompt_injections" }'
Les routes /api/guardrail/* utilisent votre session de console / token d’accès, pas une clé de relais sk-orca-... — et elles sont à portée d’espace de travail via X-Workspace-Id. En pratique, vous l’exécuterez depuis l’onglet Eval dans la console ; le curl est ici pour montrer la forme. Exécuter une eval est ouvert à tout Member.
L’exécution rapporte les métriques de détection calculées contre les actions attendues :
  • TP / FP / FN / TN — vrais/faux positifs et négatifs, où un « faux positif » inclut le fait d’attraper une attaque avec la mauvaise classe d’action (par ex. masquer quand vous attendiez un block).
  • Précision / Rappel / F1 — les chiffres phares. Un rappel faible signifie que des attaques passent ; une précision faible signifie que vous bloquez du trafic bénin.
Ouvrez l’exécution pour inspecter les échecs échantillon par échantillon, ajustez la règle ou la grille du juge, et réexécutez jusqu’à ce que le score tienne. Les corpus personnalisés fonctionnent de la même façon — téléversez votre propre JSONL (Developer+) pour tester contre les formes d’attaque exactes auxquelles votre produit fait face.
Où vit la défense contre l’injection de prompt. Le preset intégré Prompt-Injection Basics est une règle de mot-clé sur l’action flag — il fait remonter les phrases de jailbreak courantes pour revue sans bloquer l’utilisateur. Pour l’intention d’injection sémantique qu’aucune liste de mots-clés ne capture, ajoutez une règle llm_judge et red-teamez-la de la même façon : eval contre deepset_prompt_injections et anthropic_hh_redteam et lisez le F1. Voir la référence guardrail.

​
3. Mode shadow du firewall contre du trafic réel

Une eval de guardrail teste du texte contre un corpus fixe. Votre firewall, en revanche, doit être testé contre la réalité désordonnée de ce que votre agent fait réellement — et la façon la plus sûre de faire cela avant le lancement est le mode shadow. Le mode shadow est un flag par politique qui fait que le firewall évalue et journalise chaque appel d’outil exactement comme il le ferait en production, mais rétrograde chaque verdict appliquant en audit. Un deny devient une ligne d’audit dont la raison est préfixée [shadow] would …. Rien n’est bloqué. Rien ne casse. Mais le flux Events vous montre maintenant la liste précise des appels que votre politique aurait rejetés. C’est le red team du firewall : rédigez votre politique prévue la plus stricte, activez le mode shadow, exécutez votre agent à travers une répétition de lancement réaliste, puis lisez les événements [shadow] would ….
Construisez votre politique appliquante dans la console (Developer+) — pour un dry-run de lancement, définissez default_verdict sur audit et ajoutez les règles de deny que vous comptez déployer. Basculez le mode shadow sur activé. Toute la politique journalise maintenant sans appliquer.
Exécutez vos vrais flux d’agent contre la passerelle avec une clé attachée à la politique en shadow. Chaque appel d’outil — inbound, response, dispatch MCP, egress — est évalué et journalisé.
Ouvrez Firewall → Events (Developer+) et filtrez sur les raisons [shadow] would …. Chacune est un appel que votre politique aurait refusé en production. Confirmez que chaque entrée est un appel que vous voulez refuser — et que rien de légitime n’est sur la liste.
Une fois que la liste des would-block est propre, désactivez le mode shadow. Le tout prochain appel correspondant est appliqué pour de vrai — aucun autre changement.
Associez le mode shadow au mode observe (un réglage d’espace de travail) pour la couverture, pas seulement la correction. Le mode observe journalise chaque appel d’outil qui se résout à aucune politique comme une lacune, peuplant la vue Discovered tools — de sorte que vous attrapiez l’outil pour lequel vous avez oublié d’écrire une règle, pas seulement les règles que vous avez mal écrites. Voir modes d’application.

​
4. Simulez une posture plus serrée avant de vous engager

Le troisième mouvement de red team est le moins cher : avant d’appliquer un niveau d’autonomie plus strict, simulez-le. Le simulateur prévisualise ce qu’appliquer tight (ou tout niveau) changerait contre le trafic récent de votre espace de travail — combien d’appels basculeraient en deny — sans écrire une seule ligne de politique. 
curl "https://api.orcarouter.ai/api/workspace/firewall/simulate?level=tight" \
  -H "Authorization: Bearer <your-session-token>" \
  -H "X-Workspace-Id: <workspace-id>"
Lire le simulateur est ouvert à tout Member. Utilisez-le pour répondre à « mon agent est-il prêt pour tight ? » avant le lancement : si l’aperçu montre un mur de refus potentiels sur des appels dont votre agent dépend, vous avez des règles à assouplir avant le go-live, pas un incident après.
Simulate est en aperçu seulement — il ne mute jamais vos politiques. Appliquer un niveau d’autonomie est une action distincte, Developer+, et c’est une transaction avec annulation en un clic si le résultat en direct vous surprend quand même.

​
5. La checklist de red-team pré-lancement

Mettez les trois passes ensemble et vous avez une porte de lancement :
PasseOutilVert quand
Politique de contenuGuardrail Eval vs corpus attaque + béninRappel élevé sur les attaques, aucun block sur le bénin
Politique d’actionFirewall mode shadow vs trafic de répétitionChaque [shadow] would … est intentionnel
CouvertureMode observe + Discovered toolsAucun outil surprenant n’est dans une lacune de couverture
PostureSimulate le niveau d’autonomie cibleL’aperçu correspond à ce que vous attendez
Passez les quatre au vert, puis appliquez : désactivez le mode shadow et appliquez votre niveau d’autonomie. Parce que chaque liaison vit sur la clé dans la passerelle, le passage du dry-run au direct est un changement de config, pas un déploiement — votre agent continue d’appeler https://api.orcarouter.ai/v1/... exactement comme avant.
Le masquage au stade output et le scan de réponse en direct mûrissent encore — une exécution d’eval prouve la logique d’une règle dans la sandbox, mais confirmez votre combinaison spécifique stage et streaming contre les notes guardrail avant d’en dépendre en production.

​
6. Étapes suivantes

Modes d'application

Observe → shadow → enforce, le déploiement sûr que cette recette répète.

Le référentiel Secure Agents

Ce que chaque niveau d’autonomie définit — et comment simulate le prévisualise.

Injection de prompt

La menace contre laquelle votre eval de guardrail score.

Passer en direct

Le basculement en production après que le red team passe.
Pour les moteurs complets derrière chaque passe, voir les références Guardrails et Firewall, et les menaces connexes : jailbreaks et appels d’outils dangereux.