Un rapport de red team peut montrer comment un agent IA a réagi à un ensemble d’attaques connues dans une configuration testée. À lui seul, il ne peut pas autoriser l’agent pour un futur flux de production.
La sécurité d’un agent dépend de bien plus que la réponse du modèle à une instruction. L’agent peut ingérer du contenu externe et agir par l’intermédiaire d’outils dotés de permissions propres à l’environnement. Chaque nouvelle source, chaque nouvel outil ou chaque nouvelle permission modifie à la fois le chemin d’influence de l’attaquant et les conséquences d’une attaque réussie.
Le Center for AI Standards and Innovation du NIST a publié le 23 mars 2026 les résultats d’une vaste compétition de red teaming consacrée aux agents IA. L’étude a couvert plus de 250 000 tentatives menées par plus de 400 participants contre 13 modèles de pointe ; au moins une attaque a réussi contre chacun des modèles ciblés. Certaines attaques conçues pour un modèle ou un scénario se sont aussi transférées à d’autres. L’analyse du NIST présente les résultats et explique pourquoi les évaluations doivent s’adapter aux adversaires réels.
Pour une équipe de production, l’APPROBATION doit tenir compte de l’autorité actuelle du flux, de ses conditions d’exploitation et du chemin de reprise lorsqu’une protection échoue.
Un Test Réussi Répond À Une Question Étroite
Des tests statiques peuvent révéler des schémas connus d’injection d’instructions, des descriptions d’outils faibles, un comportement de recherche dangereux et des conflits d’instructions mal gérés. Ils rendent aussi visibles les régressions après un changement de modèle, d’invite ou d’intégration. Un test compare toutefois un ensemble fixe d’attaques à une configuration fixe. Il fournit une preuve pour la décision d’approbation, mais ne constitue pas cette décision.
Les conditions de production changent lorsqu’un nouveau connecteur atteint un autre système, qu’une mise à jour du modèle modifie son comportement, que le flux obtient une nouvelle action ou qu’un attaquant apprend la formulation des politiques de l’équipe.
Consignez l’autorité appliquée, les conditions qui permettent l’action et le chemin de reprise lorsqu’une protection échoue.
Tester Le Flux, Pas Seulement Le Modèle
Une évaluation utile commence par l’action que l’organisation souhaite autoriser. Identifiez-la, retracez le chemin des preuves et des outils qui y conduit, puis testez l’application des politiques, la transmission et le confinement qui l’entourent.
Prenons un flux de support capable de consulter un dossier client, de créer un ticket et de préparer une recommandation de remboursement. Chaque action comporte un risque différent. L’évaluation doit tester les instructions reçues par l’agent, les preuves qu’il voit, les outils qu’il peut appeler et les contrôles placés entre une action proposée et son exécution.
Pour chaque flux, constituez un jeu d’évaluation représentatif. Incluez des cas courants, des demandes ambiguës, des preuves manquantes ou contradictoires, des instructions malveillantes insérées dans le contenu récupéré et des cas où l’absence d’autorité impose de ne rien faire. Cette dernière catégorie est souvent plus révélatrice qu’un bon score d’exécution des tâches.
L’évaluation doit aussi examiner les transmissions : la recommandation atteint-elle la bonne personne, la demande d’approbation contient-elle assez de preuves et le système rejette-t-il un appel d’outil qui ne dispose pas des preuves ou de l’autorité requises ? Ces contrôles se trouvent hors du modèle, mais ils déterminent la sécurité du flux.
La Variation Des Attaques Compte Plus Qu’Une Longue Liste De Tests
Actualisez la suite d’évaluation lorsqu’un connecteur, une source de recherche, une invite, un modèle, un schéma d’outil ou une politique change. Le NIST indique que les adversaires adaptent leurs techniques aux cibles et aux défenses. Relancer le même ensemble d’instructions après chaque version laissera donc passer les attaques qui exploitent une nouvelle source ou un raccourci opérationnel.
Faites varier les conditions de test. Changez l’emplacement de l’instruction malveillante, l’autorité demandée, la séquence d’outils et les preuves accessibles à l’agent. Testez si une attaque peut pousser l’agent à divulguer des données, élargir une demande de permission, contourner une approbation ou provoquer une modification irréversible. Un résultat négatif sur un chemin ne prouve pas la sécurité du suivant.
Les comparaisons entre modèles restent utiles à la sélection, surtout lorsqu’elles montrent des écarts importants de résistance aux attaques. Elles ne remplacent pas l’évaluation du flux réel. Le risque de production naît de l’interaction entre un modèle précis, ses instructions, les contenus récupérés, les outils disponibles et l’autorité de décision.
Mesurer Les Contrôles Qui Limitent Les Dommages
Les équipes de sécurité concentrent souvent l’évaluation sur la capacité du modèle à suivre une instruction malveillante. Ce test est nécessaire, mais il ne constitue que la première couche. La question la plus lourde de conséquences concerne ce qui se produit après une erreur du modèle.
L’autorisation des outils et les portes de politique bloquent les actions dépourvues d’autorité. Un dossier de décision permet d’examiner une action erronée, tandis que les contrôles de confinement en limitent l’effet. Une demande d’approbation donne à une personne nommée les informations dont elle a besoin pour décider. Un agent ne doit pas recevoir un large accès aux données simplement parce qu’il sait résumer un document sans danger.
Ces contrôles permettent à l’organisation d’énoncer ce que l’agent peut faire et la réponse du flux lorsqu’il atteint une limite.
L’Évaluation Doit Continuer Après Le Déploiement
La production modifie les preuves accessibles à l’agent et les conséquences de ses actions. Traitez la suite d’évaluation comme un actif de production contrôlé, avec un responsable et des déclencheurs de changement définis.
Ajoutez les nouvelles attaques à mesure que l’équipe les découvre. Examinez les traces de l’agent après les incidents, les approbations échouées et les appels d’outils inattendus. Relancez la suite lorsqu’une modification importante du modèle, des instructions, de la source de recherche, du schéma d’outil ou de la politique affecte le périmètre de décision. Conservez les cas qui ont entraîné un changement de contrôle, car ils expliquent l’existence de cette limite.
Ce travail exige un flux limité, un responsable clairement désigné et un plan d’évaluation adapté aux conséquences de l’action. En cas d’incertitude, nous recommandons de commencer par l’aide à la décision ou un circuit d’approbation restreint. N’élargissez l’automatisation qu’après avoir établi les preuves, les contrôles de politique et le chemin de reprise nécessaires à cette autorité.
L’Approbation En Production Est Une Décision Opérationnelle
Les tests de sécurité doivent aider l’organisation à décider si un agent peut poursuivre, poursuivre sous contraintes, demander une approbation ou s’arrêter.
Le meilleur dossier d’approbation relie les scénarios testés à l’autorité permise à l’agent, à la politique qui gouverne chaque action, à la personne responsable des exceptions et à la réponse prévue en cas d’échec d’un contrôle. Les équipes d’ingénierie et de sécurité disposent alors d’une base pour faire évoluer le flux sans prétendre qu’un certificat de test fait disparaître le risque.
Vous préparez le dossier d’approbation d’un agent IA ? Planifiez une consultation.