Fiche d’inventaire des identifiants pour les agents IA de programmation

Les agents IA de programmation ne devraient pas recevoir un tas d’identifiants hérités accompagné d’une consigne vague leur demandant d’être prudents. Avant qu’un agent appelle une API, déploie un service ou ouvre une connexion SSH, quelqu’un doit disposer d’un document indiquant à quoi l’identifiant donne accès, qui en assume la responsabilité et comment l’équipe pourra le désactiver.

Une fiche d’inventaire des identifiants ressemble à une tâche administrative jusqu’au jour où un agent effectue vingt appels pendant que son opérateur est loin du clavier. Elle devient alors la différence entre révoquer une capacité connue et désactiver la moitié de l’organisation technique parce que personne ne sait identifier le jeton. J’ai vu des équipes découvrir que leur automatisation de « staging » possédait un jeton d’écriture en production seulement après qu’une modification automatique eut été appliquée au mauvais endroit.

L’inventaire doit décrire l’autorité, pas les chaînes secrètes

Une fiche d’inventaire des identifiants décrit une autorité. Elle ne contient ni jeton API, ni matériel SSH privé, ni mot de passe, ni code de récupération, ni export chiffré de ces éléments. Si une fiche peut authentifier quoi que ce soit, elle est devenue un autre coffre de secrets, avec des contrôles d’accès plus faibles et un public bien plus large.

Cette distinction compte, car les équipes confondent souvent un identifiant et un identifiant d’accès. Les quatre derniers caractères d’un jeton API aident un opérateur à retrouver la bonne entrée lors d’une rotation. Ils ne permettent pas de savoir si le jeton peut supprimer un projet. L’empreinte d’une clé publique SSH identifie une identité. Elle ne dit pas à quel compte Unix elle donne accès, si elle autorise le transfert de ports ni quels hôtes lui font confiance.

Utilisez une ligne pour chaque autorité pouvant être révoquée indépendamment. Un même compte fournisseur peut nécessiter plusieurs lignes : un jeton de consultation des rapports de production, un jeton de déploiement en staging, un jeton d’administrateur de secours que les agents ne peuvent pas utiliser et un secret de signature de webhook. Les regrouper sur une seule ligne fait disparaître leurs niveaux de risque et leurs exigences de rotation différents.

La même règle s’applique à SSH. N’écrivez pas « Git et serveurs » dans une seule cellule parce qu’une même clé privée fonctionne par hasard aux deux endroits. Une identité d’écriture dans un outil de gestion de code et une identité de connexion à un hôte ont des conséquences différentes. Elles nécessitent des lignes distinctes, même si la même personne les a créées le même après-midi.

La publication NIST SP 800-57 Part 1 traite la gestion des clés cryptographiques comme un cycle de vie : génération, distribution, stockage, utilisation, remplacement et destruction doivent tous être contrôlés. Le document porte sur les clés cryptographiques, mais sa méthode s’applique directement à ce sujet. Une liste qui s’arrête à « nous avons créé un jeton » n’est pas un inventaire. C’est un aide-mémoire qui échoue précisément au moment où le personnel a besoin de documents fiables.

Donnez à chaque identifiant un responsable clairement désigné

Chaque ligne doit avoir un propriétaire nommé, capable de répondre à la question : « Cette autorité doit-elle encore exister ? » Cette personne n’a pas besoin de gérer le coffre de secrets ni d’écrire l’intégration de l’agent. Elle doit toutefois connaître suffisamment le système concerné pour approuver l’accès et en accepter les conséquences opérationnelles.

Évitez les valeurs telles que « plateforme », « équipe de développement », « partagé » ou le nom d’un ancien salarié. Un groupe peut gérer un processus, mais son nom ne dit pas à la personne qui répond à un incident qui appeler à deux heures du matin. Enregistrez un responsable principal et, si nécessaire, un remplaçant autorisé à révoquer ou remplacer l’identifiant.

Séparez quatre rôles que les équipes mélangent régulièrement :

• Le propriétaire du système décide si l’accès reste approprié.
• Le dépositaire de l’identifiant peut créer, stocker, révoquer et renouveler celui-ci.
• L’opérateur de l’agent démarre ou supervise son exécution.
• Le contact d’incident gère une défaillance urgente lorsque les trois premières personnes sont indisponibles.

Dans une petite équipe, une même personne peut cumuler plusieurs rôles. La fiche doit tout de même les nommer séparément. Lorsqu’un jeton cesse de fonctionner pendant une mise en production, le dépositaire peut corriger le stockage tandis que le propriétaire du système décide si un remplacement temporaire mérite la même portée.

Pour une API de fournisseur, la responsabilité revient souvent à l’équipe qui paie le compte ou l’exploite, et non au développeur qui a copié le premier jeton dans un fichier de configuration local. Pour un accès SSH, elle revient généralement au propriétaire de l’hôte ou de l’application, et non à la personne qui a généré la paire de clés. Cela semble évident, mais les identifiants orphelins sont souvent nés d’un raccourci raisonnable pris par une personne qui a ensuite changé d’équipe.

Ajoutez une date de revue distincte de la date de rotation du secret. Un jeton peut rester techniquement valide alors que son objectif métier a disparu. La revue vérifie si l’accès doit exister. La rotation remplace un matériel qui a pu vieillir ou fuiter. L’une ne remplace pas l’autre.

Décrivez les actions autorisées avec des verbes et des cibles

« Accès à la production » ne décrit pas une permission. C’est une étiquette d’avertissement qui n’apprend rien d’utile à l’opérateur de l’agent. La fiche doit contenir des verbes, des ressources cibles et des limites qu’un réviseur peut vérifier.

Écrivez les permissions sous cette forme :

verbe + cible + limite + action interdite

Par exemple :

• GET /v1/projects/acme/builds dans staging ; aucune demande vers les tenants de production
• POST des révisions de déploiement pour le service catalog-api ; aucun retour en arrière ni suppression
• SSH avec le compte deploy sur le groupe d’hôtes de build ; exécuter uniquement la commande de mise en production approuvée ; aucun shell interactif
• Créer des commentaires d’incident dans le dépôt alpha ; aucune fusion, suppression de branche ni modification des paramètres

C’est plus utile qu’une étiquette générale du fournisseur telle que « écriture ». Un agent capable de créer une révision de déploiement et un agent capable de supprimer un déploiement ont tous deux une permission d’écriture, mais l’ampleur des dommages possibles est très différente.

Indiquez si l’action prévue consiste à lire, créer, modifier, supprimer, exécuter ou changer un paramètre d’administration. « Exécuter » demande une attention particulière. Un appel API qui démarre une tâche cloud, renouvelle un identifiant de service, déclenche une opération de paiement ou lance un shell distant peut sembler anodin dans un journal de requêtes tout en produisant un résultat coûteux ou irréversible en aval.

Ne transformez pas la fiche en document juridique rempli de formulations floues. « Utiliser uniquement lorsque c’est approprié » et « travail normal de déploiement » ne fixent aucune limite. Une personne ne peut pas approuver ces formulations et un ingénieur ne peut pas en tirer des contrôles. Si l’action dépend du contexte, indiquez ce contexte : environnement, dépôt, groupe d’hôtes, compte ou type de changement précis.

Le raccourci le plus répandu consiste à accorder un jeton d’administrateur général et à compter sur l’invite de l’agent pour éviter les appels dangereux. Il est populaire parce qu’il permet de lancer un prototype en quelques minutes. Il est mauvais parce que les invites ne sont pas des contrôles d’accès et que les appels d’outils ultérieurs peuvent hériter de cette autorité étendue sans que la personne qui a écrit l’invite s’en aperçoive.

Les environnements nécessitent des lignes et des conséquences distinctes

Un identifiant de staging et un identifiant de production ne devraient jamais partager une ligne simplement parce qu’ils appellent la même API. Leurs propriétaires peuvent être les mêmes, mais leur compte cible, l’exposition des données, le niveau d’approbation et l’urgence de la révocation diffèrent souvent.

Considérez l’environnement comme davantage qu’une simple étiquette. Indiquez le compte ou le tenant du fournisseur, le point d’accès ou le groupe d’hôtes, la classification des données et la possibilité qu’un appel franchisse une frontière d’environnement. « Prod » est trop vague lorsqu’une organisation possède plusieurs comptes, régions ou partitions client en production.

Un champ d’environnement exploitable pourrait être :

production / tenant 4821 / données de compte client / endpoint api.example.internal

Ne placez pas un véritable nom d’hôte interne dans une fiche accessible à de nombreuses personnes si ce nom est lui-même sensible. Le but est de nommer la cible avec assez de précision pour l’équipe autorisée. La politique d’accès à l’inventaire doit correspondre à la sensibilité de ses informations opérationnelles.

Ajoutez un champ distinct pour les données qu’un agent peut recevoir dans la réponse. Le droit d’appeler un endpoint et le droit de consulter sa réponse sont des risques liés, mais différents. Une demande de lecture peut renvoyer du code source, des coordonnées client, des factures, des métadonnées d’accès ou un secret intégré à une ancienne valeur de configuration.

Cela permet de repérer un échec fréquent. Une équipe crée un identifiant d’agent pour des « diagnostics en lecture seule » dans staging. Plus tard, pendant un incident, un ingénieur pointe le client de diagnostic vers la production parce que la syntaxe de commande est identique. L’identifiant fonctionne, car le fournisseur applique une portée à tout le compte, et l’agent renvoie des données client dans sa transcription. La ligne d’origine aurait révélé l’absence de limite si elle avait nommé le tenant et les données de réponse au lieu de dire simplement « lecture des diagnostics ».

Lorsqu’un fournisseur ne peut pas isoler les environnements, ne compensez pas cette lacune par une documentation optimiste. Marquez l’identifiant comme inter-environnements, augmentez son niveau d’approbation et décidez si un agent doit réellement l’utiliser. La réponse honnête est parfois non.

L’accès SSH demande plus de détails que l’accès API

Les identifiants SSH méritent leurs propres champs, car une connexion SSH peut transporter plusieurs types d’autorité à la fois. Le compte de connexion, les hôtes acceptés, les restrictions de commande, les permissions de transfert et l’activation du transfert d’agent modifient tous ce que la connexion peut faire.

Pour chaque ligne SSH, indiquez l’empreinte de la clé publique, l’emplacement du matériel privé, le compte de connexion, l’hôte ou le groupe d’hôtes et la commande exacte prévue. Ne copiez pas la clé privée dans la fiche. Une empreinte SHA256 suffit pour l’identification, et les opérateurs peuvent la calculer localement.

Exécutez cette commande sur le fichier de clé publique :

ssh-keygen -lf ~/.ssh/id_agent_deploy.pub

Un résultat normal a cette forme :

256 SHA256:AbCdEfGhIjKlMnOpQrStUvWxYz0123456789abcd agent-deploy (ED25519)

Conservez la valeur SHA256: et le commentaire seulement si celui-ci aide les personnes à identifier le rôle. Les commentaires ne sont pas des contrôles de sécurité. N’importe qui peut en modifier un en copiant une clé publique.

Pour les hôtes cibles, examinez les restrictions de authorized_keys au lieu de supposer qu’un compte de déploiement est limité parce que c’est l’intention des utilisateurs. OpenSSH documente des options telles que command=, no-port-forwarding, no-agent-forwarding et no-pty dans le manuel de sshd. Ces restrictions peuvent transformer une identité d’automatisation en exécuteur de commandes limité. Elles ne peuvent pas corriger un identifiant qui se connecte comme administrateur sans restriction.

Une entrée pourrait indiquer : « connexion avec deploy, hôtes du groupe de mise en production A, commande forcée /usr/local/bin/release-catalog, aucun transfert de port, aucun PTY, aucun transfert d’agent ». Si l’accès doit disposer d’un shell interactif pour les urgences, créez une identité distincte, utilisée par une personne. Ne réutilisez pas discrètement l’identité de l’agent parce qu’elle est déjà disponible.

La vérification des hôtes doit aussi figurer dans la fiche. Notez comment l’intégration côté agent vérifie l’identité de l’hôte, où se trouvent les entrées known-hosts et qui les met à jour après le remplacement légitime d’un hôte. Désactiver la vérification pour contourner un problème après une reconstruction revient à envoyer un identifiant valide à la mauvaise machine.

Une fiche exploitable impose des réponses précises

Copiez ce modèle dans un document contrôlé, un système de tickets ou une base d’inventaire. Supprimez les colonnes que votre équipe ne peut pas maintenir, mais gardez celles qui établissent l’autorité, la portée et la récupération.

La colonne chemin de l’agent impose une question utile : comment l’agent obtient-il l’effet de cet identifiant ? « Variable d’environnement dans le shell de programmation » est une réponse, mais elle devrait vous inquiéter, car le processus peut l’afficher, la transmettre ou la conserver. « La passerelle d’actions exécute la demande et renvoie la réponse » décrit une autre conception, avec un chemin d’exposition plus réduit.

Le champ méthode de révocation doit pouvoir être utilisé par une autre personne. « Demander à Sam » n’est pas une méthode. « Désactiver le jeton dans les paramètres du projet du fournisseur, puis révoquer la session active de l’agent » en est une. Testez cette instruction lorsque vous ajoutez la ligne, avant qu’un incident ne rende chaque page de console inconnue.

Évitez un champ d’état qui indique seulement actif ou inactif. Ajoutez dernière utilisation, dernière revue et retrait prévu. Un identifiant inutilisé n’est pas inoffensif. C’est souvent celui que personne ne pense à révoquer à la fin d’un projet.

Les plans de rotation doivent prévoir le remplacement et la preuve

La rotation est terminée uniquement lorsque l’ancien identifiant est désactivé et que le remplacement a effectué une action prévue via le véritable chemin de l’agent. Créer un nouveau jeton, l’ajouter au stockage et promettre de revenir plus tard sur l’ancien laisse les deux identités actives. Cela double le travail pendant un incident.

Un plan de rotation doit préciser cinq faits opérationnels :

1. L’événement qui déclenche la rotation, par exemple une expiration planifiée, le départ d’un membre du personnel, une fuite présumée ou un changement de portée.
2. La personne qui crée le remplacement et celle qui approuve la modification de l’autorité.
3. L’endroit où le nouveau matériel est stocké sans parvenir à l’agent.
4. L’action de test limitée qui prouve que le remplacement fonctionne.
5. Le moment exact où l’ancien matériel est révoqué et où la preuve est enregistrée.

Utilisez un test limité. Pour un identifiant HTTP, appelez un endpoint sans risque qui exige la portée prévue et vérifiez le statut et la forme de réponse attendus. Pour SSH, exécutez la commande forcée d’état du déploiement sur le groupe d’hôtes approuvé, plutôt que de tester avec une connexion shell générale.

Une fiche de test peut être aussi simple que celle-ci :

Credential ID: api-catalog-deploy-prod-01
Replacement ID suffix: ...7KQ2
Test: POST /deployments/validate for catalog-api revision 8f3c
Expected: HTTP 200 with validation status accepted
Old credential revoked: provider audit event recorded
Reviewer: production service owner

Ne définissez pas de calendriers de rotation que votre équipe ne peut pas respecter. Un intervalle court assorti d’exceptions répétées apprend aux équipes à considérer l’inventaire comme une fiction. Utilisez l’expiration proposée par le fournisseur lorsqu’elle existe, prévoyez des déclencheurs liés aux événements et choisissez une cadence de revue adaptée au risque. Un accès d’écriture en production, un accès étendu à des données sensibles et un accès SSH à des hôtes partagés méritent plus d’attention qu’un jeton de staging temporaire sans données sensibles dans la réponse.

Si une fuite est suspectée, révoquez d’abord lorsque le service peut le supporter. Les équipes perdent du temps à chercher à prouver qu’un jeton divulgué a été copié depuis un tampon de terminal, un journal CI, une transcription d’invite ou un historique local. Cette preuve est rarement nécessaire avant d’arrêter l’identifiant. Conservez les journaux, remplacez l’identifiant, puis recherchez le chemin de fuite.

L’approbation de l’agent doit suivre les conséquences de l’appel

Une exécution d’agent possède un cycle de vie que les scripts ordinaires n’ont souvent pas : une personne peut la démarrer, la laisser travailler, revenir plus tard et découvrir qu’elle a effectué de nombreux appels externes. La fiche doit donc préciser quand une autorisation humaine s’applique, et pas seulement à qui appartient l’identifiant.

L’approbation par session convient à une exécution limitée, avec un processus d’agent local identifié et fiable, ainsi que des conséquences faibles ou modérées. Elle confirme que ce processus peut utiliser les autorités répertoriées pendant qu’il reste actif. Elle ne signifie pas que tous les appels futurs sont automatiquement autorisés.

Demandez une approbation à chaque utilisation pour les opérations qui peuvent publier, déployer, modifier des données de production, atteindre des réponses très sensibles ou créer un nouvel engagement externe. Un clic supplémentaire coûte moins cher que l’explication d’une action involontaire à un client ou à une équipe financière. Lorsque le fournisseur le permet, utilisez un identifiant distinct pour les actions soumises à un autre niveau d’approbation.

L’approbation ne remplace pas la limitation de portée. Une personne peut approuver la mauvaise action parce que la description de la demande était vague, que l’action est survenue pendant un incident ou que l’agent a effectué plusieurs appels similaires à la suite. Commencez par limiter les permissions, puis utilisez l’approbation pour couvrir le risque résiduel que la portée ne peut pas exprimer.

Sallyport conserve les identifiants API et SSH dans un coffre chiffré sur Mac et peut demander une autorisation pour un nouveau processus d’agent ou à chaque utilisation d’un identifiant choisi, tandis que l’agent reçoit les résultats plutôt que les secrets.

Une bonne fiche relie chaque ligne à haut risque aux preuves d’audit attendues après utilisation. Enregistrez l’identifiant de session ou l’emplacement du journal d’exécution, l’activité au niveau des appels, la cible, l’horodatage, le résultat et, le cas échéant, la personne qui a approuvé. Si les preuves ne permettent pas de savoir quel identifiant a été utilisé pour quel résultat, l’intégration de l’agent est trop opaque pour l’autorité accordée.

Les journaux d’audit tranchent les débats après une mauvaise exécution

L’inventaire est un travail préventif. Les journaux d’audit répondent à une autre question après un comportement inattendu de l’agent : qu’a-t-il réellement tenté, qu’est-ce qui a réussi et quelle autorité l’a rendu possible ? Ne confondez pas ces fonctions. Une fiche soigneusement tenue ne peut pas prouver qu’un appel a eu lieu, et un journal ne peut pas prouver qu’une permission était justifiée.

Organisez un exercice d’incident autour d’une ligne d’inventaire. Demandez à un opérateur de trouver le propriétaire, révoquer l’identifiant, arrêter tout accès actif de l’agent, identifier le dernier appel réussi et vérifier que la piste d’audit n’a pas changé. Mesurez la confusion, pas le temps écoulé. Si personne ne peut nommer le compte cible ou distinguer l’ancien jeton du remplacement, corrigez les champs de la fiche.

Les preuves d’altération comptent lorsque plusieurs personnes peuvent consulter ou exporter les journaux. Une base en ajout uniquement peut être modifiée par un administrateur disposant de suffisamment d’accès, puis présentée comme l’historique. Un journal chaîné par hachage rend les modifications non autorisées détectables lorsque vous vérifiez la chaîne par rapport à la séquence conservée. Cela ne rend pas la demande initiale judicieuse et n’empêche pas une personne autorisée de faire un mauvais appel. Ce sont des contrôles distincts.

Conservez la décision relative à la durée de rétention de l’audit avec la fiche d’inventaire, surtout lorsque les réponses peuvent contenir des données sensibles. Un relevé d’activité doit conserver assez de contexte pour permettre une enquête sans garder inutilement des charges utiles client complètes pour toujours. Stockez si possible les métadonnées de la demande et le statut du résultat ; réservez la capture complète de la réponse aux cas où elle est réellement nécessaire et autorisée.

La première ligne d’identifiant à remplir devrait être celle qu’un agent peut utiliser aujourd’hui pour modifier la production. Nommez précisément sa cible, rendez le verbe autorisé concret, écrivez l’instruction de révocation afin qu’une autre personne puisse la suivre et testez le parcours de remplacement. Si cette ligne contient des suppositions, le reste de l’inventaire n’est que de la décoration.