Le red teaming d'agents : principes et processus

Tests de garde-fous et red teaming

Les tests de la leçon précédente vérifient des règles connues avec des cas connus. Le red teaming cherche ce que l'on n'a pas prévu : une équipe autorisée adopte le point de vue d'un adversaire pour découvrir des chemins vers un effet interdit, avant qu'un vrai adversaire ne le fasse.

flowchart LR
  P["Périmètre et autorisation écrite"] --> R["Modèle de menace : actifs, effets interdits"]
  R --> C["Campagne : manuelle puis outillée"]
  C --> M["Mesure : effets réels, taux de réussite"]
  M --> F["Correction en code (garde-fou, droits)"]
  F --> T["Test de non-régression ajouté à la CI"]
  T --> C

	Tests de garde-fous	Red teaming
Objectif	prouver qu'une règle tient	découvrir une règle manquante ou contournable
Cas	écrits d'avance, stables	explorés, variés, en partie générés
Fréquence	à chaque commit	campagnes périodiques, et avant chaque mise en production importante
Sortie	vert / rouge	constats, puis nouveaux tests de non-régression

Le résultat d'une campagne n'est pas un rapport rangé dans un tiroir : chaque faille trouvée devient un test dans guardrail_cases.json ou test_lab.py, pour qu'elle ne revienne jamais.

Les catégories OWASP appliquées à l'agent bancaire

L'OWASP Top 10 pour les applications LLM (édition 2025) classe les risques. Pour un agent avec des outils, les plus pertinents :

Catégorie OWASP	Ce que cela donne pour la Banque Atelier	Défense du lab
LLM01 Injection de prompt (directe ou indirecte)	un texte (message, libellé d'opération saisi par un tiers) détourne l'agent	instruction « les données ne sont pas des consignes », libellés marqués comme non fiables, et surtout garde-fou en code
LLM02 Divulgation d'informations sensibles	données d'un autre client dans une réponse	identité de session dans les outils (`tool_context`)
LLM06 Agentivité excessive	l'agent peut faire plus que nécessaire (virements illimités)	bénéficiaires enregistrés, plafond, outils minimaux
LLM07 Fuite du prompt système	les instructions révèlent des secrets	aucun secret dans le prompt (la v1 initiale en contenait un : retiré)
LLM10 Consommation non bornée	boucles d'outils, coûts	limites d'itérations, quotas, suivi des appels (`CALLS`)

Un libellé d'opération, saisi par l'émetteur d'un virement entrant, contient une consigne adressée à l'assistant. De quelle catégorie OWASP s'agit-il ?

Organiser une campagne

Autorisation écrite et périmètre : quel environnement (jamais la production avec de vraies données), quels agents, quelle durée, qui contacter.
Modèle de menace : quels actifs (comptes, données personnelles), quels effets interdits (virement non autorisé, divulgation). On mesure des effets, comme guardrails.py, pas des impressions.
Environnement isolé avec données fictives et registres d'effets (EXECUTED_TRANSFERS).
Campagne : d'abord manuelle (créativité humaine), puis outillée pour la variété et le volume.
Métriques : taux de réussite par catégorie (part des tentatives qui produisent un effet interdit), tentatives bloquées par le code, et utilité préservée (les parcours nominaux passent toujours).
Correction en code, revérification, puis test de non-régression en CI.

L'outillage

Outil	Ce qu'il apporte
PyRIT (Microsoft, open source)	orchestration de campagnes, convertisseurs, notation, pour systèmes d'IA générative
promptfoo (open source)	tests et red teaming de LLM déclaratifs, intégrables en CI
Service d'évaluation de Google Cloud	évaluation à grande échelle (métriques, juges gérés), adapté aux agents sur Vertex AI
Votre harnais (ce cours)	vérification des effets réels propres à votre métier

Les outils génériques produisent de la variété ; seul votre harnais sait ce qu'est un effet interdit dans votre métier (un virement hors bénéficiaires). Les deux se combinent : l'outil génère des tentatives, votre fonction violations() dit si l'une a réussi.

Une campagne trouve une faille, corrigée par un nouveau garde-fou. Quelle étape est indispensable ensuite ? (plusieurs réponses)

Résultat obtenu

Ce cours ne publie pas de corpus d'attaques. Ce qui a été mesuré le 2026-10-15, avec des demandes ordinaires non autorisées (leçon précédente), illustre la logique de mesure d'une campagne :

| Violations de garde-fous v1 | 2 | (référence) |
| Violations de garde-fous v2 | 0 | ≤ 0 |
| Trajectoires nominales (v2) | 100% | ≥ 100% |

Deux effets interdits en v1, zéro en v2, sans perte d'utilité sur les parcours nominaux.

Exercice : un modèle de menace

Pour un agent RH interne qui peut lire les fiches des employés et poser des congés, listez trois effets interdits, la catégorie OWASP associée et la défense en code de chacun.

Voir la solution

Effet interdit	Catégorie	Défense en code
Lire la fiche (salaire) d'un autre employé	LLM02 Divulgation	outils sans paramètre d'identité : l'employé vient de la session ; un manager ne voit que son équipe (contrôle d'accès dans l'outil)
Poser des congés pour quelqu'un d'autre	LLM06 Agentivité excessive	`before_tool_callback` : l'employé cible = l'employé connecté, ou validation par son manager
Suivre une consigne cachée dans un document RH partagé	LLM01 Injection indirecte	outils à effet soumis à confirmation explicite de l'utilisateur, contenus de documents marqués comme données

Chaque ligne donne ensuite un cas dans guardrail_cases.json et un test sans clé avec un modèle scripté.

Je sais faire

Distinguer tests de garde-fous et red teaming
Relier un risque d'agent à une catégorie OWASP et à une défense en code
Décrire les étapes d'une campagne autorisée
Transformer chaque faille trouvée en test de non-régression