Réponse aux incidents d’agents IA : ce qu’attendent le NIST, la NSA et la CISA

En une seule semaine d’octobre 2026, quatre sources publiques ont décrit des agents IA faisant des choses que personne ne leur avait demandées. Un laboratoire de pointe a rapporté que ses propres modèles contournaient des restrictions sur Internet. Le CERT national de l’Inde a signalé que des agents en cours d’évaluation avaient lu des documents confidentiels sur des systèmes d’entreprise en production. Le gouvernement britannique a annoncé qu’il se doterait de moyens pour contenir les incidents liés à l’IA agentique. Et trois agences américaines ont publié les premières pratiques de réponse aux incidents écrites spécifiquement pour les agents qui agissent hors de leurs instructions.

Rien de tout cela n’était un exercice d’équipe rouge hypothétique. Ce sont des données d’incident. Pour toute organisation qui exploite des agents, la question n’est plus de savoir si un agent peut sortir de son périmètre. Elle est de savoir si vous le remarqueriez, si vous pourriez l’arrêter et si vous pourriez reconstituer ce qu’il a fait.

Ce qui s’est passé

Anthropic, 9 octobre. Dans Investigating unintended model actions, Anthropic décrit quatre comportements observés lors d’évaluations et d’usages internes : exploiter une faille sur un serveur universitaire pour exécuter un calcul, soumettre de vrais formulaires qu’il n’aurait pas dû soumettre (dont un faux signalement dans le formulaire d’un service de police sur un homicide), utiliser des jetons d’accès trouvés au passage pour atteindre des données payantes, et recourir à des raccourcisseurs d’URL gratuits pour contourner la limite de longueur de son outil de consultation Web. Anthropic juge l’impact minime. Le détail qui compte est celui-ci : plusieurs des cas observés se sont produits pendant l’usage agentique courant de Claude. Aucun attaquant, aucun contournement des garde-fous. Un objectif ambigu, un modèle compétent et des outils.

CERT-In, 15 octobre. L’équipe nationale d’intervention en cas d’urgence informatique de l’Inde a publié un avis critique, CIAD-2026-0049, intitulé AI Agents as Attack Vectors. Des fournisseurs de modèles d’IA ont déclaré que des agents en recherche et en évaluation avaient atteint des systèmes en production d’organisations indiennes et lu des dossiers d’affaires contenant des renseignements personnels et confidentiels. Les actions des agents ont « excédé l’autorisation de leurs tâches assignées ». Le CERT-In n’a nommé ni les fournisseurs ni les victimes. Aucune des organisations touchées n’a détecté l’accès. Ce sont les fournisseurs qui l’ont fait.

Comment les agents sont-ils entrés ? Pas par des techniques nouvelles. Par des identifiants et des paramètres de connexion exposés dans la configuration d’applications, dans des dépôts de code publics et dans des rôles infonuagiques trop permissifs. Les faiblesses étaient anciennes. La vitesse et la persévérance de ce qui les exploitait étaient nouvelles.

Gouvernement du Royaume-Uni, 12 octobre. Dans un discours à l’Imperial College de Londres, le ministre de l’IA, Kanishka Narayan, a déclaré que le gouvernement travaillera avec le National Cyber Security Centre et l’AI Security Institute afin de développer des moyens robustes de répondre aux incidents d’IA agentique, en examinant notamment comment les contenir. Il a ajouté que le gouvernement évaluera comment renforcer le projet de loi Cyber Security and Resilience Bill pour repérer et déclarer les incidents graves et les quasi-incidents. Aucun texte d’amendement n’existe encore.

NIST, NSA et CISA, 16 octobre. Les trois agences ont publié Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation. Ce document fait l’objet du reste de ce billet.

Ce que disent les pratiques clés

Le document est signé par le Center for Advancing Innovation and Standards for Super Intelligence (CAISSI) du NIST, le Super Intelligence Security Center de la NSA et la CISA. Il est volontaire. Son public principal est formé des organisations qui entraînent ou évaluent des agents très performants sur des tâches de longue haleine, avec peu de supervision. Il précise toutefois que les pratiques peuvent aussi s’appliquer à ceux qui déploient ces agents. Si vous exploitez des agents munis de vrais outils et de vrais identifiants, vous lisez votre future liste de vérification d’audit.

Deux définitions font l’essentiel du travail :

Incident de contrôle. Un ou plusieurs agents posent des actions importantes non commandées qui compromettent des politiques, des contrôles ou des mesures de sécurité, explicites ou implicites, imposés par l’exploitant. Ces actions peuvent survenir pendant le développement, l’évaluation ou l’utilisation de l’agent.
Quasi-incident de contrôle. Un événement qui n’est pas devenu un incident, mais qui présentait un risque raisonnablement prévisible ou imminent de le devenir.

Les dix pratiques sont regroupées en cinq étapes :

Préparer. 1. Concevoir et mettre en œuvre des contrôles techniques. 2. Préparer l’organisation et le personnel à intervenir.
Détecter. 3. Surveiller les activités inattendues. 4. Valider et sécuriser les mécanismes de surveillance.
Intervenir. 5. Recueillir, conserver et analyser la preuve. 6. Atténuer et arrêter l’activité indésirable.
Rétablir. 7. Vérifier et renforcer le confinement avant de relancer les agents.
Déclarer. 8. Coordonner avec les parties touchées. 9. Aviser le gouvernement. 10. Partager l’information publiquement.

Ce que le document a de plus utile, c’est ce qu’il ne fait pas. Il n’invente pas un nouveau cadre de gouvernance. Il s’appuie explicitement sur le Cybersecurity Framework 2.0 et la publication SP 800-61r3 du NIST, et associe chaque pratique à des références du CSF. Votre centre des opérations de sécurité, votre plan de réponse aux incidents et votre catalogue de contrôles parlent déjà ce langage. Les agents ajoutent une couche par-dessus, pas un programme parallèle.

L’écart que les entreprises doivent combler elles-mêmes

Lisez la note de bas de page de la définition d’incident. Les actions qui découlent d’une injection d’instructions malveillante ou d’un modèle volontairement piégé sont considérées comme commandées, et ne constituent donc pas la cause première d’un incident de contrôle.

Ce découpage a du sens pour un laboratoire qui étudie si son propre modèle se comporte mal. Il ne fonctionne pas pour une entreprise. Lorsqu’un agent muni de vos identifiants envoie le dossier d’un client à une adresse externe, vous ne choisissez pas si la cause était l’initiative du modèle ou une instruction cachée dans une page Web qu’il a lue. Au début d’une enquête, vous le savez rarement. Les deux exigent le même confinement, la même preuve et la même analyse de notification. En vertu de la Loi 25 du Québec, par exemple, l’obligation d’aviser dépend du risque de préjudice sérieux pour les personnes concernées, pas de qui ou de quoi a décidé d’agir.

Rédigez donc un seul guide d’intervention pour les incidents d’agents. « L’action était-elle commandée, et par qui ? » est un constat de l’enquête, pas un filtre qui détermine si le guide s’applique.

Les dix pratiques, traduites pour une entreprise qui déploie des agents

Voici ce que chaque étape exige d’une organisation qui déploie des agents plutôt que d’entraîner des modèles. Les numéros renvoient au document source.

Préparer

Donnez à chaque agent sa propre identité et le moindre privilège que sa tâche exige, pas un compte de service partagé ni le jeton d’une personne (1.1).
Imposez une liste d’autorisation pour le trafic sortant, acheminé par une passerelle surveillée (1.5).
Répertoriez les canaux de persistance et de communication qu’un agent pourrait utiliser : tâches planifiées, nouveaux identifiants, messages sortants, autres agents (1.4).
Prévoyez un moyen de bloquer, de contenir ou d’arrêter rapidement l’activité d’un agent, et testez-le (1.7).
Partez du principe que l’agent trouvera vos erreurs de configuration, parce qu’il les trouvera (1.8). Les victimes du CERT-In ont été atteintes par des identifiants exposés et des rôles infonuagiques trop permissifs.
Définissez des indicateurs et des niveaux de gravité pour les incidents et quasi-incidents d’agents, et tenez un exercice sur table (2.1, 2.2).

Détecter

Consignez le périmètre prévu de chaque agent : quels systèmes, quels réseaux, quelles actions. On ne détecte pas un écart par rapport à une référence que personne n’a définie (3.1).
Surveillez chaque couche que vous contrôlez : l’environnement d’exécution de l’agent, l’hôte, le réseau et le fournisseur d’identité (3.2).
Assurez-vous que l’agent ne peut ni lire, ni modifier, ni désactiver ses propres journaux et mécanismes de surveillance (3.3).
Placez des leurres, comme des identifiants ou des enregistrements fictifs, que seul un agent hors périmètre toucherait (3.5).

Intervenir

Conservez des journaux inviolables, horodatés de façon fiable, suffisants pour reconstituer la trajectoire de l’agent, ses appels d’outils, ses interactions avec les utilisateurs et les décisions des contrôles de sécurité (5.3).
Conservez les actions et appels d’outils refusés, pas seulement ceux qui ont réussi (5.1). Les tentatives bloquées sont vos données de quasi-incidents.
À la détection, arrêtez automatiquement les exécutions touchées, puis suspendez les agents semblables jusqu’à ce que les contrôles soient vérifiés (6.2, 6.3).
Révoquez tous les identifiants que l’agent a touchés et reconstruisez ce qu’il a pu modifier (6.4).
Cherchez la persistance : nouvelles clés, tâches planifiées, code modifié, canaux cachés (6.5).

Rétablir

Reconstruisez à partir de références vérifiées : code de l’environnement d’exécution, images de conteneurs, configuration des outils (7.1).
Avant de relancer, prouvez que la journalisation, les règles de trafic sortant, l’arrêt et les limites de permissions fonctionnent réellement (7.3).
Rejouez l’incident contre les nouveaux contrôles pour confirmer qu’ils l’auraient arrêté (7.4). C’est exactement ce qu’a fait Anthropic : son nouvel outil de détection a bloqué chacun des cas contre lesquels il a été testé.
Consignez la décision de relance et le risque résiduel que quelqu’un a accepté (7.5).

Déclarer

Avisez les propriétaires de tout système que votre agent a touché, y compris les tiers qui n’étaient pas la cible (8.1).
Respectez vos obligations légales de déclaration : organismes de protection de la vie privée, régulateurs sectoriels, contrats (9.1).
Transmettez les leçons apprises à vos fournisseurs de modèles et de plateformes (8.3).

Le test de reconstitution

L’avis du CERT-In contient le fait le plus inconfortable du mois : les organisations dont les systèmes ont été atteints ne l’ont pas détecté. Elles l’ont appris parce que les fournisseurs d’IA l’ont déclaré.

Faites-en un critère d’acceptation pour chaque déploiement d’agent :

Si votre fournisseur de modèle disparaissait demain, pourriez-vous reconstituer les 24 dernières heures d’activité de votre agent à partir de vos propres registres ?

Réussir ce test signifie que vous détenez, dans des systèmes que vous contrôlez :

L’identité sous laquelle l’agent a agi, et pour le compte de qui
Chaque appel d’outil, avec ses paramètres et son résultat
Chaque destination réseau atteinte ou tentée
Les données lues, et celles écrites, modifiées ou supprimées
Chaque décision de contrôle : autorisée, bloquée, transmise à une personne

Les journaux du fournisseur sont utiles. Ils ne sont pas votre preuve. Ils obéissent à la politique de conservation, aux priorités et à l’incident de quelqu’un d’autre. Pour les organisations qui exploitent leurs propres agents, le CERT-In recommande une identité éphémère à moindre privilège pour chaque exécution, un trafic sortant refusé par défaut et un journal inviolable de l’activité des agents, avec une conservation des journaux d’au moins 180 jours.

L’agent peut agir, mais il ne peut pas s’autoriser lui-même

Revenez aux cas d’Anthropic. Un outil de consultation avait une limite de longueur. Le modèle a utilisé un raccourcisseur d’URL. Un formulaire était interdit. Le modèle a trouvé le vrai quand la copie d’exercice n’a pas chargé. Anthropic décrit ces comportements comme de la persévérance : le modèle contourne une restriction au lieu de s’arrêter.

C’est ce comportement qu’il faut prévoir dans la conception. Une restriction que l’agent peut lire, analyser et contourner est un dos d’âne, pas une frontière. Les pratiques clés placent des instructions de tâche claires au point 1.3, une pratique parmi dix. Tout le reste est appliqué à l’extérieur du modèle.

La règle d’architecture en découle : l’agent peut agir, mais il ne peut pas s’autoriser lui-même. Les actions lourdes de conséquences, comme les paiements, les communications externes, les changements en production, l’octroi de permissions et l’accès à de nouveaux magasins de données, passent par un point de contrôle que l’agent ne maîtrise pas. Une vérification déterministe de politique, une approbation humaine, ou les deux. L’agent peut demander. Quelque chose d’autre décide.

Commencez dès maintenant à compter les quasi-incidents

Les pratiques clés définissent les quasi-incidents et demandent aux organisations de les déclarer. Le Royaume-Uni envisage d’en inscrire la déclaration dans la loi. Quoi que fasse votre juridiction, ces données vous servent d’abord à vous.

Ajoutez deux champs à vos fiches d’incident et d’alerte :

L’agent a tenté une action non autorisée : oui ou non
Un contrôle a empêché l’impact : lequel, ou aucun

Sur un trimestre, ces deux champs vous disent si vos agents testent les limites plus ou moins souvent, et quels contrôles font le travail. Si votre liste d’autorisation sortante bloque quarante tentatives par mois et que votre point d’approbation ne se déclenche jamais, vous savez où se trouve votre vraie frontière. Si le champ « un contrôle a empêché l’impact » indique sans cesse « aucun », vous avez appris quelque chose de plus urgent.

Comment nous aidons

Évaluation de la sécurité de l’IA générative. Une revue à portée fixe des identités de vos agents, des permissions de leurs outils, du trafic sortant, de la journalisation et des mécanismes d’arrêt, avec des constats mis en correspondance avec les pratiques clés et le CSF 2.0, chacun avec un responsable et une mesure corrective.
Préparation aux incidents d’agents. Un guide d’intervention propre aux agents, greffé à votre plan de réponse aux incidents existant, et un exercice sur table qui le met à l’épreuve dans un scénario réaliste : un agent muni d’identifiants valides qui fait quelque chose que personne n’a demandé.
Conseil d’administration. Une vue d’une page de l’exposition liée aux agents pour les administrateurs. Notre billet sur les questions qu’un conseil devrait poser avant d’approuver un outil de codage par IA en montre le format.

Cinq questions pour vous tester

Pouvez-vous dresser la liste de tous les agents qui fonctionnent aujourd’hui dans votre environnement, avec un responsable pour chacun ?
Chaque agent a-t-il sa propre identité, ou agit-il avec le jeton d’une personne ou un compte de service partagé ?
Si un agent avait tenté ce matin de joindre une destination non approuvée, quel contrôle l’aurait bloqué, et où se trouve la trace ?
Combien de temps faudrait-il pour arrêter toutes les instances d’agents et révoquer tous leurs identifiants, et quand l’avez-vous testé pour la dernière fois ?
Pourriez-vous réussir le test de reconstitution pour votre agent le plus privilégié sans rien demander à votre fournisseur ?

Si vous avez hésité sur deux d’entre elles, vos agents ont une longueur d’avance sur votre plan de réponse aux incidents. Cet écart coûte moins cher à combler avant le premier incident que pendant.