Comment contrôler les jetons d'actualisation des agents IA

Un agent IA ne doit jamais détenir de jeton d'actualisation. Cette règle paraît sévère jusqu'à ce que l'on regarde ce que fait ce jeton : il permet à un processus de continuer à obtenir des accès après que l'approbation initiale de la personne a disparu du champ de vision. Un jeton d'accès peut expirer rapidement ; un jeton d'actualisation maintient la relation active.

La bonne conception ne consiste pas à rendre l'agent plus efficace pour protéger un identifiant porteur. Placez l'identifiant dans une couche d'action contrôlée par un processus dont une personne garde la responsabilité. L'agent demande une action externe précise, la couche décide si cette exécution est autorisée, actualise l'accès uniquement lorsque c'est nécessaire, puis renvoie le résultat. Cette organisation vous donne un endroit où approuver, révoquer et examiner les utilisations.

Un simple coffre de mots de passe ne suffit pas. Un coffre protège le stockage. Une couche d'action pour agents gouverne l'utilisation. Les équipes confondent constamment ces deux rôles, puis découvrent qu'un jeton placé dans un espace chiffré reste accessible à tout processus capable de poser la bonne question au coffre.

Les jetons d'actualisation des agents IA modifient la frontière de confiance

Les jetons d'actualisation des agents IA sont dangereux parce qu'ils prolongent l'autorité au-delà du processus d'agent qui en avait initialement besoin. Si un agent de programmation peut lire un jeton d'actualisation dans une variable d'environnement, un fichier de configuration, un profil de navigateur ou la réponse d'un gestionnaire de secrets, il peut l'utiliser avec n'importe quel client HTTP qu'il est capable d'appeler. Le jeton n'appartient plus à une tâche limitée. Il appartient à quiconque prend le contrôle de ce processus.

OAuth 2.0, RFC 6749, décrit les jetons d'actualisation comme des identifiants utilisés pour obtenir des jetons d'accès lorsque le jeton actuel expire ou devient invalide. La spécification les rend facultatifs, mais cela ne les rend pas inoffensifs. Les fournisseurs les émettent parce qu'une autorisation interactive à chaque renouvellement de jeton d'accès serait fastidieuse. C'est précisément pour cette raison qu'un agent sans surveillance ne doit pas en posséder.

Gardez trois éléments distincts :

• Le propriétaire du compte est la personne ou l'identité de service dont le compte a accordé l'accès.
• Le demandeur de l'action est le processus d'agent qui demande à appeler une API maintenant.
• Le dépositaire de l'identifiant est le composant qui stocke le jeton d'actualisation et communique avec le point de terminaison de jeton.

Dans une petite installation, une même personne ou un même programme peut remplir plusieurs rôles, mais ces rôles doivent tout de même exister. Si le même agent les assume tous, il peut connecter un nouveau compte, élargir son périmètre, actualiser l'accès indéfiniment et dissimuler l'action parmi les requêtes ordinaires. Ce n'est pas une conception d'autorisation. C'est un jeton porteur avec un chatbot attaché.

J'ai vu des équipes dire : « l'agent a seulement besoin d'un accès en lecture », puis placer un jeton d'actualisation donnant de larges accès aux dépôts, aux e-mails ou au cloud dans un fichier .env local. Le jeton d'accès a peut-être une durée de vie brève, mais le jeton d'actualisation rend l'erreur persistante. Une injection de prompt n'a pas besoin de convaincre le modèle d'exfiltrer un mot de passe. Elle peut le convaincre d'utiliser l'autorisation toujours valide pour effectuer une requête qui paraît plausible dans son contexte.

La frontière doit se trouver avant l'entrée des identifiants dans le processus de l'agent. L'agent ne reçoit ni la valeur d'un jeton ni un faux emplacement qu'il pourrait échanger ailleurs. Il reçoit une interface d'opérations : récupérer ce ticket, créer ce brouillon, lire l'état de ce déploiement, ouvrir cette session SSH vers cet hôte approuvé. La couche d'action gère les détails du protocole derrière cette opération.

Une personne doit être responsable de l'autorisation, pas seulement approuver un prompt

La personne qui peut approuver une actualisation doit être désignée avant la création de la connexion OAuth. « N'importe quel développeur peut cliquer sur Autoriser » fonctionne jusqu'au départ du propriétaire du compte, au changement de responsable d'une boîte partagée ou à la reconnexion d'un service par un agent sous l'identité de quelqu'un d'autre.

Pour un compte SaaS personnel, le propriétaire du compte doit effectuer l'autorisation initiale et approuver la reconnexion après une révocation ou une expiration. Pour un compte opérationnel partagé, désignez un responsable et un remplaçant capables de le révoquer. Pour une identité machine, le responsable du service doit autoriser l'enregistrement du client et ses périmètres. Ne considérez pas une personne et une identité machine comme interchangeables simplement parce qu'elles peuvent appeler la même API.

Séparez quatre décisions souvent réduites à un seul clic dans le navigateur :

1. Qui peut créer l'autorisation initiale.
2. Quelle couche d'action peut conserver le jeton d'actualisation obtenu.
3. Quelles sessions d'agent peuvent demander des actions avec cette autorisation.
4. Qui peut révoquer l'autorisation ou approuver une nouvelle connexion.

L'écran de consentement OAuth initial ne répond qu'à la première question, et parfois de manière très incomplète. Il indique au fournisseur qu'un titulaire de compte a autorisé un client avec les périmètres indiqués. Il ne dit pas à votre système local si un dépôt non fiable, un nouveau sous-processus d'agent ou une tâche nocturne peut utiliser cette autorisation.

Un registre pratique de propriété doit contenir plus qu'une adresse e-mail de compte fournisseur. Conservez un enregistrement local avec un identifiant d'autorisation opaque, le nom du fournisseur, la référence du compte, l'ensemble des périmètres, le responsable, la personne de secours chargée de la révocation, la date de connexion et les actions autorisées à la demander. Évitez de copier le jeton d'actualisation dans cet enregistrement. Il explique le jeton ; il ne doit pas devenir un second coffre de secrets.

Le cas délicat est celui de l'accès partagé. Une équipe connecte souvent un compte administrateur parce que c'est rapide, puis laisse l'agent de chaque développeur l'utiliser. Ce choix détruit la responsabilité. Si l'API prend en charge les comptes de service, les installations d'application, les identités déléguées ou les jetons limités à certains projets, utilisez-les. Sinon, limitez la couche d'action à un petit groupe d'opérations approuvées et notez le véritable responsable du compte partagé.

Ne donnez pas à un agent le pouvoir de lancer seul un nouveau flux OAuth dans le navigateur. Il peut afficher une page légitime du fournisseur, mais aussi orienter la personne vers un compte plus étendu, une sélection de périmètres plus large ou un autre espace client. Lancer une connexion est une action administrative. Demandez à la personne de la lancer depuis la couche d'action et de vérifier le compte et la liste des périmètres avant le consentement.

La couche d'action ne doit actualiser l'accès que pour terminer une action approuvée

Une couche d'action contrôlée ne doit échanger un jeton d'actualisation que lorsqu'elle reçoit une demande autorisée qui nécessite un jeton d'accès actuel. Elle ne doit pas exécuter une boucle en arrière-plan qui actualise chaque identifiant « au cas où ». L'actualisation préventive paraît propre dans le code, mais complique la réponse aux incidents, car elle maintient les autorisations actives sans action humaine ou agent correspondante.

Le chemin de requête peut rester simple :

1. Une session d'agent demande une opération nommée et fournit les paramètres d'action ordinaires.
2. La couche d'action identifie l'autorisation liée à cette opération, puis vérifie que la session peut l'utiliser.
3. Si le jeton d'accès mis en cache est absent ou proche de l'expiration, la couche envoie le jeton d'actualisation au point de terminaison de jeton du fournisseur.
4. La couche appelle l'API cible avec le jeton d'accès et renvoie le résultat filtré à l'agent.
5. La couche enregistre l'action et l'événement d'actualisation sans enregistrer de données d'identification.

L'agent ne choisit jamais le point de terminaison de jeton, l'identifiant client, l'URL de rappel ni la chaîne de périmètres. Ces valeurs appartiennent à la définition de connexion approuvée par la personne. Autoriser l'agent à les fournir transforme votre passerelle en relais de jetons ouvert.

Prenons le cas d'un agent chargé de publier une note de version dans un outil de suivi de projet. Il demande à la couche d'action de créer un ticket dans un projet donné. La couche constate que l'opération nécessite une autorisation du système de suivi pour ce projet, vérifie la session demandeuse, renouvelle le jeton d'accès si nécessaire et publie la note. Le résultat peut être l'identifiant du nouveau ticket et la référence fournie par le service, pas le jeton porteur qui a servi à le créer.

Modifions maintenant le prompt. Une instruction malveillante dans un dépôt demande à l'agent de « vérifier l'accès » en listant tous les projets de l'organisation et en créant un ticket de test dans chacun. Si l'agent possède le jeton d'actualisation, l'instruction peut devenir une série directe d'appels API. Si l'agent ne dispose que de l'interface d'opérations nommées, la couche peut refuser les demandes en dehors du projet approuvé ou exiger une nouvelle autorisation humaine avant de poursuivre la session.

Cela ne demande pas un langage de règles compliqué. Il faut un ensemble restreint et compréhensible de choix : quel processus demande l'action, quelle autorisation il peut utiliser et si cette action nécessite une approbation humaine. Davantage d'options ne rendent pas automatiquement la conception plus sûre. Elles empêchent souvent l'opérateur de savoir quelle règle l'a emporté.

Sallyport applique cette séparation en conservant les identifiants API dans son coffre chiffré et en exécutant les actions HTTP ou SSH via sa connexion MCP, au lieu de renvoyer les identifiants à l'agent.

Le type d'autorisation détermine ce que vous pouvez automatiser sans risque

Utilisez le flux de code d'autorisation avec PKCE pour connecter le compte d'une personne dans une application de bureau ou locale. La personne se connecte chez le fournisseur, examine la demande de consentement, puis revient à l'application locale par le chemin de redirection enregistré. PKCE lie la réponse d'autorisation au client qui a lancé le flux et réduit l'intérêt d'un code d'autorisation intercepté.

La RFC 9700, OAuth 2.0 Security Best Current Practice, indique que les clients publics doivent utiliser PKCE. Elle précise aussi que les jetons d'actualisation des clients publics doivent utiliser une contrainte de présentation ou une rotation des jetons. Cette recommandation compte pour les intégrations d'agents, car une application locale se comporte souvent comme un client public. Intégrer un secret client dans une application de bureau n'en fait pas un client confidentiel. Toute personne qui possède l'application peut extraire ce secret.

Choisissez le flux en fonction de l'identité connectée :

• Utilisez le code d'autorisation avec PKCE pour le compte d'une personne chez un fournisseur.
• Utilisez les identifiants client pour une identité de service lorsque le fournisseur les prend en charge et qu'aucune délégation d'un compte humain n'est nécessaire.
• Utilisez le modèle d'installation ou d'application propre au fournisseur lorsqu'il offre un accès plus limité à un projet ou à une organisation.
• Utilisez l'autorisation par appareil uniquement lorsque le fournisseur et votre environnement l'exigent, et montrez clairement à la personne quelle identité et quels périmètres elle approuve.

Les identifiants client ne produisent généralement pas de jetons d'actualisation, car le client peut demander un nouveau jeton d'accès en s'authentifiant à nouveau. Cette approche peut être plus sûre pour une tâche autonome si l'identité de service possède des droits limités et si ses éléments d'authentification restent dans la couche d'action. N'utilisez pas les identifiants client comme prétexte pour donner à un agent de programmation un secret client largement privilégié.

L'accès hors ligne mérite une attention particulière. Certains fournisseurs OpenID Connect exigent le périmètre offline_access avant d'émettre un jeton d'actualisation. Demandez-le uniquement lorsqu'une action doit réellement s'exécuter après la fin de la session interactive. Si une personne est présente pour chaque opération, un jeton d'accès court avec une nouvelle autorisation peut mieux convenir. Les équipes demandent souvent l'accès hors ligne par défaut pour éviter de gérer les expirations. Elles échangent ainsi un désagrément contre un identifiant durable.

Évitez complètement les identifiants de mot de passe du propriétaire de la ressource. La RFC 9700 déconseille ce type d'autorisation, car il transmet le mot de passe de l'utilisateur au client. Une couche d'action ne rend pas cette pratique acceptable. Elle vous offre seulement un endroit supplémentaire où perdre un mot de passe.

La rotation n'est utile que si le stockage gère correctement le remplacement

La rotation des jetons d'actualisation réduit les dégâts causés par la copie d'un jeton en remplaçant l'ancien après chaque actualisation réussie. Un fournisseur peut détecter la réutilisation d'un ancien jeton et invalider la famille d'autorisations concernée. Cette détection est utile, mais elle peut aussi bloquer votre intégration légitime si votre logique d'actualisation est mal conçue.

La panne la plus fréquente est une condition de concurrence. Deux sessions d'agent ont besoin d'un jeton d'accès presque au même moment. Elles lisent toutes deux le même ancien jeton d'actualisation. La première réussit et reçoit une nouvelle valeur. La seconde envoie l'ancienne valeur un instant plus tard. Selon le fournisseur, cette seconde demande peut échouer ou déclencher une détection de réutilisation qui révoque toute la famille, y compris le nouveau jeton.

Évitez cette course en désignant un seul responsable de l'actualisation par autorisation. La couche d'action doit sérialiser le travail d'actualisation pour chaque identifiant d'autorisation. Le second appelant attend le résultat de la première actualisation, puis utilise le jeton d'accès nouvellement mis en cache au lieu d'envoyer une autre demande de jeton. C'est une exigence de correction, pas une optimisation.

Enregistrez le jeton de remplacement avant de considérer l'actualisation comme réussie pour les opérations suivantes. Un ordre sûr ressemble à ceci :

1. Envoyer l'ancien jeton d'actualisation au point de terminaison de jeton via TLS.
2. Valider la réponse et l'associer au fournisseur et à l'autorisation attendus.
3. Écrire le nouveau jeton d'actualisation et ses métadonnées dans le stockage chiffré en une seule mise à jour durable.
4. Marquer l'ancien jeton comme inutilisable dans l'état local.
5. Libérer les appels en attente avec le nouveau jeton d'accès ou un nouveau chemin de requête.

Si le processus s'arrête après la rotation du jeton par le fournisseur, mais avant l'enregistrement du remplacement dans le stockage local, vous avez peut-être perdu l'autorisation. Les nouvelles tentatives ne peuvent pas résoudre ce problème. La récupération passe par une reconnexion guidée par une personne, ce qui explique l'importance des informations sur le responsable et le révocateur.

Certains fournisseurs émettent un nouveau jeton d'actualisation seulement dans certains cas. D'autres renvoient le même jeton. Votre code doit accepter ces deux comportements sans supposer que l'un ou l'autre sera toujours appliqué. Ne conservez l'ancienne valeur que jusqu'à la confirmation de la réponse du fournisseur et de l'écriture durable. Ne consignez jamais l'une ou l'autre valeur pendant le débogage. Un nombre étonnant de fuites de jetons commence par une instruction de débogage temporaire qui a survécu à une mise en production.

Les jetons soumis à une contrainte de présentation peuvent réduire le risque de rejeu en liant le jeton à une clé cryptographique détenue par le client. DPoP, défini dans la RFC 9449, est une approche possible. Cela ne supprime pas le besoin d'un dépositaire. Si un agent peut utiliser à la fois le jeton d'actualisation et la clé privée de signature, il possède toujours une autorité durable. Gardez ces deux éléments derrière la couche d'action et testez le comportement du fournisseur avant de vous fier à cette contrainte.

La révocation nécessite un opérateur désigné et un processus testé

La révocation n'est pas un réglage que l'on active une fois. C'est une action que quelqu'un doit pouvoir effectuer sous pression, lorsque le tableau de bord du fournisseur est lent et que personne ne se rappelle quel compte a autorisé l'intégration.

Donnez au propriétaire du compte et à son remplaçant désigné un moyen direct de révoquer l'autorisation. Lorsqu'ils la révoquent, votre couche d'action doit supprimer le jeton d'actualisation local, invalider les jetons d'accès en cache et arrêter les sessions qui pourraient continuer à demander cette autorisation. Désactiver l'interface de l'agent tout en laissant l'identifiant stocké ne constitue pas une révocation complète.

La RFC 7009 définit une demande de révocation d'un jeton OAuth. Le fournisseur publie son propre point de terminaison, mais la demande ressemble généralement à ceci :

POST /revoke HTTP/1.1
Host: authorization.example
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <client authentication>

token=<refresh-token>&token_type_hint=refresh_token

La RFC 7009 demande aux serveurs de renvoyer une réponse positive même lorsque le jeton soumis est déjà invalide ou inconnu. Ce comportement empêche un attaquant d'utiliser le point de terminaison comme oracle de validité. Il signifie aussi que l'opérateur ne peut pas interpréter à lui seul le succès HTTP comme la preuve que l'autorisation disposait encore d'un accès actif. Notez que la demande de révocation a été envoyée, supprimez l'identifiant local, puis vérifiez avec un appel fournisseur sans risque ou dans la trace d'audit du fournisseur si elle existe.

Préparez la révocation pour les événements suivants : départ du propriétaire du compte, suspicion de compromission d'une session d'agent, instruction d'un dépôt ayant provoqué un appel externe inattendu, retrait d'une intégration ou signalement d'une réutilisation de jeton par un fournisseur. N'attendez pas une fuite pour décider qui a le droit d'appuyer sur le bouton.

Un jeton d'accès déjà émis peut rester utilisable jusqu'à son expiration. Certains fournisseurs le révoquent immédiatement, d'autres non. Votre couche locale peut cesser immédiatement d'émettre de nouvelles actions, ce qui est le contrôle que vous maîtrisez. Ne promettez pas une invalidation mondiale instantanée sans documentation du fournisseur et sans l'avoir testée.

Séparez la révocation chez le fournisseur de la désactivation locale. La désactivation locale empêche votre couche d'action d'utiliser une autorisation. La révocation auprès du fournisseur lui demande de la refuser également. Pendant un incident, faites les deux dans cet ordre : coupez d'abord votre propre chemin d'exécution, puis envoyez la demande au fournisseur. La première étape dépend de vous et ne doit pas attendre un appel réseau externe.

Un enregistrement d'audit doit expliquer l'intention, pas seulement le trafic

Une liste d'appels HTTP ne permet pas de savoir si une actualisation était légitime. Il vous faut un enregistrement qui relie la décision humaine, la session de l'agent demandeur, la référence de l'autorisation et l'action externe obtenue.

N'écrivez pas les jetons d'actualisation, les jetons d'accès, les codes d'autorisation, les assertions client ni les corps complets des API dans le journal d'audit. Les chaînes de jetons sont des secrets. Les corps de réponse complets peuvent contenir des données client, le contenu de dépôts ou des informations personnelles. Les journaliser par commodité crée un second stockage de secrets et de données, plus difficile à maîtriser.

Un événement utile contient un identifiant d'événement, l'heure, l'identifiant de session, l'identité du processus demandeur, l'identifiant d'autorisation, la référence du compte connecté, le nom de l'opération, l'hôte du fournisseur, la ressource demandée, l'ensemble des périmètres enregistré lors de la connexion, la référence d'approbation, la classe de résultat et un code d'erreur le cas échéant. Pour une actualisation, indiquez qu'elle a eu lieu et si elle a réussi. La valeur du jeton n'est pas nécessaire pour l'enquête.

La différence entre un enregistrement d'action et un enregistrement d'identifiant est importante. Le premier indique qu'une session d'agent donnée a demandé l'état d'un déploiement dans un environnement nommé et que la couche d'action l'a autorisé. Le second indique quelle autorisation a soutenu la demande et qui en est responsable. Gardez les deux reliés par un identifiant d'autorisation opaque, mais ne permettez pas à tout opérateur pouvant consulter l'historique des actions de voir les détails de connexion du compte.

La preuve d'intégrité améliore la qualité d'une enquête. Si un processus local compromis peut modifier le même journal que celui dans lequel il écrit, l'attaquant peut effacer les entrées importantes. Utilisez un traitement d'événements en ajout uniquement avec des contrôles d'intégrité, et vérifiez le journal indépendamment du processus qui l'a généré.

Sallyport produit ses journaux Sessions et Activité à partir d'un journal d'audit chiffré et chaîné par hachage, et sp audit verify vérifie cette chaîne hors ligne sans clé du coffre.

Examinez le comportement selon un calendrier adapté au pouvoir de l'autorisation. Une autorisation personnelle pour un outil de tickets peut être examinée de temps en temps. Une autorisation capable de modifier l'infrastructure de production doit être revue après chaque nouvelle connexion, chaque changement de périmètre et tout comportement inattendu de l'agent. La couche d'action doit rendre les enregistrements suffisamment lisibles pour qu'un responsable puisse répondre à la question : « Quel agent a utilisé mon compte, pour quoi faire et avec quelle approbation ? »

Les profils de navigateur et les courtiers de jetons génériques créent des contournements discrets

Un profil de navigateur est un mauvais espace de stockage pour les identifiants d'un agent. Il peut contenir des cookies de session, des jetons d'accès en cache, des jetons d'actualisation, des sélecteurs de compte et un état de navigation sans rapport. Donner à un agent l'accès à ce profil est plus large que lui déléguer une seule action API, et le nettoyage devient difficile parce que l'état du fournisseur et celui du navigateur se mélangent.

Un courtier de jetons générique peut créer le même problème s'il accepte des paramètres arbitraires du point de terminaison de jeton. Les équipes construisent souvent une API appelée getToken(scope) et se sentent plus en sécurité parce que le jeton n'est plus dans le processus de l'agent. Le courtier devient tout de même un distributeur de jetons si chaque session peut demander n'importe quel compte connecté ou n'importe quel périmètre.

Faites demander une opération à l'appelant, pas un jeton. « Créer une note de version dans le projet A » a un responsable, une destination et une exigence de périmètre que vous pouvez examiner. « Donne-moi un jeton pour tracker.write » laisse trop d'autorité à l'appelant.

Ne résolvez pas ce problème avec un moteur de règles gigantesque avant de comprendre vos opérations. Un catalogue court d'actions approuvées, associé à des autorisations nommées et à des points d'approbation humaine, est plus facile à examiner et plus difficile à contourner. N'ajoutez de la complexité que lorsqu'un besoin réel l'exige.

Résistez aussi à l'habitude de partager un même jeton d'actualisation entre le développement, la préproduction et la production. Des autorisations séparées rendent la révocation moins grave et les enregistrements d'audit moins ambigus. Un agent de préproduction ne doit pas conserver un chemin vers la production simplement parce que les deux environnements utilisent le même fournisseur d'identité.

Commencez par un tableau de propriété et un exercice de révocation

Le premier livrable utile est un inventaire des autorisations, pas du code. Créez une ligne pour chaque jeton d'actualisation que vos agents pourraient utiliser. Indiquez le fournisseur, la référence du compte, l'identifiant d'autorisation, les périmètres, l'emplacement de la couche d'action, le responsable du compte, le remplaçant chargé de la révocation, la méthode de création, la dernière utilisation confirmée et la procédure locale de désactivation. Si vous ne pouvez pas remplir une colonne, vous ne contrôlez pas encore cette autorisation.

Organisez ensuite un exercice de révocation avec une intégration peu risquée. Demandez au responsable de désactiver l'autorisation localement, de la révoquer chez le fournisseur, puis tentez une action ordinaire avec un agent. Vérifiez que la couche d'action bloque la demande, qu'une reconnexion exige une action humaine explicite et que la piste d'audit identifie la session précédente. Cet exercice révèle rapidement les hypothèses fragiles : points de terminaison du fournisseur introuvables, propriété du compte inconnue, jetons stockés sur d'anciens ordinateurs de développeurs et jetons d'accès en cache qui restent valides plus longtemps que prévu localement.

Définissez une date de réexamen pour les autorisations qui ne sont pas limitées par le fournisseur. Un accès de longue durée est parfois nécessaire pour un travail sans surveillance, mais un accès indéfini doit rester une exception volontaire, avec un responsable désigné. Lorsqu'une équipe ne peut pas nommer ce responsable, l'autorisation ne doit plus rester utilisable.

La règle à retenir est simple : un agent peut demander du travail, mais il ne doit pas hériter de la capacité d'un compte à se renouveler indéfiniment. Placez l'identifiant d'actualisation là où une personne peut contrôler son utilisation, et faites de la révocation une action répétée et maîtrisée plutôt qu'une recherche urgente dans des onglets de navigateur.