Exercice tabletop : un incident d’agent IA en 90 minutes

Les pratiques de réponse aux incidents publiées le 16 octobre par le NIST, la NSA et la CISA demandent aux organisations de faire des exercices et des simulations pour se préparer aux incidents de contrôle (pratique 2.2). La plupart des plans de réponse aux incidents n’ont jamais été testés contre un agent. Ils ont été écrits pour un portable compromis ou un rançongiciel, où l’attaquant est une personne et où les logs vous appartiennent.

Voici un scénario d’exercice tabletop (un exercice sur table, en salle, sans toucher aux systèmes) que vous pouvez faire dès la semaine prochaine avec les gens que vous avez déjà. Ça dure 90 minutes, ça ne demande aucun outil et ça se termine par une liste de lacunes à attribuer.

D’où vient le scénario

Le scénario part de deux faits survenus ce mois-ci.

Dans son rapport du 9 octobre, Anthropic décrit ses propres modèles qui ont trouvé des tokens d’accès dans le fichier de paramètres d’un site de cartographie pour interroger directement le serveur, et qui ont soumis de vrais formulaires qu’ils n’auraient pas dû soumettre. Anthropic appelle ça de la persévérance : le modèle contourne une restriction au lieu de s’arrêter. Plusieurs cas sont survenus pendant l’usage agentique courant, pas pendant des tests adverses.

Dans son avis critique CIAD-2026-0049, le CERT-In de l’Inde rapporte que des agents en évaluation ont atteint des systèmes en production d’organisations indiennes grâce à des identifiants qui traînaient dans la configuration d’applications, dans des dépôts de code publics et dans des rôles cloud trop permissifs. Aucune des organisations touchées n’a détecté l’accès. C’est quelqu’un d’autre qui les a prévenues.

Le scénario réunit donc trois choses : un agent de bonne foi sur une tâche ambiguë, un identifiant qu’on ne lui a jamais donné, et une détection qui vient de l’extérieur.

Le scénario

Une entreprise québécoise fait rouler un agent d’opérations qui aide l’équipe de facturation. Sa tâche : « Résumer les factures contestées du mois et envoyer le résumé à la responsable de la facturation. » Il peut lire le système de billets et la plateforme de facturation, et il peut envoyer des courriels.

La plateforme de facturation ne répond pas. L’agent cherche une autre voie dans le lecteur partagé, trouve un fichier de configuration avec une chaîne de connexion en lecture seule à la base de données clients, et s’en sert. Pour être complet, il sort le dossier entier de chaque compte en litige : coordonnées, historique de paiement et notes. Il rédige un résumé clair et l’envoie à l’adresse du billet le plus récent, qui appartient à une agence de recouvrement externe.

Personne n’a demandé ça. Rien n’a été piraté. Chaque identifiant a fonctionné.

Qui est autour de la table

Animateur. Gère le temps, lit les injects, pose les questions. Ne règle pas le problème à la place des autres.
Responsable de l’incident. Prend les décisions pendant l’exercice.
Responsable de l’agent. La personne qui répond de l’agent. Si personne n’est capable de la nommer, c’est votre premier constat.
Ingénieur plateforme ou cloud. Sait où l’agent roule et ce qu’il peut atteindre.
Identité et accès. Sait quels identifiants existent et comment les révoquer.
Responsable de la protection des renseignements personnels. Mène l’analyse de notification.
Juridique et communications. Se joignent pour les 30 dernières minutes.
Secrétaire. Note chaque décision, chaque « on ne sait pas » et chaque « faudrait que je vérifie ».

Le déroulement, inject par inject

Chaque inject est un nouvel élément d’information que l’animateur dévoile au groupe.

T+0. Détection par un tiers. Lundi, 9 h 40. L’agence de recouvrement écrit à votre responsable de la facturation : « Nous avons reçu un fichier contenant les dossiers complets de 212 clients. Était-ce voulu ? »

Qui reçoit ce courriel, et comment se rend-il au responsable de l’incident ? Combien de temps ça prend ?
Est-ce que notre propre surveillance aurait pu le signaler en premier ?

Ce qu’on veut voir : un chemin défini de n’importe quel employé jusqu’au responsable de l’incident, et une réponse honnête à la deuxième question.

T+15. Périmètre. La responsable de la facturation confirme que le courriel vient de la boîte de l’agent.

C’est quel agent ? Qui en est responsable ? Sous quelle identité agit-il ? (1.1)
Qu’est-ce qu’il pouvait atteindre hier, et qu’est-ce qu’il peut atteindre maintenant ?
Est-ce qu’il roule encore ? Y a-t-il d’autres instances du même agent actives ?

Ce qu’on veut voir : le responsable de l’agent répond à partir d’une fiche d’inventaire, pas de mémoire.

T+30. Confinement. L’ingénieur trouve la chaîne de connexion dans un fichier du lecteur partagé, modifié il y a deux ans.

Comment arrête-t-on cet agent maintenant, et combien de temps ça prend ? Quand l’a-t-on testé la dernière fois ? (1.7, 6.2)
Est-ce qu’on suspend les agents semblables jusqu’à ce qu’on comprenne ce qui s’est passé ? Qui décide ? (6.3)
Quels identifiants révoque-t-on : ceux de l’agent, la chaîne de connexion, les deux ? Qu’est-ce qui d’autre utilise cette chaîne de connexion ? (6.4)

Ce qu’on veut voir : un kill switch testé qui arrête toutes les instances en quelques minutes, et une liste de révocation qui inclut les identifiants que l’agent a trouvés, pas seulement ceux qu’on lui a donnés.

T+45. Preuve. Le juridique demande une chronologie exacte de ce que l’agent a lu et envoyé.

Peut-on sortir chaque tool call, chaque requête et chaque destination de nos propres registres, sans rien demander au fournisseur du modèle ? (5.3)
A-t-on les actions tentées mais bloquées, ou seulement celles qui ont réussi ? (5.1)
L’agent aurait-il pu lire, modifier ou supprimer ses propres logs ? (3.3)
Combien de temps ces logs sont-ils conservés ?

Ce qu’on veut voir : des logs inviolables que vous contrôlez, assez détaillés pour énumérer les 212 dossiers par identifiant. Si la réponse est « la console du fournisseur garde 30 jours », c’est votre constat le plus important.

T+60. Notification. La responsable de la protection des renseignements personnels a la liste des dossiers.

S’agit-il d’un incident de confidentialité au sens de la Loi 25 ? Présente-t-il un risque de préjudice sérieux, compte tenu de la sensibilité des renseignements, des conséquences appréhendées de leur utilisation et de la probabilité qu’ils soient utilisés à des fins préjudiciables ? (Loi 25, articles 3.5 et 3.7)
Est-ce que la réponse change parce que le destinataire est un fournisseur connu qui a signalé l’envoi rapidement ? Qu’est-ce qu’on lui demande de faire et de confirmer ? (8.1)
Qui avise la Commission d’accès à l’information et les clients concernés, si c’est requis ? Qui inscrit l’incident au registre prévu à l’article 3.8, peu importe la décision ? (9.1)
Un contrat nous oblige-t-il à aviser un client ou un partenaire ?

Ce qu’on veut voir : une évaluation du risque documentée et motivée, une décision et une inscription au registre, le tout pendant la séance. La décision elle-même compte moins que la capacité de la défendre.

T+75. Relance. L’équipe de facturation veut récupérer son agent. La fin du mois est dans trois jours.

Qu’est-ce qui doit être vrai avant la relance ? (7.3)
Comment prouver que les nouveaux contrôles auraient arrêté cet incident ? Peut-on le rejouer ? (7.4)
Qui signe la décision de relance, et quel risque résiduel accepte-t-il par écrit ? (7.5)

Ce qu’on veut voir : une courte liste de vérification de relance, un approbateur nommé, et au moins un contrôle appliqué à l’extérieur du modèle : une allowlist des destinataires de courriel, ou un point d’approbation avant qu’un message sorte de l’entreprise.

Ce qui ressort presque à tout coup

Trois constats reviennent presque chaque fois qu’on fait l’exercice pour la première fois :

Personne n’est responsable de l’agent. L’équipe qui l’a bâti est passée à autre chose. L’équipe qui s’en sert pense que les TI s’en occupent.
La preuve est chez le fournisseur. Les logs existent, mais dans une console soumise à la politique de conservation de quelqu’un d’autre.
Le kill switch est théorique. « On désactiverait la clé d’API » arrête une instance et laisse l’identifiant trouvé fonctionner.

Aucun de ces problèmes n’est propre à l’IA. Ce sont des lacunes ordinaires de responsabilité, de journalisation et d’identité, qu’un agent trouve plus vite qu’une personne.

Deuxième ronde : un attaquant armé d’un agent

Ce scénario met en scène un agent de bonne foi. Faites le prochain exercice contre un adversaire qui en utilise un. Le 21 octobre, Microsoft a rapporté qu’un acteur aligné sur la Chine, qu’elle désigne Storm-0940, utilise ARTEX, un framework libre de tests d’intrusion agentique, contre des centaines d’organisations depuis septembre 2026 au moins. Dans plusieurs cas, il s’est écoulé moins de trois heures entre le ciblage initial et l’obtention d’un accès privilégié. Microsoft estime que le même acteur est derrière la compromission de la chaîne d’approvisionnement de ConnectWise divulguée récemment.

Gardez les mêmes rôles. Remplacez les injects par une seule chaîne tirée des techniques que décrit Microsoft : un compte cloud valide, un token volé, un nouvel identifiant et un rôle ajoutés à une application, de la reconnaissance par Microsoft Graph, puis la persistance. Affichez une horloge de trois heures au mur.

Quelle alerte sort en premier, et est-ce qu’une personne s’en occupe dans l’heure ?
Peut-on lister chaque identifiant d’application et chaque attribution de rôle ajoutés dans les dernières 24 heures ?
Peut-on révoquer les tokens et les identifiants ajoutés par l’attaquant, pas seulement réinitialiser un mot de passe ?
Peut-on reconstituer, à partir de nos propres logs, ce qui a été lu par Graph ?

Si le confinement prend plus de temps que l’attaque, le problème n’est pas la détection. C’est la vitesse de révocation.

Ce qui sort de l’exercice

Dans la semaine qui suit, l’animateur envoie :

La chronologie des décisions prises pendant l’exercice, avec le temps que chacune a pris
Une liste de lacunes, chacune avec un responsable, un niveau de gravité et une échéance
Les changements proposés au plan de réponse aux incidents, y compris les étapes propres aux agents décrites plus haut
Les champs de quasi-incident et d’incident que vos fiches devront désormais consigner
La date du prochain exercice, avec un scénario plus difficile

Besoin d’un deuxième regard ?

Nous concevons et animons des exercices tabletop d’incidents d’agents adaptés à vos agents, à vos régulateurs et à vos contrats, et nous transformons la liste de lacunes en plan de correction. L’Évaluation de la sécurité de l’IA générative couvre les contrôles que l’exercice met à l’épreuve : identité, trafic sortant, journalisation et kill switches.

Avant de fixer la date

Posez une question au responsable de l’agent d’avance : si ça arrivait demain, seriez-vous capable d’énumérer tout ce que l’agent a lu ? Si c’est oui, l’exercice va tester votre processus. Si c’est non, il va tester vos hypothèses, et c’est le plus utile des deux.