# Agents de réponse aux incidents : accès à la production sans chaos

Les agents de réponse aux incidents de production devraient d'abord enquêter et ne lancer une récupération qu'après l'approbation d'une personne pour une petite liste d'actions nommées. Cette limite est pratique, pas symbolique. Pendant une panne, un agent peut rassembler des éléments dispersés plus vite qu'un intervenant épuisé, mais il ne peut pas décider seul de modifier l'état en production.

La mauvaise conception donne à un agent un shell de production, un rôle cloud très large et une phrase dans le runbook qui dit « faites preuve de discernement ». Elle semble rapide jusqu'au jour où l'agent redémarre le mauvais groupe de workers, dimensionne un déploiement défectueux, fait tourner un identifiant dont dépend encore un service ou transforme une panne isolée en incident généralisé. Une bonne conception lui fournit une carte de diagnostic et limite suffisamment les actions de récupération pour qu'une personne puisse comprendre chacune d'elles.

## L'autorité de diagnostic et l'autorité de récupération sont deux permissions différentes

Le diagnostic demande au système ce qui s'est passé. La récupération lui demande de devenir différent. Les équipes brouillent cette distinction parce qu'une commande comme `restart` semble banale et que de nombreux tableaux de bord permettent d'inspecter et de modifier la même ressource depuis un seul écran. Traiter les deux comme une seule permission transforme un assistant d'incident utile en opérateur de production dont la responsabilité reste floue.

Les actions de diagnostic ne devraient pas modifier le comportement du service. Elles peuvent lire les métriques, interroger les journaux dans une période définie, récupérer les métadonnées de déploiement, consulter les points de contrôle de santé, comparer des versions de configuration et recueillir des informations limitées sur la base de données. Une action de diagnostic peut révéler des informations sensibles, elle a donc tout de même besoin d'un périmètre et d'un audit. Elle ne doit pas pouvoir modifier l'état de l'application.

Les actions de récupération modifient une partie du système en fonctionnement. Elles comprennent la restauration, le redémarrage, le déplacement du trafic, le dimensionnement, les changements de feature flags, la rotation d'identifiants, la relecture de files, le basculement, la réparation de bases de données et la désactivation d'une intégration. Certaines sont réversibles, mais aucune n'est inoffensive par défaut. Un redémarrage peut tuer l'unique processus qui détient un bail. Un changement d'échelle peut épuiser une dépendance partagée. La relecture d'une file peut dupliquer des messages client.

Pour classer une action, utilisez ce test : si répéter exactement la même action au même moment peut produire un résultat différent parce qu'elle modifie l'état, placez-la dans la récupération. Si elle modifie un cache, crée un ticket d'assistance, envoie un message, change une mise en sourdine d'alerte ou écrit une annotation consommée par une autre automatisation, elle modifie également l'état. Ne l'appelez pas une simple lecture sous prétexte qu'elle ne touche pas la base principale.

La norme NIST SP 800-61 Revision 2 sépare le confinement, l'éradication et la récupération de la détection et de l'analyse. Cette distinction est utile ici. Un agent peut considérablement accélérer la détection et l'analyse. Dès qu'il propose un confinement ou une récupération, une personne responsable doit choisir l'action et en accepter les conséquences. Le document ne résout pas votre modèle d'autorisation, mais ses phases d'incident empêchent une fiction dangereuse : enquêter et intervenir ne sont pas le même travail.

Un rôle en lecture seule n'est pas automatiquement sûr. Les requêtes de journaux peuvent contenir des jetons d'accès. Les attributs de trace peuvent exposer des identifiants de compte. Un point de contrôle de configuration peut renvoyer des identifiants. Intégrez la censure et les limites de champs à l'interface de diagnostic au lieu de permettre à l'agent de récupérer des artefacts bruts arbitraires. La visibilité en production a besoin de sa propre limite.

## Donnez à l'agent des questions, pas un shell de production général

Un agent travaille mieux sous pression lorsque ses outils formulent directement les questions de l'incident. Un shell général oblige l'agent à découvrir à la fois le système et la procédure sûre alors que le temps presse. Il rend aussi la vérification presque impossible, puisque `kubectl`, les CLI cloud, les clients de bases de données et SSH peuvent chacun faire bien plus que ce que demande l'incident.

Exposez des actions de diagnostic centrées sur les éléments qu'un intervenant demanderait dans les premières minutes :

- récupérer le taux d'erreur, la latence, la saturation et la disponibilité d'un service nommé sur une période donnée
- trouver le déploiement, la révision de configuration et les changements de dépendances proches de la première erreur
- rechercher dans les journaux structurés avec un ensemble de champs autorisés et un nombre maximal de résultats
- examiner l'état de santé et les événements récents d'un composant donné
- comparer un canari ou une région à un homologue connu comme sain

Chaque action doit avoir un contrat d'entrée précis. `get_service_errors(service, start, end, group_by)` indique au réviseur ce que l'agent a demandé. `run_query(text)` ne lui apprend presque rien et ouvre la porte aux analyses complètes accidentelles, aux prédicats dangereux ou à du texte de requête injecté par une invite.

Placez les limites strictes dans l'outil au lieu de demander au modèle de s'en souvenir. Un outil de métriques doit refuser une période trop large. Un outil de journaux doit limiter les enregistrements renvoyés et censurer les champs configurés avant de transmettre le résultat au modèle. Une recherche de déploiement doit accepter un identifiant d'application issu d'un inventaire connu, pas une URL arbitraire fournie par un commentaire de ticket. Ces limites réduisent les coûts et empêchent qu'un incident ne devienne une opération d'exfiltration de données.

Le catalogue d'actions suivant est volontairement sans intérêt. Dans une panne, c'est un compliment.

```yaml
incident_actions:
  diagnostics:
    - name: service_summary
      inputs: [service, start_time, end_time]
      limits: {max_window_minutes: 180}
    - name: recent_deployments
      inputs: [service, since_time]
    - name: log_sample
      inputs: [service, start_time, end_time, error_code]
      limits: {max_records: 200, redact_fields: [authorization, cookie, token]}
    - name: dependency_health
      inputs: [dependency, region]
  recovery:
    - name: rollback_release
    - name: set_traffic_weight
    - name: restart_component
    - name: disable_feature_flag
```

Ce fragment empêche une défaillance fréquente dans les outils internes : un agent supposé en lecture seule reçoit un point d'accès de requête universel parce que c'est pratique pour la première démonstration. Plus tard, quelqu'un découvre qu'il peut récupérer toutes les lignes de journal de tous les services ou appeler un chemin d'écriture caché. Les noms des outils ne créent pas la sécurité. Ce sont la validation des entrées, une liste autorisée, une sortie limitée et des identifiants incapables d'écrire qui la créent.

Ne donnez pas à un agent de diagnostic un accès SSH à la production simplement parce que SSH facilite l'inspection. L'accès au shell regroupe la lecture de fichiers, le contrôle des processus, l'accès réseau et souvent un chemin vers les identifiants. Si vous devez exposer des informations sur l'hôte, fournissez des commandes ciblées comme l'état des processus, l'utilisation du disque, certains éléments du journal ou un wrapper de commande contrôlé. Le wrapper doit refuser les pipes, les redirections, la substitution de commandes et les options arbitraires. Une instruction en langage naturel ne rend pas un shell sûr.

## Un catalogue de récupération doit être assez court pour être répété

Une personne ne peut pas approuver sérieusement un menu infini de mutations de production. Définissez un catalogue court par classe de service, avec des descriptions simples, des paramètres fixes lorsque c'est possible et un responsable désigné. Si une action de récupération ne peut pas être expliquée sur une seule fiche d'approbation, il faut la décomposer avant qu'un agent puisse la demander.

Un catalogue raisonnable peut inclure la restauration vers la version approuvée immédiatement précédente, la mise à zéro du trafic d'une révision défaillante, le redémarrage d'un composant sans état nommé, la désactivation d'un feature flag préexistant ou la mise en pause d'un consommateur nommé. Il ne devrait pas inclure « exécuter une remédiation arbitraire », du SQL libre, de vastes changements IAM ni des scripts improvisés copiés depuis une conversation avec un agent.

Pour chaque élément du catalogue, écrivez cinq faits avant que l'incident ne force la discussion :

1. Indiquez exactement ce qui change, notamment l'environnement et le périmètre de la ressource.
2. Nommez les prérequis que l'agent doit réunir, par exemple un identifiant de version confirmé ou une solution de repli saine.
3. Indiquez l'observation attendue après l'exécution et le délai maximal avant escalade.
4. Nommez l'action de restauration ou de compensation, si elle existe.
5. Désignez le rôle humain qui peut l'approuver.

Le catalogue doit limiter les paramètres. « Définir le poids du trafic » est trop large. « Mettre la révision `orders-v184` à zéro pour cent dans `eu-west` après vérification de la version stable » est une demande approuvable. La demande ne doit pas permettre au modèle de choisir une région, une révision et un pourcentage sans contraintes.

Ne faites pas passer la liste d'actions pour une liste complète. Elle doit exclure les actions qui exigent un jugement particulier. La réparation d'une migration de base, la suppression de données, la communication client, l'attribution de droits et la rotation d'identifiants impliquent souvent des informations qu'un agent d'incident générique ne peut pas déduire. Pour une action absente de la liste, le bon résultat est un refus clair accompagné des éléments déjà recueillis.

Un catalogue court rend aussi les exercices possibles. Simulez un incident et demandez à la personne désignée de distinguer une demande de mise en pause d'un consommateur d'une demande de suppression de sa file d'attente. Si la réponse dépend de la lecture du code source ou de la confiance accordée au résumé de l'agent, le texte d'approbation est faible.

## L'approbation doit lier une demande exacte à une personne et à un moment

Une approbation humaine n'est utile que si elle autorise une action précise, et non une session d'incident vague. « Approuver la remédiation pour les paiements » laisse à l'agent la possibilité de choisir une mutation après que la personne a cessé de surveiller la situation. Liez l'approbation au type d'action, à la cible, aux paramètres, à l'identifiant de l'incident, à l'identité de l'appelant et à une courte expiration.

La demande d'approbation doit afficher les éléments qui justifient l'action, tout en séparant les preuves de la mutation demandée. Les intervenants doivent voir que les erreurs ont augmenté après la version `184`, que la version précédente reste disponible et que la région sélectionnée dispose d'une capacité saine. Ils doivent aussi voir exactement ce qui se passera s'ils approuvent.

Utilisez un objet de demande avec des champs immuables et refusez l'exécution si un champ approuvé change :

```json
{
  "incident_id": "inc-2025-041",
  "action": "rollback_release",
  "target": {"service": "orders", "environment": "production", "region": "eu-west"},
  "parameters": {"from_release": "184", "to_release": "183"},
  "evidence_refs": ["metric:err-17", "deploy:184", "health:183"],
  "requested_by": {"agent_session": "sess-8f2a", "process_identity": "signed-agent-build"},
  "expires_at": "2025-03-08T14:35:00Z"
}
```

L'exécuteur doit renvoyer un résultat qui conserve l'identifiant de la demande et précise si l'action a commencé, s'est terminée, a échoué ou a expiré. Un message comme « restauration effectuée » est trop vague pour une chronologie d'incident. L'agent doit lire le résultat, puis relancer ses contrôles de diagnostic. Il ne doit pas supposer qu'une réponse API réussie a rétabli le service.

N'utilisez pas une seule approbation initiale pour toutes les actions suivantes. La fatigue liée aux approbations existe, mais une autorisation générale remplace la fatigue par l'ambiguïté. Regroupez uniquement les actions qui partagent la même cible, le même effet attendu et le même risque. Une personne peut approuver en une seule fois le retrait du trafic et la restauration d'une version si les deux sont fixés à l'avance. Cette approbation ne doit pas couvrir une modification de base, une rotation d'identifiants ou une autre région.

Exigez une nouvelle approbation lorsque l'hypothèse de l'agent change. Cela bloque une séquence fréquente : l'agent soupçonne d'abord un déploiement, obtient l'autorisation de le restaurer, puis découvre une erreur de base et décide d'exécuter une autre action avec l'ancienne autorisation. L'ancienne approbation a perdu sa validité dans les faits, même si son délai n'est pas encore écoulé.

## Les sessions d'incident évitent une autorité de production permanente

Un agent d'incident a besoin d'une identité distincte de celle de l'opérateur humain et de celle de sa transcription de discussion. Enregistrez quel exécutable ou processus distant a demandé l'accès, à quel incident il appartient, quelles actions de diagnostic il a appelées et qui a approuvé chaque demande de récupération. Sans cette séparation, l'analyse après incident devient une recherche dans de la prose plutôt qu'un compte rendu de l'autorité exercée.

Une session doit commencer par une référence d'incident, un environnement déclaré, un périmètre de diagnostic explicite et une expiration. Elle doit se terminer lorsque le processus de l'agent s'arrête, lorsque l'expiration est atteinte ou lorsqu'un opérateur la révoque. La révocation doit prendre effet avant l'action suivante, y compris les lectures. Lorsqu'un identifiant est probablement compromis ou qu'une injection d'invite est suspectée, la poursuite de l'accès en lecture peut encore aggraver les dégâts.

L'autorisation par session est un meilleur choix par défaut que le traitement de chaque appel de diagnostic comme une invite isolée. La première demande d'un nouveau processus d'agent permet à l'opérateur de vérifier son origine et la raison de sa visibilité sur la production. L'agent peut ensuite recueillir des preuves sans demander une approbation pour chaque graphique ou échantillon de journal. La récupération exige toujours une approbation propre à chaque appel.

La distinction entre l'identité de l'agent et celle de l'utilisateur compte sur les machines partagées et dans les environnements de type CI. Un compte humain peut être autorisé à répondre aux incidents, tandis qu'un processus d'agent copié ou un wrapper d'outil malveillant ne l'est pas. Lorsque l'environnement le permet, recueillez l'autorité de signature du code ou une autre identité de processus vérifiable. Le titre d'une fenêtre et un libellé fourni par l'utilisateur ne sont pas une identité.

Sallyport utilise une barrière absolue vers le coffre, une autorisation de session pour chaque nouveau processus d'agent et une option par clé pour chaque utilisation individuelle. Cette organisation convient aux incidents, car une personne peut autoriser un diagnostic limité tout en réservant les identifiants sensibles de récupération à une nouvelle décision.

Évitez de transmettre des identifiants dans le contexte de l'agent, même temporairement. Un identifiant copié dans une invite ne peut pas être repris, et l'agent peut le reproduire dans une commande, une transcription, un journal ou une requête externe. L'exécuteur doit conserver l'identifiant, effectuer l'appel API ou SSH autorisé et renvoyer uniquement le résultat nécessaire à l'enquête.

## Les enregistrements d'audit doivent expliquer l'intention et l'exécution

Les notes d'incident consignent souvent ce que les personnes pensent s'être produit. Elles consignent rarement la demande exacte faite par un agent, l'autorité qui l'a permise et le résultat renvoyé par le système en aval. Il faut les quatre. Une chronologie qui dit « l'agent a restauré orders » ne peut pas préciser si l'agent a demandé une restauration, si une personne a approuvé la version `183` ou si le système de déploiement a effectivement accepté la commande.

Conservez un événement durable pour la création de session, l'appel de diagnostic, la proposition de récupération, l'approbation ou le refus, la tentative d'exécution, le résultat, la révocation et la fin de session. Chaque événement doit comporter un horodatage, des identifiants de corrélation, l'identité du processus, le nom de l'action, la cible, les paramètres normalisés et un code de résultat. Conservez soigneusement le contenu sensible des demandes : l'audit doit garder leur sens sans devenir un autre dépôt incontrôlé de secrets.

Une chaîne de hachage rend les modifications ultérieures détectables, car chaque enregistrement intègre le hachage du précédent. Elle ne prouve pas que le collecteur a reçu chaque événement au départ. Concevez le système pour garantir ces deux propriétés. Rendez l'écriture des événements difficile à réécrire pour l'exécuteur, conservez les identifiants des demandes en amont et vérifiez périodiquement la chaîne en dehors du contrôle de l'agent.

Une commande de vérification hors ligne doit produire un résultat simple et lisible :

```text
$ sp audit verify
verified: 1842 records
first sequence: 2025-03-08T12:01:09Z
last sequence:  2025-03-08T14:42:31Z
chain: valid
```

Sallyport projette un journal de session et un journal d'activité individuel à partir d'un même journal chiffré et chaîné par hachage, et `sp audit verify` peut vérifier la chaîne sur le texte chiffré. C'est utile comme preuve d'incident, car la vérification ne nécessite pas d'ouvrir le coffre simplement pour savoir si l'historique a été modifié.

Gardez l'examen de l'audit en dehors de la boucle de l'agent actif. L'agent peut citer les identifiants des actions qu'il a enregistrées, mais le responsable de l'incident ou le réviseur doit pouvoir examiner le registre indépendamment. Sinon, un agent qui décrit mal ses actions pourrait aussi contrôler les preuves présentées à l'intervenant.

## Une restauration échouée montre pourquoi les preuves doivent précéder l'intervention

Prenons un service dont le taux d'erreur augmente peu après une version. Un agent remarque la simultanéité et propose une restauration. Un agent de production disposant de larges droits pourrait l'exécuter immédiatement. C'est rapide, mais cela peut être faux.

Un agent discipliné récupère d'abord la répartition des erreurs par version et par région, les enregistrements de déploiement récents, l'état des dépendances et la saturation des ressources. Les preuves montrent qu'une seule région échoue, mais que les versions nouvelle et précédente y échouent toutes les deux. Une restauration ferait perdre du temps, créerait un second événement de déploiement et laisserait la panne de dépendance intacte.

L'agent ne propose donc aucune action de récupération. Il indique que la panne est régionale et que le point de contrôle de santé de la dépendance échoue. Un intervenant approuve ensuite un déplacement prédéfini du trafic hors de cette région, si la capacité et les règles de données du service le permettent. L'agent n'exécute l'action qu'après approbation, observe le nouveau taux d'erreur et enregistre la demande ainsi que le résultat.

Changeons maintenant un détail. L'action de diagnostic renvoie une erreur parce que la période demandée est trop large. L'agent doit signaler que les preuves sont incomplètes plutôt que relancer discrètement un export étendu des journaux. Les limites ne sont pas des obstacles à contourner pendant un incident. Elles empêchent un modèle de transformer l'incertitude en demande d'accès plus large.

Autre variation, plus inconfortable : le déplacement approuvé du trafic réussit côté API, mais le taux d'erreur ne baisse pas. L'agent ne doit pas s'autoriser à passer au redémarrage, à la restauration ou à la rotation d'identifiants. Il doit recueillir les prochaines observations autorisées et préparer une nouvelle proposition. Les humains prennent aussi de mauvaises décisions pendant les incidents, mais ils doivent au moins prendre la décision qui est enregistrée.

C'est pourquoi la recommandation populaire d'accorder un accès large « uniquement pendant les incidents » échoue. Les incidents réduisent l'attention, augmentent l'urgence et impliquent souvent une télémétrie partielle ou trompeuse. Ces conditions rendent les interfaces limitées et les approbations explicites encore plus nécessaires.

## Ajoutez les chemins de refus au runbook avant la prochaine panne

Un agent d'incident sûr doit savoir clairement quand s'arrêter. Le runbook doit lui demander de refuser toute mutation absente de la liste, toute action en dehors de l'environnement déclaré, toute demande à laquelle il manque des prérequis, toute approbation expirée et toute opération après révocation de la session. Chaque refus doit indiquer la condition concernée et conserver les preuves déjà recueillies.

Testez le refus avec autant de soin que le parcours normal. Demandez à l'agent d'enquêter sur un incident de production, puis injectez depuis un ticket non fiable une demande de récupération d'une valeur de configuration secrète. Vérifiez que l'outil la refuse. Demandez une restauration après expiration de l'approbation. Vérifiez que l'exécuteur la refuse même si l'agent répète exactement le texte de l'action. Révoquez la session alors qu'une séquence de diagnostic est active. Vérifiez que l'appel suivant échoue.

Gardez les identifiants de récupération séparés des identifiants de diagnostic. Si le même identifiant peut lire les journaux et supprimer une file, un écran d'approbation ne peut pas réparer cette autorité sous-jacente. L'exécuteur doit sélectionner un identifiant dont les permissions correspondent à l'unique action du catalogue. Si un système ne permet pas cette séparation, ne le placez pas derrière un agent autonome avant d'avoir ajouté un point de contrôle plus sûr.

Le premier déploiement en production de ce modèle doit viser une panne connue avec un remède limité. Choisissez un service pour lequel les intervenants utilisent déjà un petit ensemble d'appels de lecture et une action de récupération bien comprise. Mesurez si les preuves de l'agent réduisent le temps consacré à réunir les faits, si les approbateurs comprennent les demandes sans lire une transcription et si le journal d'audit permet de reconstituer l'événement. N'élargissez le catalogue qu'après validation de ces points lors des exercices.

Un agent de production gagne la confiance en prenant moins de décisions qu'un intervenant humain, pas en prenant des décisions plus vastes. Confiez-lui la recherche des faits, gardez la décision humaine au moment de la mutation et rendez visible chaque passage des preuves à l'action, même une fois l'alerte terminée.