Cybersécurité des IA agentiques : éprouver les hypothèses avant d’automatiser la réponse

Résumer avec

Nous proposons ici les éléments d’une série à venir, qui sera constituée de cinq manœuvres d’hypothèses appliquées à la cybersécurité. La première portera sur les IA agentiques : comment réagir lorsqu’un agent de sécurité utilise ses accès légitimes pour masquer des alertes ? L’enjeu sera de distinguer les causes possibles, de limiter les effets de l’incident et de déterminer quelles preuves permettent de choisir la réponse.

Introduction à une série de cinq manœuvres d’hypothèses

Jean Langlois-Berthelot et Clémence Foufa

L’agent a exécuté une action autorisée. Était-elle légitime ?

Un centre opérationnel de sécurité, ou SOC, confie à un agent IA une partie du tri des alertes. L’agent lit des rapports, rapproche des événements et propose des actions. Pour quelques cas jugés répétitifs, il peut aussi suspendre temporairement une règle de notification. Cette autonomie doit réduire le bruit et laisser les analystes travailler sur les incidents prioritaires.

Une nuit, les notifications d’un environnement critique cessent. Le journal d’administration indique une suspension effectuée par l’identité technique de l’agent. La requête respecte le format attendu et utilise une permission existante. L’analyste découvre pourtant des événements suspects dans une autre source. Le service censé aider à détecter l’attaque semble en réduire la visibilité.

Plusieurs explications sont possibles. Un rapport consulté a pu détourner le modèle par injection indirecte. Un attaquant a pu utiliser le secret du connecteur sans passer par le modèle. Une règle de regroupement a pu produire une erreur. Les premières traces montrent une opération ; elles n’établissent pas encore le mécanisme qui l’a provoquée.

Cette distinction change la réponse. Modifier le prompt ne retire pas un secret volé. Faire tourner un secret ne corrige pas une politique d’autorisation trop large. Réactiver les notifications ne garantit pas que leur suspension ne sera pas demandée de nouveau. L’enquête doit donc relier le contenu consulté, la décision proposée, l’identité utilisée et l’action exécutée.

L’OWASP identifie l’injection de prompt et les risques d’action excessive parmi les catégories de sécurité des applications fondées sur les grands modèles de langage. [1, 2] Ces catégories donnent des repères. Dans une organisation, il faut encore établir laquelle explique l’incident et quels contrôles limitent ses effets. C’est ce passage que nos manœuvres chercheront à préparer.

La fiction sensibilise ; elle ne démontre pas une réponse

La fiction documentée permet de rendre une situation lisible. Elle montre la fatigue d’une équipe, l’arrivée d’une alerte et la difficulté d’un choix. Elle peut attirer l’attention sur une dépendance technique que l’on aurait peu discutée dans une présentation classique. Cet intérêt ne lui donne pas automatiquement une portée opérationnelle.

Prise seule, elle reste un exercice de fiction. Si l’auteur écrit que l’agent a été manipulé, puis qu’une coupure résout le problème, il a organisé un dénouement. Il n’a pas établi que ce diagnostic était le seul possible ni que la mesure fonctionnerait dans un système réel. La qualité de l’histoire ne permet pas de franchir cette différence.

La FICINT associe fiction et documentation pour explorer des situations. Nous souhaitons aller au-delà du seul récit. Nos manœuvres partiront d’une question de sécurité, conserveront plusieurs explications concurrentes et feront varier les conditions. Elles devront déboucher sur des éléments que l’équipe pourra utiliser : une collecte de traces, une restriction d’accès, une condition de reprise ou un essai d’architecture.

Il ne s’agit pas de dévaloriser la littérature. Le personnage peut faire comprendre ce que le tableau de bord masque. Mais une scène bouleversante ne mesure ni la résistance d’un contrôle ni la probabilité d’une attaque. Pour préparer une décision, il faut ajouter une méthode qui accepte la contradiction, l’absence de résultat et la vérification extérieure au récit.

Écrire les explications avant de connaître la fin

Dans le cas de l’agent du SOC, une première hypothèse serait : un contenu consulté a conduit le modèle à demander la suspension des alertes. Nous devrions alors rechercher une relation entre la lecture de ce contenu, la demande d’outil et l’exécution. La présence de texte suspect ne suffirait pas : il faut établir que le chemin proposé est compatible avec les traces.

La deuxième hypothèse serait une compromission de l’identité technique. Une opération pourrait avoir été envoyée directement au service d’administration. L’absence de demande correspondante dans les traces de l’agent deviendrait un indice, à condition que ces traces soient complètes et protégées. Un trou dans la journalisation ne constitue pas une preuve de contournement.

La troisième hypothèse serait un défaut de l’automatisation : une règle trop large, une mauvaise association d’environnement ou un incident de synchronisation. Il faudrait comparer les paramètres attendus et l’objet réellement affecté. Enfin, nous conserverions l’hypothèse d’une maintenance légitime pour ne pas transformer toute suspension en attaque.

Ces explications peuvent se combiner. Une injection peut exploiter une permission trop large ; un défaut de contrôle peut amplifier les effets. La manœuvre doit distinguer le déclencheur, les conditions nécessaires et les conséquences. Tout appeler « compromission de l’IA » ferait perdre les différences qui permettent de réparer le système.

Chaque hypothèse reçoit une question qui peut la fragiliser. L’action existe-t-elle sans passage par le modèle ? Le connecteur sait-il atteindre cette règle ? Le rapport a-t-il été effectivement lu ? Un changement de configuration explique-t-il la même opération ? Une proposition qui survit à toutes les réponses parce qu’elle reste vague ne permet pas de travailler.

Faire varier les conditions sans inventer les preuves

Une première variation retire le contenu suspect tout en conservant la tâche et les droits. Si une opération comparable survient encore en essai, il faut examiner d’autres causes. Si elle ne survient plus, nous avons un résultat local à interpréter ; nous n’avons pas démontré que toute variante d’injection serait bloquée. Les versions, les entrées et les conditions de l’essai doivent être conservées.

Une deuxième variation retire la permission de suspendre les règles, tout en laissant l’agent proposer un diagnostic. Le modèle peut encore demander une action dangereuse ; le service cible devrait la refuser. Cette distinction permet d’évaluer une barrière d’autorisation indépendamment du comportement du modèle. Elle aide à savoir ce que la défense peut garantir dans le périmètre examiné.

Une troisième variation remplace l’agent par un appel direct utilisant la même identité, dans un environnement de test. Elle pose une question de frontière : les contrôles portent-ils sur le connecteur et le service cible, ou seulement sur l’interface de l’agent ? Le test doit être autorisé et limité aux objets prévus. Son résultat peut révéler une faiblesse que le réglage du modèle ne traiterait pas.

Une quatrième variation réduit le temps disponible. L’équipe peut-elle retirer un droit sans perdre les traces nécessaires ? Dispose-t-elle d’un moyen indépendant pour surveiller les événements pendant l’arrêt de l’automatisation ? Les délais deviennent des données à mesurer. Une suspension annoncée comme réversible peut rester dangereuse si la réactivation exige un accès que l’équipe n’a plus.

Enfin, une variation retire l’intention hostile. Si une mauvaise règle de maintenance provoque le même silence, certaines protections restent nécessaires : limiter la portée d’une suspension, conserver les événements bruts et surveiller l’arrêt des notifications. La lutte contre l’attaquant et la maîtrise des effets de l’automatisation se rejoignent alors sur des exigences vérifiables.

Ce que le SOC doit conserver pour décider

Une manœuvre doit faire travailler les preuves. Le texte présenté au modèle, les demandes d’outils, les décisions du moteur d’autorisation et les journaux des services cibles décrivent des étapes différentes. Les rapprocher suppose des identifiants de corrélation et des horodatages suffisamment fiables. Si l’un manque, le compte rendu indique ce que cette absence empêche de conclure.

L’indépendance des sources est également importante. Deux écrans alimentés par le même composant ne constituent pas deux observations indépendantes. Dans notre cas, une source de télémétrie séparée peut révéler que les événements continuent alors que les notifications disparaissent. Cette observation oriente l’analyse vers le traitement des alertes plutôt que vers une disparition de l’activité suspecte.

Le NIST a publié en avril 2025 une nouvelle révision de ses recommandations de réponse à incident, en reliant préparation, détection, réponse et récupération à la gestion du risque. [3] Notre proposition se situe dans ce travail de préparation. Elle ne remplace pas les procédures de l’équipe ; elle permet d’en examiner certaines hypothèses avant qu’une crise ne les rende coûteuses.

Le résultat attendu doit être utilisable. Par exemple : vérifier qu’un agent ne peut pas altérer la source de preuves utilisée pour surveiller ses actions ; mesurer le délai réel de retrait d’un droit ; préparer une reprise dans laquelle le contenu suspect ne sera pas réintroduit. Chaque résultat doit préciser un responsable, une condition de réalisation et une observation attendue.

L’architecture zero trust fournit un autre repère : une identité reconnue et une autorisation sont deux fonctions distinctes. [4] Pour un agent, nous devons ajouter le lien avec la mission. Une action techniquement permise peut rester injustifiée dans le contexte de l’incident traité. La manœuvre doit rendre cette différence visible sans prétendre qu’un score global de confiance pourrait la résoudre.

Cinq analyses, des terrains différents

La première manœuvre examinera donc la sécurité d’un agent de SOC. Les suivantes pourront porter sur une mise à jour compromise, des accès persistants après un vol d’identité, la falsification de télémétrie industrielle et une coordination entre organisations reposant sur des données suspectes. Les terrains resteront variés et chaque situation aura sa chaîne d’attaque propre.

La proposition prolonge environ un an et demi de travail commun sur l’innovation de sécurité et de défense. Jean Langlois-Berthelot assurera la coordination scientifique et méthodologique ; Clémence Foufa interviendra comme instructrice auprès des officiers stagiaires. Les restitutions pourront enrichir les exercices. Les textes présentés ne supposeront pas que ces résultats ont déjà été obtenus.

Le critère de réussite est simple : à la fin, le lecteur doit savoir quelle hypothèse il retient provisoirement, quel fait pourrait la contredire et quelle mesure reste justifiée pendant l’enquête. La fiction donnera une présence aux personnes et aux conséquences. La manœuvre devra donner à l’équipe un travail précis pour préparer sa réponse cyber.