Les premières 24 heures d’un incident de sécurité d’un agent IA

La plupart de ce que j’ai lu sur la sécurité des agents d’IA suit la même forme : une taxonomie des risques, une liste de principes de gouvernance et un appel à « adopter des pratiques d’IA responsables ». C’est utile pour un deck de plateau. C’est presque inutile à 2 heures du matin lorsqu’un agent autonome avec des informations d’identification en direct vient de faire quelque chose que personne n’a autorisé et que quelqu’un me demande ce qui se passe ensuite.

Je ne veux pas écrire un autre framework. Je veux expliquer ce que je ferais réellement, heure par heure, le premier jour après avoir découvert qu’un agent d’IA a été détourné, manipulé ou a simplement agi en dehors des limites prévues par quiconque.

Pourquoi l’horloge fonctionne différemment pour les agents

J’ai construit mes premiers instincts de réponse aux incidents autour d’un attaquant humain se déplaçant à vitesse humaine ou d’un logiciel malveillant exécutant un ensemble fixe d’instructions. Depuis, chaque fois que j’ai vécu un incident avec un agent, j’ai dû désapprendre une partie de cet instinct, car l’IA agentique brise les deux hypothèses à la fois.

Le propre récit d’Anthropic sur la campagne GTG-1002 en est l’illustration la plus claire que j’ai rencontrée. Un groupe parrainé par l’État chinois a manipulé Claude Code pour tenter d’infiltrer une trentaine d’organisations, et l’IA aurait effectué l’essentiel du travail tactique avec une implication humaine minimale. Quand j’ai lu cet article pour la première fois, ce qui m’a marqué n’était pas l’attribution, c’était le tempo. Il ne s’agit pas d’un e-mail de phishing resté dans une boîte de réception pendant une journée avant que quelqu’un ne clique dessus. C’est un compromis qui évolue pendant que mon équipe est encore en train d’être consultée.

Quelques mois plus tôt, des chercheurs d’Aim Security ont divulgué EchoLeak, une faille d’injection rapide sans clic dans Microsoft 365 Copilot avec un score CVSS de 9,3, le genre d’indice de gravité qui obligerait normalement mon équipe à tout abandonner. Un seul e-mail contrefait, ingéré lors d’une synthèse de routine, suffisait à déclencher l’exfiltration des données de OneDrive, SharePoint et Teams sans aucune interaction de l’utilisateur. Aucun lien vers le bac à sable. Aucun attachement pour faire exploser. Il s’agit simplement du contenu pour lequel l’agent a été conçu, ce qui correspond exactement à la classe de risque que le LLM Top 10 de l’OWASP classe désormais comme la menace numéro un à laquelle sont confrontés ces systèmes.

Et le problème du rayon de souffle n’est pas non plus hypothétique. L’analyse d’Obsidian Security de la compromission Salesloft-Drift OAuth montre comment une seule application connectée compromise s’est propagée dans des centaines d’environnements SaaS en aval. Je m’attends à ce que cette situation empire, et non s’améliore, une fois que ce sont les agents qui détiennent les jetons et enchaînent les appels d’outils entre les systèmes en notre nom.

Ce que ces incidents partagent est une caractéristique structurelle qui a repensé ma façon de fonctionner le premier jour : l’attaquant peut être un ensemble d’instructions intégrées dans un document, une réponse d’un outil empoisonné ou une mémoire manipulée, et non une personne assise derrière un clavier. Le confinement signifie révoquer une identité et couper l’accès à un outil. Cela ne signifie pas isoler un hôte, du moins pas au préalable, et j’ai dû corriger des collègues au milieu de l’incident qui ont instinctivement saisi le câble réseau.

Le manuel de jeu heure par heure

Heure 0 : Reconnaître ce que je regarde réellement

L’horloge commence à la détection, et c’est souvent dans la détection que je perds le plus de temps. Les incidents d’agent déclenchent rarement les alertes pour lesquelles mon SOC est configuré. Je recherche un volume d’appels d’outils provenant d’une identité d’agent unique qui est statistiquement anormale, d’un agent agissant en dehors de la portée de sa tâche déclarée (un agent de synthèse d’e-mails interrogeant soudainement un partage de fichiers) ou de sorties faisant référence à des instructions qu’aucun opérateur humain n’a données. À ce stade, mon travail consiste à trier et non à diagnostiquer : s’agit-il d’une session compromise, d’un identifiant partagé ou d’un vecteur systémique d’injection rapide contenu dans un document que n’importe quel agent pourrait ingérer ?

Heures 0-1 : Contenir par identité, pas par hôte

C’est là que j’ai vu les playbooks IR traditionnels se tromper le plus souvent pour les agents. Tirer sur un câble réseau ne fait rien si les dommages se sont déjà produits via un appel API à trois systèmes. Je révoque ou suspends immédiatement les informations d’identification, les clés API et les jetons OAuth de l’agent, de la même manière que je traiterais un compte de service compromis. Je tue la session active si la couche d’orchestration la prend en charge. Je gèle, mais ne supprime pas, la mémoire de l’agent et l’historique des appels d’outils, car j’en aurai besoin plus tard. Et si l’agent passe par un courtier ou une passerelle, je désactive ses outils enregistrés là-bas plutôt que de poursuivre les systèmes individuels en aval un par un.

Heures 1 à 4 : déterminez le rayon de l’explosion

Maintenant, je réponds à ce que l’agent a réellement touché. J’extrait le journal complet des appels d’outils, chaque API invoquée, chaque paramètre passé, chaque réponse reçue, et je le compare aux droits de l’agent pour voir ce qu’il pourrait atteindre par rapport à ce qu’il a atteint. Je vérifie également si les propres actions de l’agent ont créé de nouveaux artefacts en cours de route : une tâche planifiée, une règle de transfert, une nouvelle clé API, car les agents autonomes sont souvent meilleurs en termes de persistance que les personnes qui les ont construits. Si le vecteur d’entrée ressemble à une injection rapide indirecte, j’essaie d’identifier toutes les autres sessions qui ont ingéré le même contenu empoisonné. Il s’agit rarement d’un événement impliquant une seule victime.

Heures 4 à 8 : avertir avant d’être certain

Les parties prenantes juridiques, chargées de la protection de la vie privée et exécutives ont besoin d’un premier briefing bien avant que l’investigation judiciaire ne soit terminée. J’ai appris que c’est en attendant la certitude que les incidents liés à l’IA se transforment en échecs de divulgation. Je donne trois choses aux dirigeants : à quoi l’agent a pu accéder, à quoi les preuves montrent actuellement qu’il a eu accès et ce qui est encore inconnu. Je passe en boucle juridique plus tôt si l’agent a touché des données réglementées. Et je demande explicitement si d’autres agents construits à partir de la même configuration de base ou de la même intégration d’outils doivent être suspendus par mesure de précaution, puisqu’un seul modèle vulnérable peut être répliqué sur l’ensemble d’un parc d’agents avant que quiconque ne s’en aperçoive.

Heures 8-16 : Reconstruire la chaîne de décision

C’est le travail médico-légal que je trouve véritablement différent d’une violation traditionnelle. Je ne me contente pas de reconstruire ce qui s’est passé sur le disque. Je reconstruis pourquoi le modèle a décidé de le faire. Je parcours toute la chaîne d’invite et de réponse, y compris tout ce que l’agent a récupéré avant l’action anormale, et j’essaie de trouver l’instruction spécifique, visible ou cachée, qui a redirigé son comportement. Je vérifie également si le propre raisonnement de l’agent montre qu’il a reconnu l’instruction comme suspecte et a quand même procédé, ce qui indique un écart de garde-corps, plutôt que de ne jamais le signaler du tout, ce qui indique un écart de détection. Le correctif est différent selon celui que je trouve.

Heures 16-24 : Décidez de la restauration et changez d’abord quelque chose

Par défaut, je ne restaure pas un agent à sa configuration antérieure. C’est ainsi que ces incidents reviennent en une semaine. Je corrige le vecteur spécifique, nettoie le chemin d’ingestion, resserre la portée de l’outil ou ajoute une porte d’approbation pour toute classe d’action qui a été abusée. Je réémets des informations d’identification avec des droits plus restreints qu’auparavant, jamais identiques. Et j’écris le résumé de l’incident sur 24 heures alors que la chronologie est encore fraîche, car elle devient la donnée d’entrée à la fois pour l’examen post-incident et, souvent, pour une notification réglementaire ou client.

Ce que j’ai appris distingue la récupération des incidents répétés

Les cadres de risque nous disent que les agents ont besoin d’un accès avec le moindre privilège et d’une surveillance humaine. Je suis d’accord, et j’ai également constaté que cela n’est pas exploitable dès la première heure lorsque c’est moi qui suis bipé. Ce dont j’ai réellement besoin dans la salle, c’est d’un séquençage opérationnel : contenir par identité avant de contenir par hôte, geler les preuves avant de mettre à jour le correctif, notifier avant d’en être sûr et ne jamais restaurer la configuration exacte qui vient d’échouer. Chaque fois que j’ai vu une équipe gérer correctement un incident de classe EchoLeak ou GTG-1002, ce n’était pas parce qu’elle avait la meilleure taxonomie des risques sur le mur. C’était parce qu’ils avaient déjà répété les premières 24 heures avant d’en avoir besoin.

C’est, à mon avis, l’élément qui manque encore à notre industrie. Nous avons passé deux ans à rédiger des principes de gouvernance des agents. Je préfère passer l’année prochaine à faire des exercices de simulation contre la montre, car le prochain incident n’attendra pas que ma politique rattrape son retard.