Une équipe découvre un mardi matin qu'un de ses agents a, pendant la nuit, envoyé 230 emails à une liste de clients en utilisant un template incorrect. Cause possible : prompt injection, hallucination, bug logique. Que fait-on en 72 heures ?
C'est exactement la situation pour laquelle un runbook agent doit exister, écrit à froid, avant l'incident. Sans, l'équipe perd 12 à 36 heures à organiser ce qu'elle aurait dû organiser une fois pour toutes.
Voici le runbook 0-72h que j'utilise en mission, adapté au cas spécifique des agents IA.
H+0 à H+1 — Contenir
Geler l'agent immédiatement
- Actionner le kill-switch global : tous les agents de cette version sont arrêtés.
- Si pas de kill-switch global : feature flag "agents off", ou retrait de la route au niveau du load balancer.
- Confirmer dans les logs que les agents ne reçoivent plus de nouvelles requêtes.
Décision binaire qui doit pouvoir être prise par une seule personne (l'astreinte ou le RSSI), pas en comité.
Préserver les preuves
- Snapshot de la mémoire long-terme de l'agent à l'instant t.
- Export des logs d'audit complets sur les dernières 48-72h.
- Capture de l'état des outils accessibles à l'agent (qui a quoi pour l'instant).
- Identifier les sessions impactées.
Aucune action de remédiation ne doit altérer ces données avant export. La phase "containment" est par conception read-only sur les preuves.
Notifier en interne
- Astreinte sécurité.
- Responsable produit de l'agent.
- DPO si possibilité d'impact RGPD.
- Direction si impact externe potentiel ou montant en jeu significatif.
Ces quatre rôles doivent être convocables en moins d'une heure. Si vous ne savez pas qui est sur appel, le runbook a déjà échoué.
H+1 à H+6 — Comprendre
Reconstituer la séquence
À partir des logs :
- Quelle est la première session où le comportement anormal apparaît ?
- Quel est l'input qui a déclenché ce comportement (prompt utilisateur, contenu RAG, output d'outil) ?
- Quels outils ont été appelés et avec quels paramètres ?
- Quelle est la portée : combien de sessions affectées, combien d'utilisateurs, quels destinataires externes ?
Sans audit log structuré (cf. Audit log d'un agent), cette étape peut prendre plusieurs jours. Avec, c'est une affaire d'heures.
Identifier la cause probable
Quatre hypothèses à éliminer dans l'ordre :
- Bug code : régression dans la logique de l'agent, mauvais merge.
- Prompt injection : contenu non fiable qui a détourné l'agent.
- Memory poisoning : instruction empoisonnée persistée.
- Modèle qui a changé : update silencieux côté provider.
Chacune appelle une remédiation différente. Ne pas sauter cette étape — fixer la mauvaise cause garantit la récidive.
Cartographier l'impact
- Destinataires externes : combien de personnes ont reçu un email, un appel, une notification non voulue ?
- Données fuitées : quelles informations ont quitté votre périmètre ?
- Actions irréversibles : quoi a été supprimé, modifié, publié ?
- Engagements pris : l'agent a-t-il "promis" quelque chose à un client en votre nom ?
H+6 à H+24 — Remédier (partie 1)
Corriger la cause immédiate
Selon l'hypothèse confirmée :
- Bug code : patch + déploiement de la version corrigée (sans les agents pour l'instant, juste le service).
- Prompt injection : ajout de la signature de l'attaque dans le set de tests, renforcement du guardrail.
- Memory poisoning : purge des entrées contaminées, restauration depuis un snapshot antérieur si disponible.
- Modèle changé : escalade au fournisseur, choix d'épingler une version (Anthropic et OpenAI supportent maintenant le pinning par version explicite).
Préparer les communications
- Aux personnes impactées (clients, partenaires) : message factuel, ce qui s'est passé, ce que vous faites, ce que vous demandez d'eux (annuler une action, ignorer un message, etc.).
- En interne : note synthétique pour l'équipe, pour aligner les réponses des sales et du support.
- À la CNIL et/ou autorités : si données personnelles concernées, évaluation de l'obligation de notification sous 72h (RGPD article 33).
Restaurer ce qui peut l'être
- Annuler les actions réversibles (suppression de messages programmés non encore envoyés, retrait de publications).
- Communiquer aux destinataires d'emails non voulus pour leur demander de les ignorer.
- Documenter ce qui n'est pas réversible.
H+24 à H+72 — Stabiliser
Déployer une version corrigée
- Code patché, version explicite (nouvelle version d'agent).
- Tests de non-régression sur la cause identifiée.
- Red team sur le scénario rencontré + variants proches.
- Déploiement progressif (canary 5%, puis 25%, puis 100%) avec monitoring serré.
Notifications externes formelles
- CNIL si applicable (notification dans les 72h en cas de violation de données).
- Clients : courrier ou email formel avec récap de l'incident, mesures prises, points de contact.
- Partenaires assurance cyber : déclaration de sinistre si la police le couvre.
- CERT-FR ou autorité sectorielle si secteur régulé (NIS2, DORA).
Post-mortem structuré
Sous 72h, document partagé en interne :
- Chronologie détaillée.
- Cause racine confirmée.
- Impact mesuré (destinataires, données, coûts).
- Actions correctives prises.
- Actions correctives à venir (court terme, moyen terme).
- Métriques que vous allez suivre pour détecter la récurrence.
Pas un document de blâme. Un document de mémoire. Il sera précieux dans 12 mois si vous avez un incident similaire.
Les pré-requis pour que ce runbook marche
Tout ce qui précède suppose :
- Kill-switch opérationnel et testé (cf. Confinement d'un agent).
- Audit log structuré (cf. Audit log d'un agent).
- Astreinte définie : qui appelle qui, dans quel délai.
- Templates de comm : email aux clients, communiqué presse, notification CNIL — à 80% prêts d'avance.
- Procédure de notification CNIL documentée.
- Relation établie avec un avocat cyber et un négociateur (le cas échéant).
Sans ces 6 pré-requis, le runbook reste théorique. Avec, vous gérez un incident en gardant la main.
Le test à froid
Une fois par an minimum, faire un exercice tabletop d'incident agent. Pas en théorie — avec scénarios précis ("votre agent commercial a envoyé une offre de prix erronée à 50 clients") et chronométrage des décisions. C'est ce qui fait la différence entre une équipe qui a un runbook et une équipe qui peut l'exécuter sous stress.
Pour la méthode incident cyber générale, Gérer un incident en 7 étapes. Pour le confinement amont, Confinement d'un agent.