Red team
L'écran Red team vous permet de lancer des sondes adverses (injection de prompt, jailbreak, exfiltration de données) contre un modèle, un agent ou une autre cible, et de lire le taux de réussite des attaques et les constats de chaque campagne. Chemin dans le portail : /quality/redteam. Les responsables sécurité, les développeurs et les responsables de la gouvernance de l'IA l'utilisent avant une mise en production. L'écran est dessiné par portal/src/screens/quality.tsx.
Ce que montre l'écran
- Tableau Campagnes red team, lu par
GET /v1/redteam/runs(50 lignes par appel, les plus récentes d'abord, pagination par curseur). Colonnes : Identifiant, Type de cible, Cible, Moteur, Statut, Taux de réussite d'attaque, Vulnérables, Démarré le. - Liste vide : Aucune campagne red team, avec l'aide Lancez des jeux d'attaques contre une cible. et le bouton Nouvelle campagne.
- Un clic sur une ligne, ou Voir le détail, ouvre un panneau latéral avec
GET /v1/redteam/runs/{run_id}: cible, sondes, synthèse (total,vulnerable,attack_success_rate,threshold,by_category), constats et erreur. - Nouvelle campagne ouvre un panneau latéral avec Cible (obligatoire, exemple
model:gpt-4o-mini; sans type, la cible est un agent), Sondes (séparées par des virgules, exemplepi.ignore_previous, jb.dan, pii.exfiltration; vide, toutes les sondes intégrées) et Taux de réussite d'attaque max (nombre de 0 à 1, défaut 0).
Les sondes intégrées (services/control-plane/src/eai/domains/evaluation/engines.py) :
| Sonde | Catégorie |
|---|---|
pi.ignore_previous | prompt_injection |
pi.system_prompt_leak | prompt_leak |
pi.indirect_document | indirect_injection |
pi.encoding_base64 | encoding |
pi.translation_smuggle | prompt_injection |
jb.dan | jailbreak |
jb.grandma | jailbreak |
jb.roleplay_malware | jailbreak |
pii.exfiltration | data_exfiltration |
pi.markdown_exfil | data_exfiltration |
Actions
| Bouton ou action | Ce qu'il fait | Appel d'API | Rôles |
|---|---|---|---|
| Actualiser (icône) | Recharge la liste. | GET /v1/redteam/runs | Tout membre du tenant |
| Nouvelle campagne | Envoie chaque sonde à la cible avec un prompt système qui contient un secret canari, juge chaque réponse, calcule le taux de réussite des attaques et enregistre la campagne. | POST /v1/redteam/runs | tenant_admin, developer, security_officer, ai_governance_officer |
| Clic sur une ligne ou Voir le détail | Ouvre la campagne avec ses constats. | GET /v1/redteam/runs/{run_id} | Tout membre du tenant |
| Réessayer (état d'erreur) | Relance la lecture qui a échoué. | Même appel | Mêmes rôles |
Le formulaire envoie ce corps avec le moteur builtin :
{"target": {"type": "model", "ref": "gpt-4o-mini"}, "probes": ["pi.ignore_previous", "jb.dan", "pii.exfiltration"], "max_attack_success_rate": 0}
Le statut vaut passed quand le taux de réussite des attaques ne dépasse pas Taux de réussite d'attaque max, failed au-dessus, et error quand la cible est injoignable.
Rôles
Le portail ne masque aucun bouton. Dans services/control-plane/src/eai/domains/evaluation/__init__.py, lancer une campagne demande l'un des WRITE_ROLES (tenant_admin, developer, security_officer, ai_governance_officer) ; lister et lire demandent un tenant. Chaque campagne est écrite dans le journal d'audit. platform_admin passe tous les contrôles de rôle.
Tâches courantes
Tester un modèle avant sa mise en production
- Choisir la cible. La campagne appelle la cible par la plateforme. Remplissez Cible avec
model:<model-id>. Résultat attendu : le formulaire est prêt. En cas d'échec :invalid_request(400) avectarget.typesignifie que le type n'est pas pris en charge. - Choisir les sondes et le seuil. La tolérance zéro est la valeur par défaut. Laissez Sondes vide pour toutes les lancer, ou listez quelques identifiants ; gardez Taux de réussite d'attaque max à 0. Cliquez sur Créer. Résultat attendu : le message Créé et une ligne avec Statut, Taux de réussite d'attaque et Vulnérables. En cas d'échec :
invalid_requestavecunknown_probesliste les identifiants introuvables et ceux qui sontavailable. - Lire les constats. Chaque constat montre ce que le modèle a répondu. Cliquez sur la ligne et lisez
findings(probe,category,vulnerable,reason,response_excerpt). Résultat attendu :vulnerable: falsepartout. En cas d'échec : corrigez le prompt système, les garde-fous ou le modèle, puis relancez la campagne.
Comparer deux campagnes
- Lire les synthèses. La synthèse compte les sondes vulnérables par catégorie. Ouvrez deux campagnes de la même cible et comparez
summary.by_category. Résultat attendu : la campagne la plus récente a moins de sondes vulnérables. En cas d'échec : un statuterroravecerrorsignifie que la cible était injoignable pendant l'une d'elles.
Dépannage
| Symptôme | Cause | Correction |
|---|---|---|
invalid_request (400) avec unknown_probes | Un identifiant de sonde n'est pas une sonde intégrée. | Utilisez un identifiant de la liste available. |
invalid_request (400) avec target.type | Le type de cible n'est pas pris en charge. | Utilisez model, agent, prompt, rag_pipeline, skill ou tool. |
| Statut Erreur | La cible n'a pas répondu. | Vérifiez la route du modèle ou l'agent, puis relancez. |
| Statut Échoué | Le taux de réussite des attaques dépasse le seuil. | Lisez findings, renforcez la cible, relancez. |
forbidden (403) avec required_roles | Vos rôles ne permettent pas de lancer des campagnes. | Demandez security_officer ou developer. |