Les testeurs adoptent des perspectives d'attaquant ou d'usage abusif pertinentes et tentent de produire un comportement inacceptable, de contourner les contrôles, d'exposer des données, d'abuser des capacités connectées ou de révéler des faiblesses dans le modèle, l'application et le processus d'exploitation. La cible peut inclure les prompts, la recherche (retrieval), le comportement du modèle, les API, les identités, les outils, l'infrastructure et la supervision humaine — pas seulement une conversation de chatbot.
Une mission utile commence par un modèle de menace, des objectifs, des règles d'engagement et des critères de succès mesurables. Les testeurs consignent des preuves reproductibles et les conditions qui ont rendu chaque résultat possible, tandis que les propriétaires priorisent les constats, améliorent les contrôles et retestent. Les méthodes peuvent inclure l'exploration manuelle, la génération automatisée de tests, les techniques d'attaque connues et des exercices par scénarios, mais les résultats exigent une interprétation experte dans le contexte métier réel du système.
Points clés
Périmètre et autorisationDéfinir les systèmes, les données, les utilisateurs, les fournisseurs, les intégrations, les actions interdites, les contacts d'escalade et les mesures de protection pour la disponibilité, la vie privée et les tiers.
Tests représentatifsCouvrir les attaques de prompt directes et indirectes, la divulgation d'informations, l'usage dangereux des outils, les défaillances d'autorisation, les hypothèses de chaîne d'approvisionnement et les dommages pertinents au niveau du modèle ou sociétaux.
Sorties utilesPréserver les prompts, les entrées, les versions du modèle et de l'application, les réponses, les traces d'outils, le comportement attendu, l'impact, la reproductibilité et les améliorations de contrôle proposées.
Rythme d'exploitationTester avant les versions importantes et après les changements de modèles, de prompts, de sources de recherche, d'outils, de permissions ou de contexte de déploiement ; suivre les constats jusqu'à la remédiation et la vérification.
Limite importanteLe red teaming IA peut découvrir des défaillances mais ne peut prouver qu'un système est sûr ou sécurisé. La couverture est finie, le comportement du modèle peut varier, et un résultat ponctuel peut ne pas représenter les versions ultérieures, les contextes ou des attaquants mieux dotés.