Les agents d’IA ont besoin d’identités, pas de clés d’API

À 9 h 12, un lundi matin, les clients d’un distributeur fictif commencent à signaler des commandes qui échouent.

L’équipe plateforme dispose d’un agent d’IA d’exploitation connecté à sa file de support et à son environnement cloud. Un ingénieur lui donne une consigne brève :

Trouvez pourquoi le tunnel de commande échoue et corrigez le problème.

L’agent lit le ticket d’incident, recherche dans les journaux (logs) applicatifs, compare les déploiements récents et vérifie l’état du service de paiement. Il découvre un certificat expiré, en génère un nouveau, met à jour la configuration et déploie la modification.

Le tunnel de commande est rétabli en douze minutes. L’équipe est impressionnée.

Puis le responsable de la sécurité demande :

• Quelle identité a modifié la production ?
• L’agent avait-il le droit d’enquêter, ou aussi de déployer ?
• De qui tenait-il son autorité ?
• S’il avait modifié le mauvais certificat, l’équipe pourrait-elle prouver ce qui s’est passé ?

Le journal d’audit ne donne qu’une seule réponse : platform-automation-service.

Ce compte est aussi utilisé par des pipelines de déploiement, des scripts de maintenance et deux anciens outils d’automatisation. Ses identifiants prouvent qu’un compte approuvé a effectué l’appel. Ils ne révèlent ni quel système a choisi l’action, ni quelle personne a lancé le travail, ni quel résultat avait été approuvé, ni à quel moment cette autorité aurait dû prendre fin.

L’agent a résolu la panne. Il a aussi mis au jour une ancienne faiblesse d’architecture : des identifiants étaient devenus un substitut à l’identité, à l’autorité et à la responsabilité.

Les agents changent la question de sécurité

Les applications ont toujours eu besoin d’identifiants. Un service peut utiliser un jeton pour appeler un autre service. Un pipeline de déploiement peut utiliser un compte de service pour mettre à jour des ressources cloud (en anglais). Une tâche planifiée peut utiliser un certificat pour lire une base de données.

Ces pratiques ne sont pas dangereuses en soi. Le problème commence lorsqu’un seul identifiant de longue durée tient lieu de plusieurs acteurs et de plusieurs finalités.

L’automatisation traditionnelle a généralement un périmètre étroit. Un pipeline suit un code écrit à l’avance. Une tâche de sauvegarde exécute une séquence connue. Un agent d’IA (en anglais) est moins prévisible : il reçoit un objectif, examine son environnement, choisit des outils et adapte l’étape suivante en fonction de ce qu’il trouve.

Le modèle n’est peut-être pas déterministe, mais ses appels d’outils ont des conséquences bien réelles.

Pour un script classique, on se demande souvent :

Ce processus peut-il appeler l’API ?

Pour un agent, ce n’est que la première question. Il faut aussi se demander :

Pourquoi appelle-t-il l’API, de qui tient-il son autorité, et cette action relève-t-elle encore de la tâche qui a été approuvée ?

Une clé d’API ne peut pas, à elle seule, répondre à ces questions.

Un identifiant prouve moins qu’on ne le croit

Un identifiant est une preuve utilisée lors de l’authentification. Il peut aider un service à établir quel principal émet une requête. Il n’explique pas, à lui seul, pourquoi la requête est autorisée.

Cinq notions doivent rester distinctes :

• Identité : quel acteur émet la requête.
• Authentification : comment le système vérifie cette affirmation.
• Autorisation : ce que l’acteur vérifié a le droit de faire.
• Délégation : ce qu’un acteur est autorisé à faire pour le compte d’un autre, pour une finalité et une durée déterminées.
• Responsabilité : la capacité de l’organisation à reconstituer la requête, la décision, la politique, l’action et le résultat.

Un jeton valide peut prouver qu’une requête provient d’un principal authentifié. Il ne peut pas prouver que la requête correspond à l’intention actuelle de l’utilisateur. Un ingénieur peut avoir le droit de déployer, mais cela ne signifie pas que chaque agent qu’il sollicite doive hériter du même pouvoir.

C’est pourquoi « l’agent est authentifié » ne constitue pas une conclusion de sécurité complète.

Une seule action peut impliquer quatre identités

Dans l’incident du tunnel de commande, un seul appel à une API cloud peut impliquer au moins quatre identités.

Identité	Ce qu’elle représente	Question à laquelle elle répond
Humain	L’ingénieur qui a demandé ou approuvé la tâche	Qui a demandé ce travail ?
Agent	Le logiciel qui choisit l’action suivante	Quel système autonome l’a choisie ?
Charge de travail	Le processus, le conteneur ou le pod qui effectue l’appel	Quel environnement d’exécution déployé l’a envoyé ?
Cible	Le service ou la ressource qui accepte l’appel	Quel système l’a exécuté ?

Ces identités peuvent se recouper. Un petit agent interne au comportement figé peut raisonnablement utiliser une identité de charge de travail existante. Mais le modèle devient plus difficile à gouverner lorsque les agents sont créés dynamiquement, agissent pour différents utilisateurs, appellent de nombreux outils ou n’existent que le temps d’une tâche.

Si un pipeline et un agent d’exploitation utilisent le même principal, la piste d’audit ne permet pas de distinguer de façon fiable une automatisation prédéterminée d’une décision dirigée par le modèle. Si vingt agents partagent une même clé, désactiver un agent compromis risque de perturber les vingt. Si un agent utilise le jeton d’une personne, sa portée peut s’étendre silencieusement à l’ensemble des accès de cette personne.

Il ne s’agit pas de créer une identité simplement pour donner un nom à l’agent. Il s’agit de rendre ses accès séparables, confinables et traçables.

Le marché du cloud évolue dans le même sens

Au cours de l’année écoulée, plusieurs plateformes ont introduit des contrôles qui traitent les agents comme des acteurs visibles plutôt que comme des utilisateurs anonymes d’un secret partagé.

Chez Microsoft, Entra Agent ID sépare les identités d’agents des identités humaines et des identités d’application classiques. Le service prend en charge les accès attribués directement à un agent et l’autorité déléguée par un utilisateur, tout en enregistrant comme activité d’agent les authentifications prises en charge.

Google Cloud a annoncé Agent Identity, une identité fondée sur SPIFFE, avec des politiques IAM adaptées aux agents et une application des politiques au niveau de la passerelle. Au 6 mai 2026, l’identité d’exécution de base et la prise en charge des politiques IAM Allow et Deny étaient en disponibilité générale ; plusieurs contrôles connexes, liés à la passerelle ou au contexte, restaient en préversion ou étaient prévus.

AWS a pris une autre voie. Amazon Bedrock AgentCore est passé en disponibilité générale en octobre 2025. AgentCore Policy a atteint la disponibilité générale en mars 2026 et évalue les appels d’outils qui transitent par la passerelle en dehors de la boucle de raisonnement de l’agent. Le service géré AWS MCP Server s’appuie lui aussi sur les contrôles IAM et offre une visibilité distincte sur l’activité du serveur.

Ces services diffèrent, et le statut de leurs fonctionnalités évoluera. Leur orientation commune compte davantage que leurs noms de produits :

Donner à l’agent une identité distincte, limiter son autorité et appliquer la politique avant qu’une action proposée ne devienne une opération réelle.

Ces services sont des briques utiles. Aucun ne dispense de définir ce que l’agent a le droit de faire pour une tâche donnée.

Le problème le plus épineux est la dérive de l’autorité

Revenons à l’incident. L’ingénieur demande à l’agent d’enquêter sur les échecs du tunnel de commande. L’agent lit les journaux et découvre le certificat expiré.

Il appelle ensuite un outil de gestion des certificats. Cet outil appelle un service de déploiement. Le service de déploiement demande à un autre agent de valider la mise en production. Chaque composant peut avoir une identité valide, et chaque appel peut être autorisé par une politique d’accès large.

Mais à quel moment a-t-il été décidé qu’« enquêter » incluait « remplacer un certificat de production et le déployer » ?

L’autorité peut dériver à mesure que le travail passe d’un outil, d’un agent et d’un service à l’autre. L’authentification reste valide, tandis que le lien entre la demande initiale et la conséquence finale s’affaiblit.

C’est là qu’apparaît la différence entre autorisation d’accès et autorisation d’action.

L’autorisation d’accès demande :

Cet agent peut-il appeler l’API de déploiement ?

L’autorisation d’action demande :

Cet agent peut-il effectuer ce déploiement, sur cette ressource, pour cette tâche, avec une autorité qui est encore valide en ce moment ?

Une identité d’agent unique améliore la visibilité et facilite l’application des politiques. Elle ne comble pas cet écart à elle seule.

Ce domaine est encore en évolution. Le NIST a lancé son AI Agent Standards Initiative en février 2026 et mène des recherches sur l’authentification des agents et les infrastructures d’identité. Son National Cybersecurity Center of Excellence étudie par ailleurs une approche de l’identité et de l’autorisation fondée sur des normes pour les accès et les actions des logiciels et des agents d’IA. Au moment de notre vérification, ces travaux étaient toujours en cours et ne constituaient pas une norme d’architecture établie.

Placer la politique juste avant la conséquence

Une instruction (prompt) telle que « n’effectuez jamais de modification dangereuse sans permission » peut influencer le comportement du modèle. Ce n’est pas un contrôle d’autorisation. Le modèle interprète les prompts ; c’est un système distinct qui doit faire respecter les permissions.

Le point de contrôle le plus solide est généralement la frontière située juste avant l’exécution d’un outil ou d’une API aux conséquences réelles.

Le flux sûr comporte quatre points de contrôle :

1. Identifier la requête. Enregistrer la personne, l’agent, la charge de travail en cours d’exécution, la tâche, l’heure et le résultat attendu.
2. Borner la délégation. N’accorder à l’agent que les ressources, les actions et la durée nécessaires à cette tâche.
3. Décider en dehors du modèle. Évaluer la cible proposée, l’action, l’environnement, le risque et les règles d’approbation dans un service de politiques externe.
4. Exécuter et prouver. Émettre un identifiant de courte durée pour l’opération approuvée, appliquer de nouveau la politique au moment de l’exécution et enregistrer le résultat.

La frontière importante se situe entre la proposition et l’exécution :

Le modèle peut proposer. Il ne doit pas pouvoir approuver sa propre proposition, se forger sa propre autorité ni contourner le point d’application.

L’approbation humaine doit avoir un sens

Ajouter un bouton d’approbation peut créer une fausse confiance. On approuve trop vite lorsque les demandes sont fréquentes, vagues ou difficiles à comprendre.

« Autoriser l’agent à continuer » n’est pas une décision éclairée. Une approbation utile montre la conséquence réelle :

Remplacer le certificat payment-internal en production, déployer la révision checkout-1842, surveiller pendant dix minutes et revenir en arrière si les erreurs de paiement dépassent le seuil convenu.

L’approbation doit aussi être proportionnée au risque. Un agent d’exploitation peut lire des métriques de santé sans interruption. Il peut redémarrer une charge de travail de développement en échec en suivant un runbook approuvé. Un changement de certificat de production, une modification des permissions d’une base de données ou une suppression doivent franchir une frontière plus stricte.

Certaines actions doivent rester interdites même lorsqu’un utilisateur les demande. Un agent ne doit pas pouvoir s’accorder des permissions, désactiver sa piste d’audit ni réécrire la politique qui évalue ses propres actions.

L’intervention humaine est la plus utile une fois que le système a ramené la question à une décision précise et compréhensible.

La charge de travail a toujours besoin d’un identifiant robuste

L’identité d’agent ne remplace pas l’identité de charge de travail. L’agent s’exécute toujours sous la forme d’un processus, d’un conteneur ou d’un pod (en anglais), et cet environnement d’exécution a besoin d’un moyen sûr de s’authentifier.

Les jetons porteurs (bearer tokens) fonctionnent comme des billets : quiconque en détient une copie valide peut la présenter. Kubernetes renforce cette couche avec les Pod Certificates, introduits en bêta dans la version 1.35 et passés en disponibilité générale dans la version 1.37. Ils permettent la preuve de possession et une rotation gérée par la plateforme, au lieu d’envoyer à chaque pair un identifiant porteur complet.

Ce n’est pas une réponse universelle. Les applications doivent utiliser le matériel cryptographique renouvelé, et les organisations ont toujours besoin d’un signataire de certificats et d’un modèle de confiance soigneusement conçu. Le principe durable consiste à préférer des identifiants de courte durée, propres à chaque charge de travail, plutôt que des secrets statiques copiés d’un système à l’autre.

L’identité logique de l’agent et son identité d’exécution doivent être reliées dans la piste d’audit, sans se confondre dans un même compte partagé.

Ne pas résoudre d’abord le problème à la mode

L’autorisation des agents ne doit pas détourner l’attention de la sécurité de base. Le rapport M-Trends 2026 de Mandiant, fondé sur ses enquêtes de 2025, indique que les exploits sont restés le vecteur d’infection initiale le plus courant, à 32 %. Il indique aussi que la grande majorité des intrusions réussies provenaient encore de défaillances humaines et systémiques fondamentales, alors même que les attaquants utilisaient l’IA pour accélérer certaines parties de leur travail.

Une organisation qui crée des identités d’agents sophistiquées tout en laissant sans correctifs des systèmes exposés sur Internet, ou des secrets de longue durée dans ses dépôts, a résolu le nouveau problème avant le problème urgent. Continuez à appliquer les correctifs, à durcir les systèmes, à surveiller et à tester la reprise — et n’ajoutez pas d’accès autonomes au moyen d’identités qui rendent les actions impossibles à distinguer ou à contenir.

Reconstruire l’incident autour d’une autorité bornée

Rejouons maintenant ce lundi matin.

L’ingénieur demande à l’agent d’exploitation d’enquêter sur les échecs du tunnel de commande. La plateforme enregistre la tâche et accorde un accès de courte durée, en lecture seule, aux journaux, aux métriques et aux données de déploiement du tunnel de commande.

L’agent trouve le certificat expiré. Comme son autorité d’enquête ne lui permet pas de modifier la production, il rédige une proposition qui précise la cible, le déploiement, les contrôles de validation et la condition de retour arrière.

Un service de politiques externe vérifie la cible, l’opération et l’exigence d’approbation. L’ingénieur approuve la modification exacte, et un service d’exécution reçoit un identifiant temporaire limité à cette opération et à cette ressource. La politique est de nouveau vérifiée juste avant l’exécution.

L’enregistrement final relie l’ingénieur, l’agent, la charge de travail en cours d’exécution, la version de la politique, l’action approuvée, la ressource modifiée, le résultat de la validation et l’heure d’expiration.

L’agent résout toujours la panne rapidement. La différence, c’est que cette rapidité ne dépend plus d’un compte doté d’un pouvoir inexpliqué.

Dix questions avant de donner à un agent un accès au cloud

1. Pouvons-nous distinguer l’agent de son utilisateur, de son environnement d’exécution et des autres automatisations ?
2. Qui est propriétaire et responsable de l’identité de l’agent ?
3. L’agent agit-il de manière indépendante ou avec une autorité humaine déléguée ?
4. Cette délégation peut-elle être plus étroite que l’ensemble des accès de l’utilisateur ?
5. Les identifiants sont-ils de courte durée, limités à des ressources précises et liés à une audience ?
6. Quelles actions sont en lecture seule, pré-approuvées, soumises à approbation ou interdites ?
7. La politique est-elle appliquée en dehors du modèle et juste avant l’exécution ?
8. Un autre outil ou un autre agent peut-il contourner cette même frontière de politique ?
9. La piste d’audit peut-elle relier la requête, la décision, l’action et le résultat ?
10. Qu’est-ce qui met fin automatiquement à l’autorité lorsque la tâche est terminée ?

Si les réponses se résument à « l’agent utilise notre compte d’automatisation », la conception n’est pas terminée.

Le principe à retenir

Les agents d’IA rendent plus difficile à ignorer une vieille faiblesse de la sécurité du cloud. La sélection autonome d’outils multiplie les façons d’exploiter l’autorité cachée dans les identifiants partagés et les comptes de service aux droits trop larges.

Une identité unique n’est qu’un début.

La frontière complète doit relier la personne, l’agent, la charge de travail en cours d’exécution, la finalité déléguée, l’action proposée, la décision de politique et la conséquence finale.

Avant de demander si un agent peut accomplir une tâche, posez trois questions plus pointues :

De qui tient-il son autorité ? Qu’est-ce que cette autorité permet exactement ? Où cette décision est-elle appliquée avant que l’action ne devienne réelle ?

Ces réponses — et non l’aisance du modèle — déterminent si un agent a sa place en production.

---

Références et lectures complémentaires

Ces sources primaires donnent accès aux détails des plateformes, aux travaux de normalisation et aux données de sécurité sur lesquels s’appuie l’article. Le statut des produits doit être vérifié de nouveau avant toute mise en œuvre.

• What are agent identities — Microsoft Entra Agent ID — Explique l’identité d’agent, l’accès autonome, l’accès délégué et ce qui les distingue des identités humaines et des identités d’application. Dernière mise à jour le 15 juin 2026.
• What’s new in IAM: Security, governance, and runtime defense — Google Cloud — Indique l’état de disponibilité, en mai 2026, d’Agent Identity, des politiques IAM adaptées aux agents, de l’application au niveau de la passerelle et des contrôles connexes. Publié le 6 mai 2026.
• Introducing Amazon Bedrock AgentCore — AWS — Présente les capacités d’exécution, d’identité et de passerelle d’AgentCore ; mis à jour lors de la disponibilité générale, le 13 octobre 2025.
• AgentCore policy controls and evaluations — AWS — Décrit l’application des politiques en dehors de la boucle de raisonnement de l’agent et avant l’exécution des outils de la passerelle. Publié le 2 décembre 2025 ; Policy a atteint la disponibilité générale le 3 mars 2026.
• The AWS MCP Server is now generally available — AWS — Traite de l’accès des agents fondé sur IAM, de la séparation entre permissions humaines et permissions du serveur, de l’exécution en bac à sable et de la visibilité pour l’audit. Publié le 6 mai 2026.
• Kubernetes v1.35 release — Annonce les Pod Certificates en bêta, avec génération native des clés et rotation automatisée. Publié le 17 décembre 2025.
• Kubernetes v1.37: Pod Certificates and Cluster Trust Bundles — Explique les limites des jetons porteurs, les identifiants à preuve de possession, la disponibilité générale et les précautions de mise en œuvre. Publié le 28 août 2026.
• NIST AI Agent Standards Initiative — Suit les travaux du NIST sur des normes d’agents sûres et interopérables et sur les infrastructures d’identité. Créé le 17 février 2026 ; mis à jour le 14 août 2026.
• Software and AI Agent Identity and Authorization — NIST NCCoE — Étudie des approches fondées sur des normes pour identifier les agents et autoriser leurs accès et leurs actions. Statut vérifié le 11 septembre 2026.
• M-Trends 2026 — Mandiant — Fournit des données issues des enquêtes de 2025 sur l’exploitation, la rapidité des passages de relais entre attaquants et le rôle de l’IA dans les intrusions observées. Consulté le 11 septembre 2026.