Gouverner les identités des agents logiciels autonomes

Un agent logiciel autonome ne se réduit ni à un utilisateur humain ni à un compte de service. Il interprète un objectif, sélectionne des actions et peut enchaîner des décisions avec des droits délégués. Cette capacité change la gouvernance : l’identité doit porter l’origine de la délégation, les limites d’action et la preuve de chaque décision.

→ Lire l’explication complète de la marmotte

Agent autonome, identité humaine et compte de service

Un compte de service représente normalement un logiciel déterministe ou une charge technique stable : un pipeline, un démon, une application. Son comportement est supposé connu à l’avance, même si cette supposition finit souvent dans un tableur fossilisé. Un agent fondé sur un modèle de langage de grande taille (LLM, Large Language Model) choisit au contraire une séquence d’outils selon un contexte variable : instruction initiale, données récupérées, mémoire de conversation, sortie d’un autre système ou contenu non fiable reçu d’un tiers.

Cette différence interdit de traiter l’agent comme un compte de service un peu plus bavard. Un agent possède au minimum quatre dimensions d’identité :

L’identité d’exécution : le principal technique qui s’authentifie auprès des interfaces de programmation applicative (API, Application Programming Interface).
L’identité du mandant : humain, groupe métier ou système qui autorise l’objectif.
L’identité de l’agent : version du modèle, configuration, jeu d’outils autorisés et politique de décision.
Le contexte de délégation : durée, périmètre de données, action demandée et limites explicites.

Sans ces dimensions, les journaux indiquent seulement qu’un compte de service a supprimé une ressource ou transféré des données. C’est insuffisant pour déterminer quelle instruction a conduit à cette action, quelle personne ou quel système a porté la demande, et quelle politique devait l’empêcher.

La recommandation est nette : créer un type de principal dédié aux agents dans le référentiel d’identités, même si l’outil de gestion des identités et des accès (IAM, Identity and Access Management) ne le propose pas nativement. Un attribut principal_type=agent, un identifiant d’agent immuable, une référence de version et un lien obligatoire vers un mandant constituent le minimum. Réutiliser un compte de service partagé entre plusieurs agents interdit toute attribution fiable. L’audit devient alors une séance de divination, et les logs n’ont jamais été très bons en astrologie.

Le compromis central est direct : plus un agent reçoit d’autonomie, plus il réduit les délais opérationnels, mais plus la délégation devient difficile à borner et à attribuer. L’autonomie ne doit donc pas être mesurée par le nombre d’outils connectés. Elle doit être mesurée par le nombre d’actions à impact qu’un agent peut exécuter sans contrôle humain.

Pour les identités humaines, consulter la gestion des identités et les enjeux d’habilitation des personnes. Pour les automatisations et modèles locaux, la page IA locale couvre les mécanismes d’agents et de supervision, sans remplacer la gouvernance d’identité décrite ici.

Délégation, responsabilité et droits effectifs

Un agent ne doit jamais devenir le propriétaire implicite d’une décision. La responsabilité opérationnelle reste portée par l’organisation qui l’exploite et, pour une demande précise, par le mandant qui déclenche ou approuve la délégation. Le fournisseur du modèle, l’équipe plateforme et l’équipe métier peuvent avoir des responsabilités distinctes, mais aucune architecture ne doit laisser cette répartition dans une zone grise non documentée.

La règle de conception est la suivante : une action doit être attribuable à une chaîne complète, mandant -> agent -> identité d'exécution -> ressource -> décision. Cette chaîne doit survivre aux retries, aux files de messages et aux appels asynchrones. Propager seulement un identifiant de requête ne suffit pas : cet identifiant n’exprime ni le titulaire de l’autorisation ni la portée de la délégation.

Une délégation doit comporter une durée maximale, une liste de ressources, une liste d’actions et un niveau de risque. Les jetons d’accès au format JSON Web Token (JWT) peuvent transporter ces informations, mais leur signature ne transforme pas une mauvaise politique en bonne politique. Un jeton signé avec scope=* reste un incendie administratif avec une cryptographie impeccable.

Les droits doivent être calculés comme une intersection :

droits_effectifs =
  droits_identite_execution
  ∩ droits_agent
  ∩ droits_mandant
  ∩ droits_delegation
  ∩ contraintes_contexte

Les contraintes de contexte incluent l’environnement, la fenêtre temporelle, la classification des données, l’adresse réseau d’origine et l’état d’approbation humaine. Une autorisation accordée pour analyser des tickets ne donne pas le droit de créer des utilisateurs, de modifier une politique IAM ou de lire un coffre de secrets. Les permissions d’escalade doivent être séparées des permissions de travail, sans exception décorative pour les démonstrations.

Les actions irréversibles ou difficilement réparables exigent une confirmation humaine explicite : suppression de données, changement de bénéficiaire de paiement, publication externe, modification de droits, rotation de secret, révocation de certificat, déploiement en production ou exfiltration de données. Cette confirmation doit porter sur l’action normalisée, pas sur un résumé rédigé par l’agent. L’agent peut expliquer son intention, mais le système d’autorisation doit afficher la ressource, la conséquence et le périmètre réels.

Une approbation humaine n’est pas une garantie contre l’erreur si elle est demandée vingt fois par heure. La fatigue de validation convertit rapidement le contrôle en bouton décoratif. Il faut donc réserver l’approbation aux transitions de risque et limiter le regroupement d’actions : approuver « supprimer 4 000 objets » n’est pas approuver « nettoyer un dossier ».

Surface d’attaque des agents décisionnels

L’attaque la plus fréquente n’est pas le vol de clé spectaculaire. C’est l’instruction malveillante injectée dans une donnée que l’agent considère comme exploitable : ticket, document, page web, pièce jointe, commentaire ou résultat d’API. Une injection indirecte peut demander à l’agent d’ignorer sa politique, de révéler un secret ou d’appeler un outil disposant de privilèges excessifs.

Aucune consigne textuelle ne constitue une frontière de sécurité. Les instructions système, garde-fous et filtres de contenu réduisent des erreurs, mais ne remplacent jamais une autorisation imposée hors du modèle. L’agent doit proposer une action ; un composant d’autorisation indépendant doit décider si cette action est permise. Confier la sécurité au raisonnement probabiliste d’un modèle revient à demander à un perroquet très cultivé de tenir le registre des accès.

Le vol d’identifiants reste critique. Une clé statique embarquée dans la configuration de l’agent permet à un attaquant de rejouer les mêmes actions hors de toute conversation. Préférer une identité de charge de travail à durée courte, émise par une autorité de confiance, avec audience, durée de vie et périmètre restreints. Les secrets de délégation ne doivent pas apparaître dans les prompts, les historiques, les traces de débogage ou les sorties d’outils.

La compromission d’un outil connecté constitue un autre chemin d’escalade. Si un agent peut appeler un service de stockage, un système de tickets et une plateforme d’administration, chaque connecteur devient un interprète de commandes à surveiller. Isoler les connecteurs par domaine fonctionnel et utiliser des identités distinctes. Un agent de support n’a aucune raison d’hériter du rôle d’administration cloud, même « temporairement ». Le temporaire est la forme la plus durable de l’infrastructure.

La surveillance doit détecter au moins : les appels refusés répétés, les changements de périmètre, les actions inhabituelles pour un agent, les délégations longues, les tentatives d’accès aux secrets, les appels en chaîne entre agents et les opérations exécutées hors fenêtre prévue. Envoyer ces événements vers un système de gestion des informations et des événements de sécurité (SIEM, Security Information and Event Management) est nécessaire, mais pas suffisant : il faut corréler l’identifiant d’agent, le mandant, l’outil et la décision d’autorisation.

La révocation doit couper trois éléments : les jetons actifs lorsque le mécanisme le permet, le droit d’obtenir de nouveaux jetons, et l’accès de l’agent aux outils. Révoquer un secret sans désactiver l’agent laisse un processus qui échoue en boucle, puis tente souvent une voie de contournement prévue par un développeur optimiste. Les sauvegardes de configuration doivent inclure les politiques, les références de connecteurs et les identifiants de versions, mais jamais les secrets en clair.

Exemple de jeton de délégation borné

L’exemple suivant illustre une demande d’accès courte à une API interne. Le contrôle d’autorisation doit vérifier les revendications avant chaque action, pas uniquement lors de l’émission du jeton.

{
  "sub": "agent:ticket-triage:v3.4.1",
  "act": {
    "sub": "human:alice@example.invalid"
  },
  "aud": "https://tickets.example.internal",
  "exp": 1735689900,
  "jti": "8c9b8c1d-4af4-4cb6-9d6f-1d5fdd42a191",
  "scope": [
    "ticket:read",
    "ticket:comment:create"
  ],
  "delegation": {
    "request_id": "req-7b1c",
    "purpose": "classer les tickets reçus",
    "environment": "production",
    "approval_required": false
  }
}

Le champ sub identifie l’agent, tandis que act désigne le mandant effectif. Une API qui ne journalise que sub perd l’auteur de la délégation ; une API qui ne contrôle que act permet au mandant d’hériter de capacités propres à l’agent. Les deux doivent être vérifiés.

Le champ jti rend possible une liste de révocation ciblée, à condition que les services consultent cette liste ou reçoivent les événements de révocation. Un jeton autoportant non vérifié après émission reste valide jusqu’à expiration. Une durée courte limite la fenêtre, elle ne remplace pas une révocation lorsque l’impact est élevé.

Exploitation : rotation, preuves et reprise

Chaque agent doit disposer d’un propriétaire opérationnel, d’un propriétaire métier et d’une date de revue. L’absence de propriétaire doit désactiver les nouvelles délégations, pas déclencher une chasse au trésor dans un annuaire. La revue doit vérifier les outils autorisés, les droits effectifs, les approbations contournées, les erreurs d’autorisation et les versions de modèle encore actives.

Les journaux d’audit doivent être immuables ou exportés vers un stockage à rétention contrôlée. Enregistrer l’instruction brute peut exposer des données personnelles ou des secrets ; conserver uniquement un hachage cryptographique, les références de données consultées, la politique évaluée, la décision, l’appel d’outil et le résultat synthétique. Le hachage permet de prouver l’intégrité sans transformer l’audit en seconde base de fuite.

La rotation des secrets d’agent doit être automatisée et testée. Une rotation qui exige de modifier un prompt, un fichier de configuration ou une image de conteneur n’est pas une rotation : c’est une future interruption planifiée par personne. Prévoir une double période de validité limitée, détecter les consommateurs de l’ancien secret et refuser son renouvellement après échéance.

Enfin, un plan de reprise doit distinguer panne et comportement dangereux. Après panne, restaurer la configuration et les droits validés. Après compromission ou désalignement, restaurer ne suffit pas : il faut geler les délégations, invalider les identités, examiner les décisions exécutées et réautoriser progressivement les outils. La gouvernance décrite dans l’architecture cyber et la gouvernance fournit le cadre de décision ; l’agent ne doit pas devenir une exception enthousiaste à ces contrôles.

🐝 Ce qui arrive si on s’en passe

Sans identité propre à l’agent, le confinement n’a plus de granularité : couper l’accès suspect revient à désactiver le compte de service partagé, donc aussi les traitements légitimes qui l’utilisent, ce qui pousse à retarder la coupure. Sans référence de version dans l’identité, une action douteuse constatée après une mise à jour de modèle ou de configuration ne peut plus être rattachée à l’état exact qui l’a produite, et le correctif porte sur une cible supposée. Sans lien obligatoire vers un mandant, le départ ou la suspension d’une personne ne retire rien aux délégations déjà émises en son nom, qui continuent de produire des effets. Sans chaîne d’attribution conservée à travers les files et les reprises, la reconstitution après incident se limite à un inventaire d’appels, sans savoir lesquels réautoriser.

🦫 Explication de la marmotte 🍫

Un agent logiciel autonome reçoit une mission, consulte des informations et peut demander à des systèmes d’effectuer des actions. Il ne faut pas lui donner l’accès général d’une personne ni un compte technique partagé. Il reçoit sa propre identité, liée à la version du programme qui le fait fonctionner, et une autre information indique qui a demandé l’action.

Avant une action, le système vérifie plusieurs limites : ce que l’agent a le droit de faire, ce que la personne ou le système demandeur a le droit de faire, les ressources concernées, la durée autorisée et le contexte. L’action ne passe que si toutes ces limites l’autorisent. Pour une suppression, un paiement, un changement de droits ou une publication, une personne doit confirmer l’action réelle avant son exécution.

L’agent peut être trompé par un texte reçu dans un document, un message ou une page consultée. Ce texte ne doit donc jamais décider seul des permissions. Un mécanisme séparé contrôle chaque demande d’action. Les accès de l’agent expirent vite, sont renouvelés seulement si nécessaire et peuvent être coupés en cas d’incident.

Chaque décision doit laisser une trace : qui a demandé, quel agent a agi, quelles données ont été consultées, quelle règle a été appliquée et quel résultat a été obtenu. Si l’agent échoue ou devient suspect, ses accès sont désactivés, les actions passées sont examinées et les autorisations ne reviennent qu’après vérification.

Pages voisines

La citent

Gouverner les identités des agents logiciels autonomes

Elle cite

Gouverner les identités des agents logiciels autonomes

Gouverner les identités des agents logiciels autonomes

Agent autonome, identité humaine et compte de service

Délégation, responsabilité et droits effectifs

Surface d’attaque des agents décisionnels

Exemple de jeton de délégation borné

Exploitation : rotation, preuves et reprise

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines