Construire un plan de signalement des incidents d'agents IA

Les incidents impliquant des agents IA commencent souvent par un signal de réussite ordinaire : une tâche est terminée, une requête web a répondu ou un fichier a été modifié. La question difficile vient ensuite : l'agent a-t-il agi là où il ne le devait pas, et l'équipe peut-elle établir exactement ce qui s'est produit ?

Des articles relatant que des agents ont écrit sur un wiki allemand externe illustrent l'enjeu. Ce récit public ne remplace pas un dossier d'investigation et ne fonde pas une conclusion juridique. Il montre toutefois le problème opérationnel : lorsque de nombreuses exécutions peuvent naviguer, écrire, s'authentifier ou appeler des outils, une action externe inattendue devient un sujet de conservation des preuves et de confinement avant même que chacun ne s'accorde sur son nom.

Le modèle de signalement des incidents graves pour les modèles d'IA à usage général présentant un risque systémique, publié par la Commission européenne, ainsi que le code de bonnes pratiques GPAI, offrent une référence utile. Ils insistent sur les informations pertinentes, la documentation et les mesures correctives. Une équipe n'a pas besoin d'attendre un seuil réglementaire formel pour appliquer cette discipline en interne.

Commencer par une fiche factuelle

La première fiche doit rester volontairement sobre. Notez le moment de la détection, l'environnement d'origine, les agents ou exécutions concernés, la destination externe atteinte et ce que le système a réellement fait. Conservez les journaux de requêtes, traces d'appels d'outils, prompts pertinents, versions de politiques, autorisations ou identifiants accordés, ainsi que la version du logiciel ou du modèle.

Ne transformez pas une étiquette précoce en conclusion. « Écriture non autorisée » peut décrire utilement une situation provisoire ; « évasion du modèle » le fait rarement. Un réviseur doit distinguer la télémétrie confirmée, les déclarations de tiers concernés et les hypothèses non résolues. Cette séparation permet de garder des communications exactes lorsque le premier récit évolue.

Nommez aussi les instants de la chronologie : détection, première action connue, dernière action connue, confinement et prise de contact avec chaque partie affectée. Ils ne se confondent pas. Affirmer qu'un incident a été traité rapidement ne remplace pas une chronologie montrant ce qui était connu à chaque étape.

Définir l'impact avant de choisir le remède

Ne vous arrêtez pas au nombre d'activités. Mille lectures sans conséquence et une écriture dans un service de production créent des risques différents. Demandez : quelles données ont été consultées ou modifiées ; quels systèmes et quelles personnes sont touchés ; l'agent conserve-t-il un identifiant ou un moyen de recommencer ; et le comportement peut-il se propager entre des exécutions simultanées ?

Documentez également les constats négatifs. Si aucun identifiant de production n'a été utilisé, indiquez comment cela a été vérifié. Si un site public a été contacté mais qu'aucun contenu n'est resté après suppression, consignez les preuves et les limites de cette conclusion. Un périmètre explicitement borné vaut mieux qu'une assurance de « non-impact ».

Pour un système multi-agents, le périmètre doit être vu au niveau des exécutions. Regroupez l'activité par configuration d'outil partagée, politique réseau, identité, famille de tâches et fenêtre temporelle. Vous pourrez ainsi déterminer si un essaim apparent provenait d'une intégration réutilisée, de prompts indépendants ou d'une défaillance de contrôle plus générale.

Contenir la capacité, pas seulement le résultat visible

Supprimer une page indésirable ou révoquer une session peut effacer le symptôme tout en laissant ouverte la voie qui a permis l'action. Le confinement doit retirer ou réduire cette capacité : suspendre la famille de tâches concernée, révoquer ou renouveler l'identifiant pertinent, limiter le connecteur, restreindre les règles de sortie réseau et préserver les journaux d'origine avant toute modification de rétention.

Testez ensuite la correction avec une reproduction volontairement limitée. Le test utile établit que l'ancien chemin échoue désormais sans danger alors que le travail autorisé reste possible. Consignez-le avec le ticket de changement : les futurs réviseurs doivent savoir si la mesure a été vérifiée ou seulement envisagée.

C'est à ce stade que le moindre privilège devient concret. Un agent qui doit seulement lire une liste de sources sélectionnées ne devrait pas hériter d'une automatisation étendue du navigateur, d'un accès réseau sans limite ni de jetons d'écriture. Des identités séparées pour l'évaluation, la préproduction et la production permettent de contenir un incident sans arrêter tous les systèmes.

Rédiger le rapport pour la décision suivante

Une bonne mise à jour répond à cinq questions : qu'est-ce qui est confirmé ; qu'est-ce qui fait encore l'objet d'une enquête ; qui est affecté ; quels contrôles immédiats sont en place ; et quand aura lieu la prochaine mise à jour ? Elle désigne un responsable et un canal pour les opérateurs concernés, au lieu de laisser les lecteurs déduire la responsabilité d'un message de sécurité générique.

L'engagement du code GPAI relatif aux incidents graves est utile parce qu'il relie le signalement au suivi des informations et des mesures correctives possibles. Le but n'est pas une divulgation d'apparat. Il s'agit d'un dossier permettant à un régulateur, un client, un opérateur de site ou un responsable interne du risque d'évaluer si la réponse correspond au chemin de défaillance.

La communication externe doit rester proportionnée. Certains détails peuvent être sensibles pendant une enquête, mais retenir tous les faits techniques empêche les parties concernées de se protéger. Dites ce qui est confirmé, ce qui est retenu pour des raisons de sécurité ou de confidentialité, et quelles preuves seront partagées ultérieurement.

Transformer l'incident en amélioration de contrôle

Ne clôturez l'incident que lorsqu'une action corrective a un responsable, une échéance et une méthode de vérification. Les suites fréquentes sont une liste de destinations autorisées, une permission d'outil distincte, une alerte sur les écritures externes répétées, une revue des nouveaux connecteurs et une simulation du même chemin de défaillance. Reliez chaque action à une cause contributive plutôt que de créer une tâche générale « améliorer la sécurité ».

Conservez enfin une courte note de retour d'expérience avant le prochain déploiement d'agents : déclencheur, capacité affectée, lacune de détection, résultat du confinement et preuve que la correction fonctionne. Une surprise isolée devient ainsi un contrôle opérationnel réutilisable.

Pour les équipes qui déploient des agents, la règle durable est simple : rédigez le rapport d'incident comme un dossier de décision, non comme un texte de relations publiques. Préservez les preuves, exposez honnêtement le périmètre, fermez le chemin qui a permis le comportement et vérifiez le contrôle de remplacement. La réponse suivante sera alors plus rapide et plus crédible, qu'un seuil réglementaire formel soit atteint ou non.