# Approbateur des actions d'un agent IA : la responsabilité selon l'astreinte Un **approbateur pour les actions d'un agent IA** doit être la personne responsable du système concerné pendant l'astreinte correspondante. Ce ne devrait pas être automatiquement le développeur qui a ouvert la session de programmation. Il s'agit souvent de deux personnes différentes. Les traiter comme interchangeables produit des approbations qui semblent légitimes jusqu'au jour où un appel de production tourne mal. J'ai vu ce problème se produire de manière ordinaire, sans sabotage spectaculaire. Un développeur demande à un agent d'analyser un problème de compilation. L'agent trouve un point d'accès de production associé, demande une écriture pour modifier un paramètre, et le développeur approuve parce que l'invite est apparue dans son terminal. Le responsable du service découvre ensuite le changement pendant son astreinte, sans contexte ni réponse utile à la question « qui a accepté ce risque ? » La responsabilité doit suivre le système, son état actuel et la personne qui porte le pager. Une conception efficace des approbations rend cette réalité visible avant l'exécution de l'action. ## L'initiateur de la session est rarement responsable des conséquences La personne qui démarre un agent est responsable de la demande qu'elle a saisie. Elle n'est pas automatiquement responsable de la base de données, du compte fournisseur, de la cible de déploiement ou des données client que l'agent peut toucher. Cette distinction peut sembler tatillonne jusqu'à ce qu'une tâche de programmation franchisse une limite. Un dépôt peut contenir des scripts de déploiement, des identifiants opérationnels, des outils de migration et des liens vers des systèmes maintenus par plusieurs équipes. Un agent peut suivre ces chemins plus vite qu'une personne qui connaît bien le dépôt. La familiarité de l'initiateur avec une base de code ne lui confère pas l'autorité opérationnelle sur tous les systèmes accessibles. Séparez trois rôles dans votre conception : - Le demandeur demande à l'agent d'examiner, de modifier ou de déployer quelque chose. - Le responsable du système accepte le risque opérationnel pour le service cible pendant son astreinte. - L'exécutant dispose de la capacité nécessaire pour effectuer l'appel ou la commande après autorisation. Dans une petite équipe, une seule personne peut remplir les trois rôles. Cela convient si c'est explicite. L'erreur consiste à les confondre silencieusement parce que l'agent s'exécute sur l'ordinateur d'un développeur. Cela éclaire aussi un argument fréquent : « Le développeur est responsable de son agent. » Il est responsable de le diriger et du code qu'il soumet. Le responsable d'astreinte est responsable du comportement du service, du traitement des données, des décisions de retour arrière et de l'impact client. Une demande d'autorisation doit parvenir à la personne qui peut prendre cette seconde décision. La norme NIST SP 800-53 Rev. 5, contrôle AC-2, demande la désignation de gestionnaires de comptes et de procédures de gestion des comptes. Elle ne prescrit pas d'écran d'approbation pour les agents, mais la discipline sous-jacente s'applique clairement : attribuer la responsabilité des accès plutôt que de considérer l'accès comme une propriété implicite de la personne actuellement connectée. Pour les actions d'un agent, le gestionnaire du compte pertinent est souvent le responsable actuel du service, et non l'utilisateur du poste de travail. ## La responsabilité d'un service doit inclure une limite d'astreinte Un registre de responsabilité durable nomme à la fois le service et la personne actuellement responsable. Le nom statique d'une équipe ne suffit pas à 2 h du matin, pendant un congé ou au milieu d'un incident. Pour chaque système qu'un agent peut affecter, gardez un petit registre avec quatre champs : l'équipe principale responsable, le responsable de l'astreinte active, un suppléant et une voie d'escalade. Le registre peut se trouver dans un système d'astreinte, un dépôt ou un annuaire interne. Son emplacement compte moins que sa mise à jour régulière et la capacité du système d'approbation à le consulter. Utilisez la limite de service employée par les opérateurs lorsqu'ils reçoivent une alerte. « API de paiements en production » est une cible utile. « Backend » ne l'est pas. Un nom d'équipe trop large masque des bases de données, des fournisseurs, des classifications de données et des procédures de retour arrière différents. Un enregistrement minimal peut ressembler à ceci : ```yaml service: billing-api-production active_owner: billing-oncall backup_owner: payments-duty-manager escalation: incident-commander approval_rules: read_customer_records: session change_remote_configuration: per_call production_database_write: per_call create_vendor_credentials: prohibited ``` Il ne s'agit pas d'un langage de politiques que l'agent doit interpréter. C'est une déclaration gérée par des humains qui indique qui peut prendre les décisions et quel niveau d'examen une action requiert. Elle évite un échec bien connu : une demande d'approbation arrive dans un canal d'ingénierie général, quelqu'un reconnaît le nom du dépôt, mais personne ne reconnaît le système de production qui se trouve derrière. Traitez ce registre comme une donnée opérationnelle. Une réorganisation, l'ajout d'un service géré ou un changement de rotation d'astreinte peut le rendre obsolète. Si votre routage des approbations dépend d'un tableur que seul un responsable peut modifier, vous avez créé un point de défaillance unique et silencieux. ## Le risque d'une action dépend de la cible, pas du verbe « Lire » et « écrire » sont des catégories trop grossières pour attribuer des droits d'approbation. Une lecture sur un point d'accès public d'état n'est pas comparable à une lecture qui renvoie un export client, un secret de déploiement ou la liste complète des hôtes internes. Une écriture qui crée une branche temporaire n'est pas comparable à une écriture qui modifie un paramètre de fournisseur de paiement. Classez les actions selon les conséquences d'un résultat réussi. Commencez par le système et les données cibles, puis examinez la réversibilité et le rayon d'impact. Les responsables disposent ainsi d'une base concrète pour choisir le périmètre d'approbation. Un ensemble pratique de catégories reste limité : - Les lectures opérationnelles courantes ne renvoient aucune donnée sensible et ne modifient pas l'état. - Les changements ciblés affectent une ressource connue et disposent d'une procédure de retour arrière documentée. - Les changements à fort impact affectent la configuration de production, les données client, les accès ou des engagements externes. - Les actions interdites ne doivent jamais passer par un canal d'agent autonome. Ne classez pas une action comme peu risquée parce que la méthode HTTP est GET. J'ai vu des points d'accès de diagnostic renvoyer des variables d'environnement, des liens signés et des détails opérationnels qui n'auraient jamais dû parvenir à un agent de programmation. Le responsable qui comprend le point d'accès doit le classer. De même, n'exigez pas une confirmation manuelle pour chaque vérification d'état inoffensive. Cette conception crée une fatigue d'approbation. Les personnes finissent par valider une demande courante parce qu'elles s'attendent à ce qu'elle le soit, puis approuvent l'appel qui ne l'était pas. Réservez l'approbation par appel aux identifiants et aux cibles pour lesquels chaque invocation mérite une décision réfléchie. Le texte de l'approbation doit identifier la cible concrète. « L'agent demande un accès à l'API » n'apprend rien au responsable. « Le processus de l'agent demande un PATCH sur la configuration de facturation en production à l'aide de l'identifiant billing-admin » lui donne assez d'informations pour s'arrêter et poser les bonnes questions. ## Une session délimitée n'est pas une autorisation sans limites Une approbation de session doit couvrir un seul processus d'agent identifiable pendant une durée définie, et non tous les processus futurs lancés depuis le même dépôt ou le même compte utilisateur. Cette distinction compte lorsqu'un terminal reste ouvert pendant une passation, lorsqu'un développeur redémarre un agent après avoir modifié ses instructions ou lorsqu'un processus local malveillant imite une commande familière. Une approbation liée uniquement à l'identité d'un utilisateur est trop large. Une approbation liée à un processus dépourvu d'identité claire est facile à mal interpréter. Une bonne approbation de session répond en termes simples à cinq questions : quel processus l'a demandée, qui a signé ou fourni ce processus, quel canal d'action il peut utiliser, quel périmètre de service s'applique et quand l'autorisation prend fin. La session doit se terminer lorsque le processus s'arrête. Un nouveau processus mérite une nouvelle décision. L'autorisation par session de Sallyport suit ce modèle en affichant l'autorité de signature du code du processus demandeur et en approuvant cette exécution uniquement jusqu'à sa fermeture. C'est un meilleur réglage par défaut que de faire confiance à un onglet de terminal, car un onglet de terminal ne constitue pas une limite d'identité. Gardez les identifiants à fort impact en dehors de l'autorisation de session. Une écriture dans une base de données de production ou une modification d'accès chez un fournisseur doit demander confirmation au responsable actuel à chaque utilisation, même s'il a approuvé la session de diagnostic de l'agent dix minutes plus tôt. La première approbation signifie : « Ce processus peut travailler sur ce système. » La suivante signifie : « J'accepte cette action précise, irréversible ou sensible. » Ce sont deux décisions différentes. Évitez les approbations permanentes intitulées « outils de développement ». Elles deviennent des réservoirs d'habilitations invisibles. Elles rendent aussi l'examen d'un incident pénible, car personne ne peut savoir si l'approbateur s'attendait à ce que cet agent précis utilise cette capacité. ## La passation d'astreinte doit transférer l'autorité, pas seulement l'information Un message de passation qui dit « Alex est maintenant d'astreinte » ne règle pas les approbations d'agents si les sessions et approbations d'hier continuent de fonctionner sous l'ancien responsable. Le responsable sortant doit transmettre le travail actif des agents comme il transmet une alerte partiellement atténuée. Enregistrez l'identité du processus, les services cibles, le périmètre demandé, l'expiration et les actions en attente de confirmation. Le responsable entrant doit pouvoir consulter cet enregistrement avant d'accepter l'astreinte. Utilisez cette séquence : 1. Terminez ou révoquez les sessions que le responsable sortant ne souhaite plus parrainer. 2. Dressez la liste des sessions actives qui doivent continuer, avec leur cible et leur expiration. 3. Transférez le registre des services au responsable entrant et confirmez son canal de notification. 4. Demandez au responsable entrant de prendre de nouvelles décisions pour les appels à fort impact. Ne transmettez pas une approbation générale d'une équipe à une autre simplement parce que la tâche d'ingénierie n'est pas terminée. La personne entrante peut disposer d'un contexte d'incident différent, de contraintes de maintenance différentes ou d'informations sur un problème fournisseur en cours. Son approbation doit lui appartenir. Le cas délicat est celui d'une action déjà en cours au moment de la passation. Si elle est réversible et observable, laissez-la se terminer avec l'autorisation enregistrée et rendez le résultat visible au nouveau responsable. Si elle est destructive, visible de l'extérieur ou en attente d'un second appel, arrêtez-vous à la limite et demandez une nouvelle confirmation. Quelques minutes de retard coûtent moins cher que de faire hériter à un inconnu un changement de production non examiné. ## Les incidents nécessitent une autorité plus étroite, pas une mémoire moins rigoureuse Pendant un incident, les équipes veulent naturellement aller vite. Elles réagissent souvent en accordant à un agent une autorisation large et durable pour « aider à réparer la production ». Cette autorisation survivra à l'urgence et finira par devenir une faille inexpliquée. Attribuez l'approbation au commandant de l'incident ou à la personne officiellement mandatée par ce commandant pour le système concerné. Le responsable d'astreinte habituel du service doit rester impliqué lorsque c'est possible, mais un incident nécessite un décideur unique lorsque plusieurs équipes touchent à la même dépendance. Inscrivez la référence de l'incident dans l'enregistrement d'approbation. Limitez-la au service et à l'action corrective. Fixez une expiration courte adaptée au travail, puis clôturez ou révoquez-la lorsque l'incident prend fin. Prenons le cas d'un agent chargé de réduire une file d'attente qui s'emballe. Il examine les métriques, propose un changement de configuration et demande une commande qui purge des messages. Le commandant de l'incident peut approuver un ajustement temporaire de la concurrence après avoir examiné le retour arrière. Il ne devrait pas approuver la suppression de messages au seul motif qu'elle est rapide. La demande doit préciser quelle file est concernée, quels messages seront touchés, quel chemin de récupération existe et si des clients perdront leur travail. La rapidité vient de chemins d'autorité préparés, de responsables clairs et de demandes lisibles. Elle ne vient pas du fait de transformer chaque intervenant en administrateur de production pour l'après-midi. ## Les demandes d'approbation doivent imposer une décision utile Une demande échoue lorsqu'un responsable compétent ne peut pas comprendre en quelques secondes ce qu'il approuve. Elle échoue aussi lorsqu'elle exige une analyse de sécurité nouvelle pour une action ordinaire. Elle doit exposer les points de décision que le responsable utilise déjà dans ses opérations habituelles. Incluez l'identité du demandeur, l'identité du processus de l'agent, le canal d'action, le libellé de l'identifiant, la cible, l'opération et le périmètre. Pour une commande, affichez la commande exacte et l'hôte distant. Pour un appel HTTP, affichez la méthode, l'hôte, le chemin et une description sûre du corps. N'affichez jamais le secret lui-même pour prouver que l'identifiant existe. Voici la différence entre une demande utile et une demande inutile : ```text Request: production configuration change Process: signed coding-agent process, session 8f3a Owner: billing-oncall Credential: billing-admin Action: PATCH https://api.internal.example/v1/routing/default Body: {"provider":"secondary"} Scope: one call Reason supplied: mitigate provider timeout during INC-482 ``` Une demande qui dit seulement « Autoriser l'accès à l'outil ? » pousse le responsable à approuver par réflexe. Elle ne lui indique ni la cible ni l'effet. Si vos outils ne peuvent pas fournir suffisamment de contexte pour prendre une décision, ils doivent refuser l'action jusqu'à ce que le demandeur le fournisse. Ne laissez pas un champ libre « motif » assurer la sécurité. Les agents peuvent produire à peu de frais un texte convaincant. Considérez le motif comme un contexte destiné à l'humain, tandis que le système impose la cible, l'identifiant et le périmètre de l'approbation. ## Les enregistrements d'audit doivent répondre aux questions gênantes Après un changement inattendu, on demande qui l'a approuvé, quel processus l'a effectué, quel identifiant il a utilisé, quelle cible il a atteinte et si quelqu'un a ensuite modifié l'enregistrement. Une piste d'audit incapable de répondre à toutes ces questions n'est qu'une aide au débogage. Conservez les décisions de session séparément des événements d'action individuels, mais reliez-les. L'enregistrement de session établit l'identité du processus et du responsable approbateur. L'enregistrement d'activité établit chaque appel ou commande et son résultat. Incluez les refus et les révocations. Les tentatives échouées expliquent souvent une solution de contournement ultérieure ou révèlent qu'un processus explore les limites. Rendez l'enregistrement évident à toute altération. Un journal chaîné par hachage permet de détecter les suppressions et les modifications lorsqu'une personne peut vérifier la chaîne indépendamment. Il ne transforme pas une mauvaise approbation en bonne approbation et ne remplace pas les contrôles d'accès. Il donne aux enquêteurs un moyen de vérifier que l'historique correspond toujours à la séquence enregistrée. Sallyport projette les journaux de session et d'activité depuis un journal chiffré, chaîné par hachage et aveugle à l'écriture, et `sp audit verify` peut vérifier la chaîne hors ligne sur le texte chiffré. Cette conception est utile, car le vérificateur n'a pas besoin d'accéder aux secrets opérationnels pour contrôler l'intégrité de l'enregistrement. Ne cachez pas les actions des agents dans des journaux d'application génériques. Ces journaux omettent souvent la décision humaine, sont rapidement renouvelés et mélangent un bruit sans rapport avec la piste d'événements. Conservez un enregistrement qu'un responsable d'astreinte, un réviseur sécurité et un commandant d'incident peuvent chacun lire sans reconstruire une histoire à partir de six systèmes. ## Les défaillances de responsabilité commencent généralement par une exception pratique Le schéma dangereux commence par un raccourci raisonnable. Un développeur expérimenté doit terminer une migration. Le responsable du service se trouve dans un autre fuseau horaire. Quelqu'un ajoute un groupe d'approbation général, accorde un identifiant réutilisable ou laisse une session ouverte tout le week-end. L'exception fonctionne, puis devient le processus officieux. Ensuite, l'agent reçoit une tâche plus large. Il peut atteindre davantage de cibles que ne le demandait la requête d'origine. Le développeur initial dort peut-être, le responsable a changé d'astreinte et le groupe général suppose que quelqu'un d'autre a vérifié la demande. Chaque décision prise séparément semblait défendable. Ensemble, elles ont supprimé la responsabilité. Corrigez ce problème en structurant les exceptions au lieu de les laisser informelles. Une exception doit nommer un service, un approbateur, un motif, une heure de fin et un point de contrôle. Elle doit produire un enregistrement visible. Elle ne doit pas élargir silencieusement les droits permanents d'un développeur. Résistez à la recommandation populaire qui consiste à résoudre le problème avec un moteur de règles tentaculaire. Les règles semblent séduisantes, car les équipes imaginent pouvoir y encoder chaque dépôt, branche, point d'accès, période et intitulé de poste. En pratique, personne ne peut expliquer pourquoi un appel précis a correspondu, et les règles obsolètes deviennent des autorisations que personne n'avait prévu de conserver. Commencez par un modèle de décision réduit : accès au coffre, décision de session délimitée et confirmation par appel pour les actions qui le méritent. Ce modèle force les équipes à régler le point difficile en termes simples : qui est responsable de ce système maintenant, et qu'est-il exactement prêt à autoriser ? ## Testez le modèle de responsabilité pendant une véritable passation Vous pouvez trouver la plupart des défauts de conception avant un incident sérieux en menant un exercice contrôlé. Utilisez un système hors production qui ressemble à un service doté d'une véritable rotation d'astreinte. Démarrez une session d'agent près d'une passation planifiée, demandez une lecture courante, puis demandez un changement nécessitant une confirmation individuelle. Observez les moments où les personnes hésitent. Le responsable sortant peut-il voir les sessions actives ? Le responsable entrant sait-il quel service il contrôle désormais ? La demande d'approbation identifie-t-elle le processus et la cible ? L'une ou l'autre personne peut-elle révoquer la session ? L'enregistrement d'audit affiche-t-il dans l'ordre les actions refusées, approuvées et exécutées ? N'acceptez pas « on réglerait ça dans le chat » comme réponse. Le chat est utile pour la coordination, mais il ne définit pas une limite de décision et ne conserve pas l'enregistrement complet des actions. Une passation qui dépend de la mémoire échouera pendant la nuit la plus chargée. Commencez par écrire le responsable actif et son suppléant pour le premier service de production que vos agents peuvent toucher. Faites ensuite effectuer par un agent une action délimitée sur ce service. Si vous ne pouvez pas identifier la personne qui devrait approuver cet appel sans demander autour de vous, l'agent a atteint la production avant votre modèle de responsabilité.