Approbation par session ou par appel pour les actions des agents

Un agent IA n'a pas besoin d'un accès sans restriction pour être utile. Il lui faut l'autorité nécessaire à la tâche en cours, pendant une durée que vous pouvez expliquer, avec une décision humaine placée là où un nouvel appel modifierait le niveau de risque. C'est la différence pratique entre l'approbation par session et l'approbation par appel.

J'ai vu des équipes commettre deux erreurs opposées. La première approuve chaque recherche anodine et habitue les utilisateurs à cliquer sur les avertissements sans les lire. La seconde accorde une session longue à un agent de programmation, puis s'étonne lorsqu'une boucle crée cinquante tickets, déclenche plusieurs déploiements ou exporte beaucoup plus de données que prévu. Ces problèmes ne viennent pas d'un exploit sophistiqué. Ils viennent d'une limite d'approbation mal placée.

L'expression clé approbation par session ou par appel décrit un choix qui repose sur trois éléments : la durée du travail, l'étendue des permissions de l'identifiant et les conséquences d'une répétition d'une requête valide. La méthode HTTP, le plan annoncé par l'agent et la présence d'un développeur qui surveille sont des indicateurs moins fiables.

L'approbation autorise une action dans une limite définie

L'approbation par session donne à un processus agent identifié le droit d'utiliser un identifiant pendant toute son exécution. L'approbation par appel demande une décision chaque fois que cet identifiant est utilisé. Ces mécanismes répondent à des questions différentes. Les confondre conduit soit à une confiance aveugle, soit à une friction inutile.

Une décision de session signifie : « Je reconnais ce processus, j'accepte cette exécution limitée et les actions accessibles avec cet identifiant sont suffisamment sûres pour être répétées pendant cette exécution. » C'est raisonnable pour un agent qui vérifie quelques tickets pendant l'analyse d'un bug. C'est une mauvaise décision pour un agent capable de modifier la production chaque fois que son propre raisonnement estime qu'une nouvelle modification serait utile.

Une décision par appel signifie : « J'accepte maintenant cette utilisation précise de cet identifiant. » Le mécanisme est volontairement plus lent. La demande doit correspondre à un moment où une personne peut comprendre la conséquence et la refuser sans perdre toute la tâche. Si elle ne présente pas un véritable choix, la conception de l'approbation est mauvaise. Lorsqu'elle précède une action irréversible, la seconde supplémentaire est généralement un faible prix à payer.

Ne confondez pas cela avec l'authentification. L'authentification indique au système local qui peut déverrouiller le coffre d'identifiants. L'autorisation détermine si une exécution agent peut utiliser un identifiant précis. Le contrôle par appel ajoute une troisième question : cette utilisation, à cet instant, mérite-t-elle une nouvelle décision humaine ?

Cette distinction compte pendant une tâche de programmation ordinaire. Un agent peut utiliser un jeton API pour lire l'état d'une compilation et un autre pour déclencher une mise en production. Le même processus peut être suffisamment fiable pour consulter le premier, tout en nécessitant une décision explicite pour le second. L'identité du processus ne rend pas tous les endpoints qu'il peut atteindre équivalents.

Une bonne limite d'approbation possède quatre caractéristiques :

• Une personne peut expliquer le travail effectué par l'agent.
• La portée de l'identifiant correspond à ce travail, et non à toute la liste des tâches possibles.
• L'approbation prend fin lorsque le travail ou le processus identifié prend fin.
• La personne peut décrire le pire résultat plausible si l'agent répète une action autorisée.

La quatrième caractéristique révèle plus de mauvaises conceptions que la plupart des listes de contrôle. Si la réponse est « il ferait une autre requête sans conséquence », l'approbation par session peut convenir. Si elle implique de l'argent, une communication client, l'état de la production, une suppression, une modification d'accès ou un export important, gardez une décision humaine proche de chaque action.

La durée de la tâche change la portée d'une promesse de session

Une session est plus sûre lorsqu'elle est courte, limitée à une seule tâche et liée à un processus qui se termine quand la tâche est achevée. Une session qui survit discrètement à des travaux sans rapport est une permission permanente sous un nom plus rassurant.

La durée modifie le risque parce qu'un agent ne cesse pas de raisonner après sa première action prévue. Il peut réessayer, poursuivre une sous-tâche découverte, consulter un autre dépôt ou suivre une instruction dangereuse trouvée dans un fichier ou un ticket. Plus le processus dure, moins votre modèle mental initial reste utile. Une exécution de dix minutes pour examiner des tests en échec a un objectif compréhensible. Un processus actif tout l'après-midi a accumulé du contexte, changé d'objectif et rencontré davantage d'entrées hostiles ou trompeuses.

Utilisez autant que possible la fin de la tâche plutôt qu'une durée fixe. La fin du processus est une condition honnête : l'agent approuvé n'existe plus. Un délai d'expiration fixe est un recours, pas un contrôle équivalent. Au bout de quinze minutes, l'agent peut encore effectuer le travail initial, ou un autre outil peut avoir hérité de la même autorité. Le temps seul ne permet pas de le savoir.

Avant d'approuver une session limitée, écrivez l'unité de travail. Une bonne description est concrète : « examiner l'exécution d'intégration continue en échec et ouvrir un commentaire brouillon avec les résultats ». Une mauvaise description est « aider à la mise en production ». Un langage trop large laisse à l'agent la possibilité de transformer une petite tâche de diagnostic en travail de déploiement.

Le raccourci courant consiste à approuver une session pour chaque tâche parce que les interruptions sont mal vécues. Cette plainte est légitime lorsque les demandes concernent des appels sans conséquence. La solution consiste à réduire le nombre de demandes en limitant les identifiants et en regroupant les tâches courantes dans de vraies sessions, pas à transformer une longue exécution agent en fenêtre d'accès total.

Les redémarrages d'agents exigent la même prudence. Pour la personne qui a lancé la commande, un redémarrage peut sembler assurer la continuité. Pourtant, il s'agit d'un nouveau processus qui peut charger d'autres instructions, du code ou des plugins. Demandez une nouvelle autorisation de session après un redémarrage. La décision initiale concernait une autorité exécutable et une exécution précises, pas une intention vague pour l'après-midi.

La sensibilité d'un identifiant commence par ses capacités

Un identifiant est sensible en raison de ce qu'il peut provoquer, révéler ou déléguer, et non de son nom. Une clé API limitée à la lecture d'un artefact de compilation public peut être moins dangereuse qu'un jeton qui donne accès aux administrateurs d'un espace privé. Une clé SSH atteignant un hôte de déploiement présente un autre mode de défaillance qu'un jeton appelant une API de facturation, mais les deux peuvent nécessiter une approbation par appel.

Évaluez chaque identifiant selon les permissions réelles du système distant. N'acceptez pas l'étiquette « jeton de lecture » sans vérifier ce que l'API considère comme une lecture. Certains services exposent les exports comme des lectures. D'autres permettent à un endpoint apparemment en lecture seule de lancer la génération d'un rapport, de consommer une capacité limitée ou de renvoyer en masse des données que l'agent ne devrait jamais voir.

Avant de choisir un niveau d'approbation, posez quatre questions :

1. Cet identifiant peut-il modifier un état hors de la machine locale ?
2. Peut-il révéler des informations qui ne devraient pas être placées dans le contexte ou la sortie de l'agent ?
3. Peut-il accorder davantage d'accès, directement ou via un workflow qu'il peut déclencher ?
4. Un appelant peut-il dépenser de l'argent, consommer un quota ou créer un engagement contractuel ou réputationnel ?

Une réponse positive n'impose pas toujours l'approbation par appel. Elle signifie que l'approbation par session doit reposer sur une tâche plus étroite, une portée plus stricte et un retour en arrière plausible. Si plusieurs réponses sont positives, demander une décision à chaque utilisation est généralement le choix honnête.

Réduisez d'abord la portée, puis ajoutez l'approbation. Un jeton qui ne peut lire qu'un seul dépôt permet une décision de session bien plus fiable qu'un jeton capable de lire tous les dépôts de l'organisation. Un identifiant limité à un environnement de préproduction est plus sûr dans une session qu'un identifiant capable d'agir en production. L'approbation humaine ne peut pas réparer un jeton excessivement large une fois que l'agent possède déjà l'autorité nécessaire pour effectuer des requêtes coûteuses.

SSH mérite une attention particulière, car on le décrit souvent comme un simple accès shell. Or l'accès shell ouvre une vaste surface d'action qui change avec le temps. Le risque dépend du compte, de l'hôte, de la connectivité réseau, des commandes disponibles, des hooks de déploiement et des fichiers accessibles. Un compte limité à une commande de diagnostic peut convenir à une session. Un compte de déploiement, un hôte contenant des données clients ou un compte capable de modifier les contrôles d'accès devrait rester derrière une approbation par appel jusqu'à ce que sa portée soit réduite.

Ne laissez pas la rotation des identifiants masquer cette analyse. Une clé nouvellement créée avec de larges droits en production conserve de larges droits en production. La rotation limite les abus futurs après une mauvaise exécution ; elle n'annule pas les appels distants déjà acceptés.

La répétition transforme une action tolérable en action coûteuse

Une requête peut être acceptable isolément et devenir dangereuse lorsqu'un agent la répète. Classez l'action répétée, pas seulement la première action présentée dans une demande.

Les équipes accordent souvent trop d'importance aux noms des méthodes HTTP. La RFC 9110 indique que les méthodes sûres sont censées être en lecture seule : GET, HEAD, OPTIONS et TRACE. Elle précise aussi qu'un client ne peut pas être tenu responsable lorsqu'un serveur expose un comportement dangereux par une méthode sûre, puisque ce comportement dépend du propriétaire de la ressource. Un endpoint GET peut donc être destiné à récupérer des informations tout en générant un export massif, en modifiant un champ d'audit ou en déclenchant un traitement. Les noms de méthodes lancent l'analyse, mais ne la terminent pas.

L'idempotence est un autre terme souvent mal utilisé. Une requête est idempotente lorsque sa répétition produit le même effet prévu sur l'état du serveur que son exécution unique. Cela ne veut pas dire qu'elle est inoffensive. Une requête PUT qui définit un indicateur sur true peut être idempotente tout en activant une fonctionnalité en production. DELETE peut être idempotente après la première suppression tout en supprimant un élément important. GET peut être sûre au sens du protocole et épuiser une limite de débit si l'agent boucle.

Testez le comportement d'un endpoint dans un compte jetable ou un environnement de préproduction. Envoyez deux fois la même requête, examinez l'état distant et les effets secondaires, puis demandez ce qui se passerait si l'agent l'envoyait cent fois. Ne vous arrêtez pas au corps de la réponse. Vérifiez les messages envoyés, les tâches mises en file, les enregistrements d'audit créés, le quota consommé, les webhooks déclenchés et les données copiées ailleurs.

Pour un endpoint qui crée des objets, utilisez une clé d'idempotence si le service la prend en charge. Cette forme de requête évite qu'une nouvelle tentative réseau crée un second paiement, ticket ou élément de provisionnement lorsque la première réponse se perd :

POST /v1/provisioning-requests HTTP/1.1
Authorization: Bearer injected-by-gateway
Idempotency-Key: agent-run-8b2f1-request-17
Content-Type: application/json

{"environment":"staging","version":"2025.04.18"}

Le service devrait renvoyer le résultat original lorsqu'il reçoit à nouveau la même clé d'idempotence. La réponse contient souvent le même identifiant d'objet et un statut de réussite, plutôt qu'un nouvel objet. Confirmez ce comportement dans la documentation du service et par vos propres tests. Une clé d'idempotence réduit les créations en double dues aux nouvelles tentatives ; elle ne rend pas un déploiement inapproprié acceptable et n'empêche pas un agent de générer une nouvelle clé à chaque tentative mal orientée.

L'approbation par appel convient aux actions présentant l'un des profils suivants :

• Chaque appel crée un nouvel élément, comme une facture, un compte, un ticket, un message ou une commande.
• Chaque appel modifie un état actif difficile à reconstituer.
• Chaque appel peut révéler une page supplémentaire, une archive ou les données d'un autre client.
• Chaque appel peut produire un effet public ou visible par un client.
• Chaque appel peut déclencher un travail coûteux ou consommer une capacité limitée.

Une session peut convenir aux appels répétés lorsque le système distant leur attribue peu de conséquences, que la portée de l'identifiant est réduite et que la tâche a une fin claire. C'est à l'équipe d'établir ce point. « L'agent ne bouclera probablement pas » n'est pas une propriété de l'endpoint.

Une étiquette « lecture seule » ne suffit pas à déterminer le risque

L'accès en lecture peut créer des risques liés à la confidentialité, aux opérations et à l'injection d'instructions, même lorsqu'il ne peut pas modifier un enregistrement distant. Traitez l'exposition des données comme une action ayant des conséquences, surtout lorsque l'agent peut résumer, copier ou utiliser les données récupérées pour décider de son étape suivante.

Un agent autorisé à rechercher dans un système de support peut utiliser une session si la tâche se limite à un ticket et à ses pièces jointes. Le même identifiant devient beaucoup plus difficile à approuver pour une exécution qui peut énumérer tous les tickets, récupérer des exports ou placer des conversations privées dans le contexte local. L'endpoint peut utiliser GET partout. C'est la limite des données, et non le verbe, qui définit le risque.

La question délicate est de savoir si l'agent lui-même peut voir le résultat renvoyé. Une passerelle qui garde les jetons hors de l'agent ne rend pas automatiquement chaque résultat acceptable. Les réponses peuvent contenir des secrets : des endpoints de configuration renvoient des chaînes de connexion, des fiches utilisateurs contiennent des données personnelles, la sortie d'une commande inclut des variables d'environnement et les erreurs exposent des chemins ou identifiants internes.

Choisissez l'approbation par appel pour une lecture lorsqu'un résultat peut révéler une catégorie d'information sensible ou lorsque la requête de l'agent peut élargir son propre périmètre de recherche. Cela comprend les recherches générales, les exports, la récupération de secrets, l'énumération de comptes et les commandes comme cat sur des répertoires au contenu variable. Une personne doit pouvoir examiner la cible avant d'introduire ces données dans l'exécution.

Pour les lectures courantes, limitez la forme de la requête. Préférez un identifiant limité à un projet, un dépôt, un environnement ou un groupe de ressources API. Définissez des limites de pagination côté serveur lorsque le service le permet. Donnez si possible à l'agent un mécanisme qui accepte des identifiants explicites plutôt qu'un endpoint de recherche illimité. Ces choix réduisent le nombre de demandes, car chaque appel autorisé est plus petit.

Un schéma de défaillance fréquent apparaît lors de la réponse aux incidents. Un agent commence par examiner les journaux, y trouve un jeton, puis recherche toutes les occurrences de ce jeton dans une archive étendue. Pour l'opérateur, l'approbation de session concernait le dépannage, mais la portée de l'identifiant et la forme de la requête permettaient une collecte. Comme aucune mutation n'apparaît dans la liste d'activité, il croit l'exécution sûre. Pourtant, l'action sensible était la récupération.

Conservez séparément ce qui a été demandé, l'identifiant utilisé et le fait que l'appel ait été approuvé comme action de session ou comme action par appel. Cette trace aide l'enquêteur à distinguer un agent compromis d'un mauvais choix d'approbation. Elle révèle aussi les identifiants dont la portée doit être réduite. Enregistrer uniquement les mutations réussies rend les échecs de récupération les plus difficiles à détecter.

Faites correspondre les demandes aux décisions qu'une personne peut réellement prendre

La fatigue liée aux approbations est un défaut de conception lorsque les demandes sont trop nombreuses pour être lues ou trop vagues pour être évaluées. L'approbation par appel ne fonctionne que si chaque demande fournit assez d'informations pour accepter ou refuser une conséquence concrète.

Une bonne demande identifie le processus appelant, l'identifiant ou la catégorie d'action, la destination et l'effet important. « Autoriser une requête API » ne permet pas de décider correctement. « Le processus agent signé demande un déploiement en production avec l'identifiant de mise en production » est beaucoup plus utile. Pour une lecture sensible, indiquez le jeu de données ou la cible plutôt que « requête GET ». Pour SSH, affichez l'hôte et la commande, ou une catégorie de commandes compréhensible.

Ne réduisez pas la surcharge en masquant la destination. Une personne qui approuve selon un nom de tâche sympathique ne peut pas détecter une faute de frappe, une instruction malveillante ou un changement de direction de l'agent. La demande doit être assez précise pour révéler l'écart entre le travail prévu et l'action réelle.

À l'inverse, ne demandez pas aux utilisateurs d'analyser un corps HTTP brut pour chaque lecture courante. Cela produit des approbations rituelles. Regroupez les appels répétitifs et peu risqués dans une session limitée, et réservez les demandes par appel aux opérations qui franchissent une véritable limite de décision. Les utilisateurs doivent voir moins de demandes, mais chacune doit compter.

Ajoutez une courte note d'approbation à chaque configuration d'identifiant. Ce n'est pas un langage de politique et elle n'a pas besoin de le devenir. Une phrase comme « session uniquement pour les lectures d'état de compilation d'un dépôt ; approuver chaque mise en production » rend les contrôles ultérieurs concrets. Si une équipe ne peut pas formuler la différence entre le travail courant et une action importante, l'identifiant est probablement trop large.

L'identité du processus affichée lors de l'autorisation de session mérite aussi de l'attention. Les utilisateurs doivent approuver l'autorité exécutable, pas seulement une ligne de commande qui pourrait être copiée ou modifiée. Un processus parent signé et un assistant non signé sont deux décisions de confiance différentes. Face à une autorité inconnue, arrêtez l'exécution, cherchez pourquoi elle a changé et ne l'approuvez que si ce changement est attendu. Cliquer parce que la tâche est urgente habitue l'organisation à accepter un chemin d'usurpation.

Utilisez une matrice de décision avant de modifier le réglage

Une petite matrice évite les débats fondés sur la tolérance personnelle aux demandes. Évaluez l'action selon ses conséquences et choisissez le niveau le plus strict lorsque les réponses partent dans deux directions.

Lorsque les réponses sont mixtes, séparez le workflow au lieu de chercher un compromis. Donnez à l'agent un identifiant approuvé par session pour les diagnostics et un identifiant approuvé par appel pour la remédiation. C'est souvent plus naturel que d'approuver constamment les lectures ou d'accorder une session large pour éviter les demandes lors des mutations.

Prenons un exemple. Un agent analyse un déploiement en échec. Il doit lire les journaux de compilation, récupérer l'état d'un environnement de préproduction précis et éventuellement redémarrer un service.

Les lectures de journaux et d'état peuvent utiliser une approbation par session si le jeton ne concerne que ce projet et si le processus prend fin après le diagnostic. Le redémarrage doit utiliser un autre identifiant, avec approbation par appel, car il modifie l'état actif. Même s'il est généralement sûr, un redémarrage répété peut interrompre un travail, masquer la cause et déclencher des boucles de récupération automatique. Le fait que l'agent ait découvert ce redémarrage comme solution raisonnable ne le rend pas courant.

Changeons un détail : l'API d'état peut interroger tous les environnements de production et les journaux peuvent contenir des charges utiles client non masquées. L'approbation par session ne convient plus à l'identifiant de diagnostic. Il faut d'abord réduire cet accès. Placer le même identifiant large derrière une approbation par appel limite un type de défaillance, mais l'utilisateur ne peut pas évaluer correctement chaque récupération si le sélecteur de données reste sans contrainte.

C'est pourquoi un réglage unique par agent est un mauvais modèle. L'approbation doit appartenir au canal d'action et à la portée de l'identifiant. Une exécution agent peut combiner les deux niveaux si les limites sont tracées volontairement.

Les pistes d'audit expliquent une mauvaise décision, mais ne l'annulent pas

Un enregistrement résistant aux altérations permet d'enquêter sur une exécution, de révoquer une session active et de déterminer si l'agent a répété une action. Il n'empêche pas un service distant d'accepter un appel déjà approuvé.

Conservez deux vues de l'activité. Le journal de session indique qui a exécuté le travail, quand il a commencé, quelle autorité de processus il possédait et si quelqu'un l'a révoqué. Le journal des appels indique quel chemin d'identifiant l'agent a utilisé, quelle destination il a contactée et si l'appel reposait sur une autorisation de session ou une approbation ponctuelle. Les deux sont nécessaires. Une liste de sessions ne prouve pas quelle action a causé le problème, tandis qu'un ensemble d'appels sans contexte de processus ne permet pas de savoir qui les a lancés.

Rendez l'intégrité de l'audit vérifiable. Une chaîne de journaux liée par hachage doit échouer à la vérification si quelqu'un modifie, supprime ou réordonne un enregistrement. Le test est simple : vérifiez une copie connue comme correcte, modifiez un octet dans une copie, puis vérifiez-la à nouveau. Le vérificateur doit signaler que la chaîne n'est plus valide, tandis que l'original reste valide. Faites ce test dans un environnement prévu à cet effet, jamais en modifiant le stockage d'audit de production.

Sallyport construit ses journaux Sessions et Activity à partir d'un journal d'audit chiffré, lié par hachage et aveugle à l'écriture, et sp audit verify vérifie cette chaîne hors ligne sur le texte chiffré sans nécessiter de clé de coffre. Cette séparation est utile lorsque la personne qui vérifie les enregistrements ne doit pas recevoir les identifiants ou les charges utiles protégés par le coffre.

Les journaux révèlent aussi une erreur courante : considérer une session comme une raison de ne plus surveiller. Examinez les exécutions qui ont effectué beaucoup plus d'appels que prévu, contacté une nouvelle destination, duré bien plus longtemps que leur description ou utilisé un identifiant dans une catégorie inhabituelle. Un moteur de règles n'est pas nécessaire pour repérer ces tendances. Une revue humaine hebdomadaire sur un petit échantillon suffit souvent à détecter l'élargissement de portée avant qu'il ne devienne une habitude.

Lorsqu'un agent agit mal, préservez l'identité du processus, les entrées de la tâche, le journal de session, la séquence d'appels et les journaux du service distant avant de modifier la configuration. Posez ensuite une question plus précise que « l'agent a-t-il été compromis ? » L'action était-elle permise par la portée de l'identifiant ? Le niveau d'approbation correspondait-il au risque de répétition ? La demande fournissait-elle assez d'informations pour la refuser ? Le processus a-t-il changé après l'autorisation ? Les réponses mènent à des corrections. Une interdiction générale de l'autonomie, non.

Un démarrage limité vaut mieux qu'une exception large

Commencez par un workflow dont vous pouvez décrire l'impact sans approximation, puis appliquez l'approbation par appel à l'identifiant capable de causer le plus de dommages. Observez plusieurs exécutions réelles avant de placer la partie courante dans une session limitée.

Pour une configuration d'agent sur Mac, Sallyport conserve les identifiants API et SSH dans son coffre chiffré et exécute l'action au lieu de transmettre le secret à l'agent. Cela réduit l'exposition des identifiants, mais vous devez toujours choisir la limite d'approbation avec le même soin, car l'action distante reste réelle.

La première configuration doit rendre le développeur légèrement impatient, pas aveugle. Si chaque exécution produit une longue série de demandes pour lire l'état des compilations, la portée ou le regroupement des tâches doit être revu. Si un agent peut modifier la production pendant une heure après une seule approbation, la session est trop large. Ajustez l'identifiant et la limite de la tâche avant de retirer l'humain de la boucle.

Formulez le prochain choix d'approbation en termes opérationnels : ce processus signé, pour cette tâche, peut effectuer ces appels à faible impact jusqu'à sa fin ; cet autre identifiant nécessite une nouvelle décision, car chaque utilisation peut modifier quelque chose que nous ne pouvons pas annuler facilement. Cette phrase donne aux personnes chargées de vérifier une règle applicable sous pression. Tout ce qui est plus vague finira par devenir une exception permanente.