Runbook d'urgence : reprendre le contrôle des agents IA

Les systèmes contrôlés par des agents ont besoin d'une procédure d'urgence avant d'avoir besoin d'un nouveau réglage de permission. Lorsqu'un agent peut appeler une API, ouvrir une session SSH, modifier un déploiement ou envoyer des données à un service externe, un humain doit pouvoir interrompre le travail, retirer les autorisations et reconstituer ce qui s'est passé sous pression.

Un runbook d'urgence ne rend pas sûre une conception dangereuse. Il donne aux équipes un moyen de contenir l'incertitude avant qu'elle ne cause des dommages. La version utile tient sur une page pour les quinze premières minutes, identifie l'autorité réelle plutôt que les seuls intitulés de poste et a été testée par des personnes qui n'ont pas participé à sa rédaction.

L'autorité d'urgence doit appartenir à des rôles nommément désignés

Un runbook d'urgence ne fonctionne que s'il dit qui peut agir sans demander une autorisation supplémentaire. « L'équipe plateforme » et « la sécurité » ne sont pas des réponses à 02 h 00, surtout lorsque plusieurs personnes supposent que quelqu'un d'autre prendra la décision.

Attribuez quatre rôles, puis associez chaque rôle aux personnes actuellement responsables et à leurs remplaçants. Dans une petite équipe, une même personne peut occuper deux rôles, mais ne laissez pas une seule personne les cumuler tous.

• Le responsable de l'incident déclare le mode d'urgence, fixe l'objectif immédiat et consigne les décisions.
• Le révocateur des accès désactive la session de l'agent, son canal d'action ou les identifiants auxquels il peut accéder.
• Le propriétaire du service décide si une charge critique peut être mise en pause sans danger et valide la reprise.
• Le rapporteur tient un journal horodaté des événements et protège le dossier de preuves.

Le révocateur doit disposer d'une autorité technique avant l'incident. Il doit pouvoir désactiver le processus de l'agent concerné, supprimer l'accès au niveau du canal d'action et demander la rotation des identifiants si nécessaire. Lui donner un numéro de téléphone d'urgence sans lui donner l'accès à la console nécessaire crée un rôle purement symbolique.

Désignez deux révocateurs, un titulaire et un remplaçant, issus si possible de lignes hiérarchiques différentes. Le propriétaire du service peut s'opposer à une interruption prolongée, mais ne devrait pas pouvoir bloquer le confinement initial lorsque le responsable de l'incident estime qu'un agent actif pourrait être dangereux. Le service pourra être rétabli après compréhension de la situation. Une requête envoyée à une API externe ou une commande SSH destructive ne peut pas être annulée.

Inscrivez dans le runbook, pour chaque rôle : le nom, le remplaçant, le moyen de contact professionnel, le moyen de contact hors horaires si vous en utilisez un et les systèmes que la personne peut réellement contrôler. Révisez cette liste après chaque changement d'équipe. Une liste de contacts obsolète n'est pas un simple problème administratif. Elle pousse les intervenants à improviser au moment où ils devraient exécuter la procédure.

Séparez l'autorité de la consultation. Le service juridique, la conformité, le support client et la direction peuvent devoir être informés selon le travail concerné. Ils ne doivent pas former une file d'attente devant le confinement. Le responsable de l'incident les informe après la première action sûre, sauf obligation légale particulière.

Arrêter, révoquer et conserver sont trois actions différentes

Arrêter un processus d'agent, révoquer son autorité et conserver les preuves répondent à des problèmes différents. Les équipes les confondent souvent, puis pensent qu'un processus inactif a perdu son accès alors que ce n'est pas le cas.

L'arrêt empêche ce processus de poursuivre son travail. Il peut s'agir de terminer un processus local, de désactiver une tâche planifiée, de mettre en pause un exécuteur d'agent ou de supprimer un déclencheur de dépôt. Arrêtez d'abord le processus s'il est encore actif et si son comportement reste incertain.

La révocation retire l'autorité qui rendait l'action possible. Elle peut consister à désactiver une session d'action, retirer une identité de service, verrouiller un coffre d'accès, remplacer un jeton en amont ou bloquer une intégration précisément définie. Un agent arrêté aujourd'hui peut redémarrer demain depuis une file de reprise ou une autre machine. Son autorité ne doit pas rester disponible par inadvertance.

La conservation recueille ce dont les intervenants ont besoin avant que la reprise habituelle ne l'écrase. Enregistrez l'identité du processus, la révision source ou le contexte de l'invite lorsque cela est pertinent, le compte opérateur, les heures de début et d'arrêt, les services destinataires et la dernière action confirmée. Conservez les journaux et les instantanés de configuration selon vos règles de conservation. Ne copiez pas de secrets dans un ticket d'incident pendant la collecte des preuves.

Utilisez cette fiche de décision pendant les premières minutes :

Incident ID:
Declared by / time:
Affected agent process or session:
Immediate risk: active calls / possible credential exposure / unknown

[ ] Stop current run
[ ] Revoke agent authorization
[ ] Lock or rotate affected credential path
[ ] Preserve process identity and action records
[ ] Notify service owner

Revoker / time:
Recorder / time:
Recovery is prohibited until incident lead approves it.

La dernière ligne évite une défaillance classique. Un développeur constate que le travail de production est en pause, redémarre l'agent pour vider la file et détruit la limite nette que les intervenants venaient de créer. La reprise doit faire l'objet d'une décision distincte, car elle modifie à nouveau le risque.

N'obligez pas les intervenants à prouver un comportement malveillant avant d'agir. Une destination étrange, un circuit d'approbation défaillant, un agent qui refuse de s'arrêter ou un écart entre les actions attendues et observées suffit pour commencer par contenir. L'examen pourra ensuite distinguer un défaut, une mauvaise configuration et une attaque.

Le travail urgent a besoin d'un circuit d'approbation étroit

Le travail urgent ne peut parfois pas attendre le propriétaire habituel, mais le mot « urgent » sert souvent à contourner précisément les contrôles qui permettraient de repérer une mauvaise demande. Le runbook doit autoriser une exception limitée sans transformer chaque incident en approbation générale.

Définissez le travail urgent comme un résultat précis du service qui subirait un préjudice important s'il attendait le circuit normal. Un déploiement en attente parce que quelqu'un veut finir avant le déjeuner n'est pas urgent. Le rétablissement d'une dépendance de production défaillante peut l'être. La description doit identifier l'action exacte, la cible, le résultat attendu et la dernière heure à laquelle l'achèvement serait utile.

Utilisez cette séquence d'approbation :

1. Le demandeur indique l'impact sur le service, l'action exacte proposée, le compte ou l'environnement concerné et l'heure d'expiration.
2. Le responsable de l'incident confirme que le confinement reste en place et désigne un propriétaire du service ou un délégué pour valider le périmètre.
3. Le révocateur accorde uniquement l'autorité nécessaire à cette action, avec une expiration explicite et un approbateur consigné.
4. Le demandeur effectue le travail pendant que le rapporteur capture l'enregistrement de l'action et son résultat.
5. Le révocateur retire immédiatement l'autorité temporaire après vérification du résultat.

Le dossier d'approbation doit être complet et sans ambiguïté. N'acceptez pas « approuvé, merci de corriger » dans une conversation. Exigez une déclaration comme celle-ci :

Emergency work authorization
Request ID: IR-2025-041
Requested action: restart payment-worker deployment in production
Scope: one named deployment, no repository writes, no account changes
Reason: queue is failing and manual recovery window expires at 14:30 UTC
Approver: service owner delegate
Granting revoker: access revoker
Expires: 14:30 UTC
Result and removal time:

L'exemple n'autorise pas un intervenant à redémarrer n'importe quoi. Il montre le niveau de précision qui empêche l'élargissement du périmètre. « Restaurer la production » dissimule des dizaines d'actions possibles. Un déploiement nommé et une expiration peuvent être vérifiés.

Évitez les identifiants d'urgence permanents pour ce circuit. Les équipes apprécient l'accès d'urgence permanent parce qu'il semble rapide. Il crée aussi une cible durable de grande valeur, et finit par être utilisé pour le travail ordinaire parce qu'il est pratique. Accordez une autorité pour une action limitée, puis retirez-la.

Si aucune personne autorisée ne peut approuver une action urgente, maintenez le confinement et escaladez selon la chaîne de responsabilité. Une reprise retardée est pénible. Une reprise non autorisée qui élargit l'incident peut faire bien plus de dégâts.

Les quinze premières minutes doivent être mécaniques

Sous pression, les personnes oublient les horodatages, discutent de la terminologie et supposent qu'un collègue a effectué une action. Un runbook a besoin d'une séquence de première réponse ordonnée, utilisable même lorsque la cause reste inconnue.

À la minute zéro, la personne qui observe le problème crée un dossier d'incident et décrit le fait observable. Écrivez « le processus de l'agent a envoyé des requêtes vers un point de terminaison non reconnu » plutôt que « l'agent est compromis ». Les faits résistent mieux aux examens ultérieurs que les premières théories.

Le responsable de l'incident déclare ensuite l'un de deux états : investigation ou confinement d'urgence. L'investigation signifie que rien n'indique une autorité active dangereuse et que l'équipe peut examiner la situation sans interrompre le travail. Le confinement d'urgence signifie que l'équipe ne peut pas établir sans danger l'autorité ou les actions actuelles de l'agent. Le second état autorise le révocateur à agir.

Pendant les quinze minutes suivantes, procédez dans cet ordre :

1. Identifiez le processus ou la session active et notez son identité visible, son hôte, son propriétaire, son heure de début et sa tâche actuelle.
2. Arrêtez toute exécution supplémentaire si elle est encore active ou si un planificateur peut la relancer.
3. Révoquez l'autorité disponible pour ce processus, en commençant par le canal d'action externe aux conséquences les plus importantes.
4. Informez le propriétaire du service concerné que le confinement est actif et indiquez clairement la conséquence opérationnelle.
5. Conservez les enregistrements d'action et le contexte de configuration avant de modifier des réglages sans rapport.

Évitez tout nettoyage général pendant cette période. Ne reconstruisez pas les hôtes, ne supprimez pas les répertoires de travail, ne faites pas tourner tous les secrets de l'entreprise et ne modifiez pas les réglages de déploiement simplement parce que la situation semble alarmante. Ces actions pourront se justifier plus tard, mais elles enfouissent les preuves et créent des pannes indépendantes.

Le rapporteur doit conserver une chronologie simple au même endroit :

14:07  Observer reported unexpected outbound request from agent run A-184.
14:09  Incident lead declared emergency containment.
14:10  Revoker stopped run A-184 and disabled its action authorization.
14:12  Service owner confirmed order processing may pause.
14:14  Recorder saved action records and configuration digest.
14:18  Team began scope review. No recovery authority granted.

C'est plus utile qu'un long récit rédigé après coup. La chronologie montre ce que l'équipe savait, qui a agi et quand l'autorité a changé. Gardez les opinions et les hypothèses dans une note d'investigation distincte.

La fatigue liée aux approbations révèle un défaut de conception

Les personnes contournent les avertissements lorsque la même invite apparaît pour une opération inoffensive et une autre lourde de conséquences. La répétition des approbations ne crée pas plus d'attention. Elle apprend aux utilisateurs à cliquer sur la fiche pour que le travail continue.

Votre runbook d'urgence doit indiquer quelles actions exigent une décision humaine explicite et lesquelles peuvent se poursuivre dans le cadre de l'autorité normale. Rendez cette limite utile. Une action qui modifie l'infrastructure, atteint une nouvelle destination externe, change un compte ou utilise un identifiant en dehors du chemin de service attendu mérite plus d'attention qu'une opération de lecture restant dans un périmètre connu.

N'essayez pas de résoudre le problème avec une immense politique écrite remplie de conditions. Pendant un incident, l'intervenant a besoin de quelques choix clairs : refuser, arrêter, révoquer, accorder une action d'urgence limitée ou rétablir le fonctionnement normal. Si la procédure exige d'interpréter vingt clauses d'exception, elle échouera différemment selon chaque intervenant.

L'écran ou le dossier d'approbation doit identifier suffisamment bien l'appelant pour qu'un humain distingue une exécution attendue d'une exécution inattendue. Le seul nom du processus est une preuve faible, car les noms sont faciles à copier. Capturez l'origine du processus, l'identité de signature du code lorsque le système d'exploitation la fournit, le contexte de lancement et l'identifiant de session. L'approbateur pourra ainsi dire « c'est bien l'outil de développement attendu, lancé depuis ce chemin » plutôt que « le libellé me semble familier ».

Une recommandation souvent mauvaise veut que chaque appel sensible exige l'approbation d'une personne. Cela semble sûr parce qu'un humain intervient partout. Pourtant, lorsqu'une tâche légitime effectue de nombreux appels, l'opérateur approuve machinalement, l'agent ne peut pas terminer une maintenance limitée et l'équipe finit par désactiver le réglage. Réservez l'approbation à usage unique aux autorités qui ont une conséquence importante et utilisez l'approbation au niveau de la session uniquement lorsque l'identité de la session est claire et son périmètre acceptable.

Sallyport suit cette séparation pratique avec une barrière de coffre, une autorisation par session par défaut et une exigence facultative par clé pour demander une approbation à chaque utilisation. Cela ne remplace pas un runbook, car un humain doit toujours disposer de l'autorité nécessaire pour interrompre le travail et décider si une exception urgente est justifiée.

Les journaux doivent indiquer qui a agi et qui a approuvé

Un dossier d'incident qui dit « l'agent l'a fait » est incomplet. Les agents passent par des processus, des identités, des canaux d'action et des circuits d'approbation humains. Vos preuves doivent montrer chaque lien.

Pour chaque appel important, conservez l'identité de la session ou du processus de l'agent, l'humain ou le système qui l'a lancé, le service ou l'hôte cible, l'action demandée, l'état de l'autorisation, le résultat et une heure fiable. Pour le travail d'urgence, enregistrez à côté de l'appel l'approbateur, le révocateur, le périmètre demandé, l'expiration et l'heure de retrait.

Gardez l'enregistrement de l'approbation séparé du résultat de l'action, puis reliez-les avec un identifiant d'incident ou de demande. Cette distinction compte. Une approbation signifie que quelqu'un a autorisé une tentative limitée. Elle ne prouve pas que la tentative a réussi, qu'elle n'a touché que l'objet prévu ou qu'elle s'est arrêtée à l'expiration.

Posez ces questions pendant la revue :

• Quel processus a envoyé la demande et comment a-t-il démarré ?
• Quelle autorité a permis la demande à ce moment-là ?
• Qui a approuvé le travail d'urgence et quel périmètre exact a été approuvé ?
• Le résultat correspondait-il à ce périmètre ?
• Un réviseur indépendant peut-il détecter des enregistrements modifiés ou manquants ?

La publication spéciale 800-61 révision 2 du NIST, Computer Security Incident Handling Guide, considère la préparation, la détection et l'analyse, le confinement, l'éradication et la reprise ainsi que les activités post-incident comme un ensemble lié. Ses conseils sur la documentation et la conservation des données d'incident restent utiles, mais les opérations d'agents ajoutent un détail souvent absent des anciens runbooks : il faut conserver la trace de l'autorité machine déléguée, pas seulement celle des connexions humaines.

Ne confondez pas les journaux applicatifs ordinaires avec une piste d'audit. Les journaux applicatifs peuvent omettre le contexte d'autorisation, permettre de vastes modifications administratives ou disparaître lors de la reconstruction d'une machine. Conservez-les, mais documentez ce que chaque enregistrement peut et ne peut pas prouver.

Pour les systèmes qui maintiennent une chaîne d'audit cryptographique, faites de la vérification un élément de l'exercice. Sallyport permet une vérification hors ligne avec sp audit verify, afin qu'un réviseur puisse contrôler son journal d'audit chiffré et chaîné par hachage sans avoir besoin de la clé du coffre. Exécutez cette commande sur une copie du dossier de preuves pendant la répétition, et non pour la première fois lorsqu'un responsable d'incident attend une réponse.

La reprise doit regagner son autorité

Rétablir le service ne revient pas à clore l'incident. Une équipe ne doit restaurer que l'autorité qu'elle peut expliquer, par étapes assez petites pour qu'une récidive ait une limite visible.

Avant la reprise, le responsable de l'incident doit obtenir trois réponses : qu'est-ce qui a motivé le confinement, quelle autorité a été exposée ou utilisée et quel contrôle empêche désormais une répétition. La cause complète peut rester inconnue dans l'immédiat. Il faut tout de même avoir suffisamment confiance pour expliquer pourquoi la première action rétablie est sûre.

Rétablissez le service par étapes limitées. Commencez si possible par une validation en lecture seule, puis une seule action connue et enfin une courte exécution surveillée. Ne réactivez pas tous les agents, toutes les intégrations et tous les identifiants parce qu'un service a récupéré. Conservez la limite de l'incident jusqu'à ce que le propriétaire du service et le responsable de l'incident conviennent que le chemin concerné est compris.

Utilisez une autorisation de reprise différente de l'approbation du travail urgent. L'approbation d'urgence permet une action nécessaire malgré l'incident. L'approbation de reprise confirme que l'autorité normale peut revenir après le confinement. Conservez un enregistrement distinct :

Recovery authorization
Incident ID:
Cause or remaining uncertainty:
Authority to restore:
Validation performed:
Monitoring owner and review time:
Approved by incident lead and service owner:

L'expiration compte ici aussi. Si une autorisation de reprise temporaire reste disponible après un test réussi, elle devient un accès permanent non documenté. Le révocateur doit confirmer son retrait dans le dossier de reprise.

La rotation des identifiants doit relever du jugement, pas du cérémonial. Faites tourner un identifiant lorsqu'il a pu atteindre un processus, une destination, un dépôt, un journal ou une personne non fiable, ou lorsque vous ne pouvez pas établir sa limite d'utilisation. Ne prétendez pas que la rotation a résolu l'incident si un agent peut encore obtenir le nouvel identifiant par le même chemin dangereux. Réparez d'abord ce chemin.

La revue post-incident doit produire des modifications, pas seulement des constats. Remplacez « la communication manquait de clarté » par « le rapporteur utilisera le modèle de chronologie et la fiche du propriétaire du service indiquera un remplaçant ». Remplacez « l'accès était difficile » par la permission manquante exacte, le responsable qui l'accordera et la date du prochain exercice.

Les exercices révèlent les éléments dont personne n'est responsable

Un runbook qui n'a jamais été exercé est une proposition. Sa première utilisation réelle révélera des contacts obsolètes, une autorité manquante et des désaccords sur la personne autorisée à relancer le travail. Un exercice transforme ces inconnues en défauts réparables lorsque les enjeux restent faibles.

Commencez par un exercice sur table, puis réalisez un exercice technique contrôlé. Pour l'exercice sur table, donnez aux participants un scénario court avec des informations incomplètes, par exemple un agent qui établit une connexion SSH inattendue pendant un déploiement. Demandez-leur d'exécuter l'arbre d'appels, de décider s'il faut contenir, de remplir le dossier d'approbation et d'indiquer quelles preuves ils conserveraient. Ne laissez pas l'auteur du runbook répondre à chaque question.

Pour l'exercice technique, utilisez une cible hors production ou un chemin de test explicitement isolé. Lancez un processus d'agent connu, autorisez une action inoffensive, déclenchez le confinement, vérifiez que les actions suivantes échouent, conservez les enregistrements et effectuez une reprise limitée. Chronométrez les actions, mais ne transformez pas l'exercice en concours de vitesse. Une réponse rapide qui oublie la révocation est pire qu'une réponse plus lente qui établit une limite nette.

Évaluez l'exercice avec des contrôles observables :

• L'observateur a-t-il pu joindre le responsable de l'incident et le révocateur avec les moyens documentés ?
• Le révocateur disposait-il de l'autorité nécessaire sans qu'un administrateur doive improviser un accès ?
• L'équipe a-t-elle distingué l'arrêt du processus de la suppression de son autorité ?
• Un réviseur pouvait-il relier l'approbation d'urgence à l'enregistrement de l'action correspondante ?
• L'accès temporaire a-t-il disparu à l'expiration ou à l'heure de retrait indiquée ?

Le NIST SP 800-61 recommande explicitement de tester les capacités de réponse aux incidents, pour une raison pratique : les exercices révèlent les lacunes des procédures, de la formation et des contrôles techniques. Ne limitez pas les tests à l'équipe de réponse aux incidents. Incluez les personnes qui exécutent l'agent, possèdent le service concerné et approuvent le travail urgent. C'est généralement dans leurs hypothèses que le processus se brise.

Mettez à jour le runbook immédiatement après l'exercice, tant que les noms, les retards et les instructions confuses sont encore présents à l'esprit. Planifiez ensuite le prochain exercice et attribuez chaque correction à un responsable. Si personne ne porte une correction, vous avez enregistré un défaut et choisi de ne pas le réparer.

Placez la fiche de première action là où l'échec ne peut pas être dissimulé

Le runbook complet peut se trouver dans votre système documentaire contrôlé, mais les intervenants ont besoin d'une fiche courte qui reste disponible lorsque les outils habituels sont lents ou touchés. Conservez-la dans un endroit accessible sans l'environnement de l'agent et faites en sorte qu'elle renvoie vers des contacts à jour plutôt que de recopier des informations qui changent rapidement.

La fiche doit indiquer à l'observateur qui appeler, au responsable de l'incident quand il peut déclarer le confinement, au révocateur quelle autorité retirer en premier et à tous que la reprise exige une nouvelle décision. Elle doit aussi nommer le dossier de preuves et l'endroit où le rapporteur écrit la chronologie.

Révisez la fiche chaque fois que vous modifiez les exécuteurs d'agents, les canaux d'action, les responsabilités ou les systèmes qui accordent l'accès. N'attendez pas un audit annuel. Dès qu'une équipe change la manière dont un agent atteint le monde extérieur, sa procédure d'urgence peut être devenue fictive.

Un bon exercice se termine par une liste légèrement embarrassante d'hypothèses manquées. Gardez cette liste. L'équipe qui découvre ses défaillances pendant une répétition a fait le travail nécessaire pour éviter de les découvrir pendant une panne.