Des comptes de service pour les agents d'IA sans responsabilité partagée

Les agents d'IA ont besoin de comptes de service, mais un compte de service ne doit jamais devenir le nom que vous utilisez lorsque vous ignorez qui a autorisé une action. Donnez à chaque workflow durable sa propre identité, associez-lui une personne nommée et supprimez-la lorsque le workflow s'arrête. Toute solution moins rigoureuse crée une responsabilité partagée, autrement dit personne ne peut fournir une réponse complète après une mauvaise décision.

J'ai vu ce problème se reproduire. Une équipe crée un compte appelé automation, lui donne assez d'accès pour débloquer plusieurs tâches de programmation et présente la configuration comme temporaire. Quelques mois plus tard, un job de déploiement, un outil de mise à jour des dépendances et un agent qui modifie l'infrastructure l'utilisent tous. Le compte reste actif, car le désactiver pourrait casser quelque chose. Lorsqu'il modifie un réglage de production, les journaux identifient parfaitement automation et n'expliquent presque rien.

La solution n'est pas un grand programme de gestion des identités. Elle repose sur quelques limites fermes : une identité de workflow pour un objectif d'autorisation, un propriétaire humain capable de l'approuver ou de l'arrêter, des preuves reliant chaque utilisation à une exécution précise et une procédure de sortie conçue avant l'attribution des accès.

Un compte de service identifie une autorité, pas l'acteur

Un compte de service indique quel ensemble d'autorisations une API ou un système a accepté. Il ne prouve pas quel agent, prompt, révision du code ou humain a provoqué la requête. Les équipes confondent régulièrement ces deux fonctions, puis découvrent que leur piste d'audit ne permet pas d'expliquer un incident.

Supposons que release-publisher puisse publier des artefacts de build. Une requête réussie authentifiée avec ce compte indique que l'autorité de publication a été utilisée. Elle ne dit pas si la requête venait d'un workflow de livraison approuvé, d'un script local lancé par un développeur ou d'un agent qui a relancé une ancienne tâche après le départ de son propriétaire humain. L'enregistrement d'authentification répond à « quelle autorité ? ». Il ne répond pas à « pourquoi cet appel, dans cette exécution, maintenant ? »

Gardez les niveaux séparés :

• L'identité du workflow détient une autorité définie avec précision.
• La session de l'agent identifie une exécution de processus particulière.
• L'approbation humaine ou le déclencheur automatisé explique qui a démarré ou autorisé cette exécution.
• L'enregistrement de l'action contient la cible, l'opération demandée, le résultat et l'heure.

Cette distinction change la manière d'enquêter. Si un appel de déploiement semble incorrect, désactivez d'abord l'identité du workflow pour empêcher toute nouvelle utilisation de l'autorité. Examinez ensuite l'enregistrement de session afin de trouver le processus qui l'a utilisée, la révision du code exécutée et la personne ou le système qui a autorisé la session. Un seul nom de compte ne peut pas porter tout cet historique sans devenir un conteneur partagé.

La RFC 6749 énonce une idée utile mais limitée dans sa description du flux OAuth 2.0 client credentials : un client peut utiliser ses identifiants comme autorisation lorsqu'il agit pour son propre compte. C'est juste pour un workload machine limité. Cela ne signifie pas que chaque processus capable de présenter l'identifiant a le même objectif légitime. C'est en considérant cette autorisation comme une responsabilité complète que les équipes se mettent en difficulté.

Un agent présente aussi un profil de risque différent de celui d'un job classique. Un job classique suit généralement un chemin de code fixe. Un agent peut choisir des commandes, construire des requêtes, réessayer avec des arguments modifiés ou être influencé par des éléments lus dans un dépôt. Le compte de service doit conserver un objectif stable même lorsque les choix de l'appelant varient. Si vous ne pouvez pas écrire cet objectif en une phrase simple, le compte a probablement accumulé des tâches sans rapport.

Un workflow, une identité limitée

Un workflow mérite sa propre identité lorsqu'il a un objectif, une limite d'autorisation, un propriétaire, un environnement ou une condition de fin distincts. Ne créez pas un compte pour chaque prompt ou chaque tâche courte. Vous obtiendriez du bruit sans meilleur contrôle. Créez des identités au niveau où vous pouvez révoquer une unité d'autorité sans interrompre le travail indépendant.

« Mettre à jour les manifestes de dépendances dans les dépôts approuvés » et « publier des artefacts signés en production » ne doivent pas utiliser la même identité. Le premier workflow modifie des fichiers source et ouvre des demandes de revue. Le second modifie un canal de livraison. Même si un même agent peut lancer les deux, les autorisations diffèrent, la personne qui doit les approuver peut différer et la réponse à une action suspecte est certainement différente.

L'erreur inverse fait aussi perdre du temps : diviser un workflow étroit en dizaines de noms de comptes parce que chaque exécution d'agent en crée un. Les identifiants d'exécution décrivent déjà les exécutions courtes. Les identités de comptes de service doivent décrire un objectif d'autorisation durable. Utilisez les enregistrements de session pour les exécutions individuelles et les comptes pour l'autorité qui persiste d'une exécution à l'autre.

Un modèle de nommage pratique est le suivant :

<environment>.<product-or-repository>.<workflow-purpose>

prod.payments.release-publisher
dev.docs.dependency-updater
prod.data.backfill-reader

Les noms aident les personnes, mais ils ne font pas respecter la portée. Liez chaque identité uniquement aux actions dont son workflow a besoin. Donnez à l'outil de mise à jour des dépendances l'autorisation de créer une branche et d'envoyer une demande de revue si c'est tout ce qu'il fait. Ne lui accordez pas les autorisations de livraison parce qu'il pourrait en avoir besoin un jour. Le « pourrait » a créé davantage d'accès permanents que n'importe quel besoin réel.

Utilisez des identités distinctes pour les environnements distincts. Un agent de développement peut expérimenter, réessayer agressivement et travailler sur des données jetables. Ce comportement n'a pas sa place sous une identité de production. Copier un identifiant de production dans une configuration de développement inverse la limite : l'environnement le moins contrôlé possède alors l'autorité la plus forte.

Il existe une exception légitime à cette séparation stricte : deux appels peuvent partager une identité lorsqu'ils font partie du même workflow documenté, ont le même propriétaire, utilisent le même ensemble d'autorisations et se terminent selon la même condition de retrait. Le test est pratique. Si désactiver le compte vous fait demander « lequel de ces jobs sans rapport vient de tomber ? », le compte couvre trop de choses.

Le propriétaire doit être une personne capable d'arrêter le travail

Chaque identité de workflow a besoin d'un propriétaire humain nommé, doté de l'autorité et de l'obligation d'en répondre. Un contact technique peut aider à exploiter le workflow et une équipe peut assurer la continuité, mais aucun des deux ne remplace un propriétaire précis.

Le propriétaire accomplit quatre tâches concrètes. Il confirme que le workflow a toujours un objectif, approuve les modifications de ses accès, réagit lorsqu'un appel suspect apparaît et retire l'identité lorsque le travail se termine. Si le propriétaire indiqué ne peut pas accomplir ces tâches, la fiche n'est que décorative.

Le contrôle AC-2 sur la gestion des comptes de la norme NIST SP 800-53 Revision 5 demande aux organisations de définir les types de comptes, d'établir les conditions d'appartenance aux groupes et aux rôles et de désactiver les comptes lorsqu'ils ne sont plus associés à un utilisateur ou ne sont plus nécessaires. Ce contrôle s'applique clairement aux comptes non humains, même si on le lit souvent comme une consigne concernant les comptes des employés. Une identité machine sans responsable identifiable n'a personne pour fixer ces conditions ni décider qu'elle n'est plus nécessaire.

Placez la fiche du compte dans un dépôt ou un registre utilisé par le processus de revue des accès. Ne l'enfouissez pas dans une page wiki qui diverge de la liaison réelle. Cette fiche minimale contient assez de champs pour permettre une revue sérieuse :

identity: prod.payments.release-publisher
owner: "Morgan Lee"
technical_contact: "Release engineering on-call"
purpose: "Publish approved signed payment service artifacts to production"
allowed_actions:
  - "upload signed artifact to production release repository"
  - "read release metadata for the payment service"
environments:
  - production
permission_bindings:
  - "artifact-repository/publish-payments-prod"
credential_method: "short lived workload token"
source_repository: "payments-service"
review_after: "2026-06-30"
retire_when: "The payment service stops using this release workflow"
incident_contact: "Release engineering on-call"

La fiche rend l'ambiguïté visible. Si allowed_actions devient un paragraphe qui mentionne plusieurs systèmes et des verbes vagues comme « gérer » ou « administrer », séparez le workflow. Si retire_when indique « jamais » ou ne contient aucune condition, le compte a rejoint le stock des accès permanents. Si le champ du propriétaire contient une liste de diffusion, attribuez le compte à une personne avant d'accorder l'accès.

Les changements de propriétaire doivent avoir leur propre contrôle. Un salarié qui part ne doit pas rester le propriétaire nominal parce que transférer la fiche semble fastidieux. Exigez que le nouveau propriétaire accepte le compte, lise son objectif et ses liaisons, puis fixe la prochaine date de revue. Si personne ne l'accepte, désactivez-le. Les systèmes ne bénéficient d'aucune exemption en matière de propriété simplement parce qu'ils continuent de fonctionner.

Les comptes partagés transforment un petit incident en jeu de devinettes

Un compte partagé échoue le plus visiblement lors d'un incident d'apparence ordinaire, pas forcément lors d'une violation spectaculaire. Imaginez une équipe qui utilise prod.agent-ops pour trois workflows : un agent de livraison, un agent de synthèse d'incidents et un agent de réparation de l'infrastructure. Le compte peut lire l'état du déploiement, modifier une variable d'environnement et déclencher un retour en arrière.

À 16 h 20, quelqu'un remarque qu'une variable d'environnement a pris une valeur invalide. Le journal de l'API indique que la requête vient de prod.agent-ops. L'équipe de livraison dit que son exécution s'est terminée plus tôt. L'équipe chargée des incidents affirme que son agent lisait l'état mais ne pense pas avoir écrit de réglages. Le responsable de l'infrastructure dit qu'un prompt de réparation a été testé dans l'après-midi, mais que personne n'a conservé la session exacte. Les trois déclarations peuvent être vraies et le journal du compte ne permet pas de trancher.

La réaction habituelle consiste à rechercher dans les discussions, l'historique du dépôt, les historiques du shell et les transcriptions du modèle. Cela peut fournir une réponse, mais la recherche est lente et incomplète. Pire encore, le même compte reste actif, car le désactiver pourrait interrompre la récupération après incident. L'incident lie désormais la détection, le confinement et des opérations de production sans rapport.

Des identités distinctes changent la séquence. Si prod.payments.release-publisher effectue un appel inattendu, désactivez cette identité. Le compte de synthèse d'incident et le compte de réparation conservent leurs propres autorités. L'enregistrement de l'action doit contenir une identité de workflow et une référence d'exécution afin que les enquêteurs puissent retrouver la session exacte sans s'appuyer sur les souvenirs. C'est pourquoi « un compte par équipe » n'est pas un compromis. C'est une décision de fusionner les domaines de défaillance.

Certaines équipes défendent les comptes partagés en affirmant que la centralisation facilite la rotation. Cela semble vrai parce qu'il n'y a qu'un identifiant à remplacer. Le gain opérationnel est faible, alors que le coût apparaît lorsqu'il faut révoquer précisément un accès, effectuer une revue des autorisations ou fournir une explication. Automatisez l'émission des identifiants et la gestion des liaisons au lieu d'élargir la frontière du compte pour des raisons de commodité.

Ne confondez pas un compte partagé avec un rôle d'autorisation partagé. Plusieurs identités peuvent recevoir le même rôle défini avec précision si elles exécutent la même opération autorisée. Les identités restent distinctes, de sorte que les journaux et la révocation continuent de fonctionner. Réutiliser un rôle facilite la gestion ; réutiliser une identité détruit l'attribution.

La portée des autorisations doit suivre les actions, pas les ambitions de l'agent

Accordez l'accès au chemin d'action précis que vous voulez autoriser, puis demandez à l'agent de justifier tout besoin supplémentaire. Les capacités générales d'un agent ne justifient pas une autorité générale.

Commencez par les verbes et les objets du workflow. « Lire les tickets ouverts du dépôt A et créer une branche dans le dépôt A » décrit une action. « Maintenir le dépôt A » n'en décrit pas une. La première formulation permet à un administrateur de trouver une portée de lecture et une portée de création de branche. La seconde se termine généralement par un accès en écriture trop large, car personne ne peut la traduire en autorisation précise.

La même rigueur s'applique aux autorisations API. Si un workflow lit un rapport et publie un commentaire, ne lui donnez pas accès à la gestion des comptes parce que l'API regroupe ces points d'accès dans un rôle général séduisant. Créez un ensemble d'autorisations plus réduit si le fournisseur le permet. Dans le cas contraire, placez un intermédiaire limité à cette action devant l'identifiant large ou demandez-vous si l'agent doit vraiment effectuer cette action sans supervision.

C'est ici que de nombreux déploiements d'agents commettent une erreur subtile. Ils accordent un accès large parce que l'agent doit examiner le contexte avant d'agir. Lire le contexte et modifier une cible sont deux autorités différentes. Donnez un accès en lecture lorsque c'est possible, puis exigez une identité ou un parcours d'approbation distinct pour les changements d'état. Un modèle capable de lire une configuration de production n'a pas automatiquement besoin de pouvoir la modifier.

Testez la limite avec des requêtes volontairement incorrectes avant de mettre le workflow en service. Pour un outil de publication, essayez de publier un artefact d'un autre produit, de supprimer une livraison et de modifier les paramètres du dépôt. Chaque requête doit échouer au niveau de l'autorisation. Un test réussi sur le chemin prévu prouve seulement que l'accès est suffisant. Le rejet des actions voisines prouve que l'accès n'est pas excessif.

Conservez le résultat du test avec la fiche de propriété. Un simple tableau suffit :

Ne laissez pas un agent choisir une identité dans un menu de comptes puissants. Le runner du workflow doit associer l'identité correspondant au job. Un agent capable de choisir entre des autorités sans rapport peut souvent contourner la limite que vous avez conçue.

Les identifiants doivent expirer avant les workflows oubliés

Les identifiants persistants rendent le retrait difficile, car une copie oubliée peut continuer à fonctionner après la désactivation du job visible. Préférez des identifiants de courte durée attribués à un runtime vérifié, ou laissez un composant contrôlé exécuter l'action authentifiée tandis que l'agent ne reçoit que le résultat.

C'est une question distincte de la conception de l'identité. Vous pouvez avoir un compte de service parfaitement nommé et attribué, puis perdre le contrôle si son identifiant se trouve dans un dépôt, un fichier d'environnement local, une transcription d'agent ou un journal de build. La fiche du compte indique qui peut utiliser l'autorité. La gestion des identifiants détermine qui peut réellement la présenter.

La séquence recommandée est simple :

1. Vérifier le runtime appelant ou la session de l'agent.
2. Émettre un identifiant à expiration courte et limité au workflow, ou exécuter l'action demandée en son nom.
3. Enregistrer l'action demandée et la décision d'autorisation.
4. Terminer la session et invalider l'autorité qui ne concernait que cette session.

Ne donnez pas un secret en clair à l'agent simplement parce qu'il doit appeler une API. Chaque prompt, sortie d'outil, trace et journal accidentel devient alors un possible chemin de diffusion de l'identifiant. Masquer les secrets dans la sortie de la console aide après une exposition, mais n'empêche pas l'agent de les recevoir et de les réutiliser.

Sallyport suit la seconde approche pour ses canaux HTTP et SSH pris en charge : l'agent demande une action via sa connexion MCP, tandis que l'application conserve les identifiants API et SSH dans son coffre chiffré et exécute elle-même l'action. Cette organisation peut garder les identifiants hors du contexte de l'agent, mais elle ne dispense pas de concevoir des identités et des propriétaires distincts pour les workflows.

Pour les systèmes qui doivent utiliser directement un identifiant, consignez où il est émis, comment il est transmis, sa durée de vie maximale et les personnes capables de le révoquer. La rotation ne doit pas dépendre du souvenir d'une date dans un agenda. Intégrez l'émission et le remplacement au processus de déploiement du workflow, puis testez une rotation avant que le compte ne devienne important.

Un identifiant à expiration courte ne permet pas d'ignorer les journaux. Un agent peut causer de vrais dommages pendant une courte session. L'expiration limite la persistance après un usage abusif ; la portée, l'approbation et l'enregistrement des actions limitent ce qui se passe pendant la session.

Les audits doivent relier l'autorité à une exécution précise

Une piste d'audit utile permet de reconstituer une action sans traiter le compte de service comme l'intégralité de l'histoire. Stockez l'identité du workflow, l'identifiant d'exécution de l'agent, le déclencheur initial, la décision d'autorisation, la cible, l'opération, le résultat et l'horodatage dans des enregistrements pouvant être corrélés.

Utilisez une structure d'événement cohérente. Le JSON suivant n'est lié à aucun fournisseur, mais il contient les champs que l'on aimerait généralement avoir après coup :

{
  "event_id": "act_01J8Q7M6K4",
  "time": "2026-04-14T16:20:31Z",
  "workflow_identity": "prod.payments.release-publisher",
  "run_id": "run_8f3c1d",
  "trigger": {
    "type": "approved_ci_job",
    "initiator": "morgan.lee",
    "source_revision": "a1b2c3d4"
  },
  "authorization": {
    "decision": "approved",
    "approved_by": "morgan.lee",
    "approval_ref": "apr_31fa"
  },
  "action": {
    "target": "production artifact repository",
    "operation": "publish",
    "resource": "payments-service/2.4.1"
  },
  "result": "success"
}

Ne placez pas dans un enregistrement d'audit des identifiants, des prompts complets contenant des informations sensibles ou des contenus sans restriction simplement parce que vous voulez des détails médico-légaux. Enregistrez assez de contexte stable pour établir la causalité, puis appliquez les mêmes règles de traitement des données qu'à n'importe quel journal opérationnel. Un système d'audit qui devient un second coffre à secrets crée son propre chemin d'incident.

L'intégrité compte aussi. Des journaux qu'un agent ou un workflow compromis peut modifier ne permettent pas de trancher les désaccords. Utilisez un stockage en ajout uniquement, séparez les permissions d'écriture des permissions de lecture et d'administration et vérifiez régulièrement l'intégrité. Conservez les preuves après le retrait d'un compte. Le retrait supprime l'autorité future, il ne doit pas effacer l'historique nécessaire pour expliquer les actions passées.

Les journaux Sessions et Activity de Sallyport sont générés à partir d'un journal d'audit chiffré, chaîné par hachage et protégé contre l'écriture ; la commande sp audit verify vérifie cette chaîne hors ligne sans identifiant de coffre. C'est une preuve utile pour les actions qu'il relaie, mais vos systèmes environnants doivent toujours conserver le propriétaire du workflow, le déclencheur et le contexte de l'approbation métier.

Organisez la revue autour de questions auxquelles quelqu'un peut répondre en quelques minutes : quel workflow détenait cette autorité ? Qui en était le propriétaire à ce moment-là ? Quelle exécution l'a utilisée ? Qu'est-ce qui a approuvé cette exécution ? Quelle opération exacte a réussi ou échoué ? Si une réponse exige de reconstituer une histoire à partir de discussions, vos enregistrements sont incomplets.

Le retrait est un workflow, pas une tâche annuelle de nettoyage

Retirez un compte de service lorsque son workflow se termine, lorsque son propriétaire ne peut pas être remplacé ou lorsqu'une évolution importante rend son objectif initial faux. Les revues annuelles repèrent les comptes obsolètes, mais elles sont trop lentes pour les événements déjà connus.

Intégrez les conditions de retrait à la fiche initiale du compte. Un workflow de migration peut être retiré lorsque la migration est terminée. Une automatisation de dépôt peut l'être lorsque le dépôt est archivé. Une intégration fournisseur peut l'être lorsque le contrat prend fin. Ces conditions rendent la décision moins politique, car le compte possède déjà une fin convenue.

Suivez cette séquence lorsque vous retirez une identité :

1. Désactiver toute nouvelle utilisation du compte et révoquer les identifiants ou liaisons actifs.
2. Observer les échecs attendus pendant une période définie et identifier les dépendances non documentées.
3. Restaurer uniquement l'accès minimal nécessaire à une dépendance vérifiée, avec un nouveau propriétaire et une nouvelle fiche si le workflow reste légitime.
4. Conserver la fiche de propriété, l'historique des accès et les journaux d'action selon vos règles de conservation.
5. Supprimer l'identité et ses identifiants restants à la fin de la période d'observation.

Ne commencez pas par supprimer le compte. La suppression peut éliminer une configuration utile et rendre les erreurs plus difficiles à diagnostiquer. La désactivation fournit un confinement et laisse la supervision habituelle révéler les appelants cachés. Elle force aussi une conversation utile : si un workflow tombe, qui le revendique et pourquoi était-il absent du registre ?

Le départ du propriétaire du compte mérite une attention immédiate. Avant son dernier jour, transférez la propriété uniquement après que le remplaçant a accepté la responsabilité. Si personne ne le remplace, désactivez le compte. Une équipe pourra décider de le réactiver plus tard pour un besoin opérationnel documenté, mais un compte orphelin ne doit pas conserver son autorité parce que quelqu'un pourrait en avoir besoin.

Le retrait s'applique aussi lorsqu'un workflow s'élargit. Si un outil de mise à jour des dépendances commence à déployer du code, ne modifiez pas simplement son objectif jusqu'à ce qu'il décrive deux tâches sans rapport. Retirez ou réduisez l'ancienne identité, puis créez une identité de déploiement avec son propre propriétaire, sa portée, ses tests et sa fiche de revue. Vous préserverez ainsi la signification d'audit des deux comptes.

La responsabilité ne subsiste que si les revues peuvent révoquer l'accès

Une revue de compte de service n'a de valeur que si les réviseurs peuvent voir les liaisons réelles, identifier le propriétaire actuel et désactiver l'accès sans une semaine de négociations. Intégrez cette autorité au processus opérationnel avant d'en avoir besoin.

Examinez plus souvent les workflows les plus risqués, mais ne transformez pas chaque revue en exercice administratif. Demandez-vous si l'objectif indiqué existe toujours, si le propriétaire possède encore l'autorité, si les actions récentes correspondent à l'objectif et si la portée correspond encore à l'utilisation observée. Si la réponse est incertaine, réduisez ou désactivez le compte pendant que le propriétaire clarifie la situation.

Mesurez l'état du système avec des faits qui révèlent les autorisations négligées : comptes sans propriétaire, dates de revue dépassées, absence d'historique d'action pendant une période significative, identifiants proches ou au-delà de leur durée prévue et workflows dont les opérations récentes sortent de l'objectif documenté. Ce sont des files de revue, pas des indicateurs de façade.

La première action concrète consiste à exporter les identités d'agents existantes et à écrire une phrase à côté de chacune : « Ce workflow peut faire X pour Y, sous la responsabilité de Z, jusqu'à la condition W. » Les comptes qui résistent à cette formulation sont ceux qui portent une responsabilité partagée cachée. Désactivez-les ou séparez-les avant d'ajouter de nouvelles capacités aux agents.