Gestion des clés des agents IA : une identité révocable par agent, des clés hors du processus de l'agent et un accès au KMS par serveur MCP encadré.
La gestion des clés des agents IA (AI agent key management) désigne la façon d'émettre, de limiter, d'utiliser, de faire tourner et de révoquer les clés et identifiants dont dépendent les agents IA autonomes. L'objectif : chaque agent agit sous sa propre identité, ne détient jamais une clé complète qu'il pourrait divulguer, et peut être coupé seul sans perturber le reste de la flotte.
Les agents IA en production demandent déjà des clés, appellent des API, signent des transactions et touchent des données régulées. La plupart s'authentifient pourtant encore comme un batch de 2012 : un compte de service partagé, un secret longue durée dans un chemin de coffre, et un journal d'audit qui dit « l'utilisateur d'automatisation a fait quelque chose » sans nommer l'agent.
La cryptographie agentique est le plan de contrôle qui comble ce manque. Chaque agent reçoit une identité cryptographique que vous pouvez émettre, attester et révoquer sans faire tourner les identifiants du reste de la flotte.
Les déploiements d'agents en production partagent souvent trois défaillances :
Rien de tout cela ne relève de la qualité du modèle. C'est un problème d'identité et de gestion des clés que les éditeurs de cryptographie traitent rarement comme un produit à part entière.
Know your agent reprend l'idée du « know your customer », appliquée aux acteurs non humains qui peuvent dépenser, approuver ou déchiffrer :
Si vous ne pouvez pas nommer l'agent, le révoquer seul et prouver ce qu'il a signé, vous n'avez pas de gouvernance des agents. Vous avez de l'automatisation avec un modèle d'identifiant emprunté aux humains.
Les agents diffèrent des charges classiques sur un point qui compte pour les clés : leur comportement dépend d'entrées que vous ne maîtrisez pas entièrement (prompts, documents, résultats d'outils). Une injection de prompt ou une réponse d'outil piégée peut pousser un agent à abuser de tout ce qu'il peut atteindre. La gestion des clés des agents part donc du principe que le processus de l'agent peut être manipulé.
Le Model Context Protocol (MCP) est le standard ouvert qu'utilisent de nombreux clients IA pour appeler des outils externes. La « gestion des clés d'un serveur MCP » recouvre deux questions.
1. Protéger les identifiants d'un serveur MCP. Un serveur MCP se place entre un agent et de vrais systèmes ; il détient ou obtient donc des identifiants pour ces systèmes. La spécification MCP rend l'autorisation optionnelle, mais pour les transports HTTP elle s'appuie sur OAuth 2.1. Les serveurs MCP doivent vérifier que les jetons ont été émis pour eux et ne doivent pas transmettre le jeton du client aux API en amont ; pour les serveurs locaux en STDIO, la spécification demande de lire les identifiants dans l'environnement (spécification d'autorisation MCP). En pratique :
2. Piloter la gestion des clés via un serveur MCP. Les éditeurs de sécurité exposent désormais leurs plateformes en MCP, pour qu'un assistant IA interroge des inventaires ou effectue des changements. Keyfactor a par exemple annoncé un serveur MCP pour Keyfactor Command (communiqué). La question devient alors : jusqu'où l'agent peut-il aller ?
La réponse de DuoKey est l'endpoint MCP du Cockpit (documentation) :
Un KMS agentique (agentic KMS) est un système de gestion des clés conçu pour que des agents IA puissent l'utiliser en sécurité : via une interface standard comme MCP, sous une politique explicite, chaque action étant liée à une identité nommée et à la personne responsable. Il couvre les deux sens : les agents qui utilisent des clés (signature, déchiffrement d'enveloppe) et les agents qui gèrent des clés (inventaire, rotation, émission de certificats).
La documentation DuoKey présente la plateforme comme un KMS agentique et un plan d'agilité cryptographique, où des clients IA et MCP peuvent piloter la cryptographie en langage naturel (docs.duokey.com). Les garde-fous sont ceux décrits plus haut : cloisonnement par tenant, packs de capacités à activer, droits propres de l'utilisateur, et approbation humaine pour les changements à fort impact, sauf si la politique du client l'autorise explicitement autrement.
| Contrôle | Ce qu'il fait |
|---|---|
| Identité cryptographique par agent | Émettre une identité vérifiable à la création de l'agent ; pas de compte de service de production partagé par la flotte |
| Révocation à l'unité | Retirer l'autorité d'un agent en une opération ; les autres continuent de fonctionner |
| Attestation signée par action | Lier l'usage des clés, les signatures ou les appels sensibles à l'identité de l'agent et à la décision de politique |
| Politique hors de l'agent | Plafonds, listes autorisées et escalades vivent hors du processus de l'agent ; un agent compromis ne peut pas les réécrire |
| Matériel de clé en MPC | Quand un agent a un pouvoir de signature ou de paiement, les parts de clé ne se réassemblent jamais en un secret en clair (MPC vs HSM) |
| Accès MCP encadré | Les clients IA accèdent au Cockpit via un endpoint MCP cloisonné par tenant, avec des packs de capacités à activer |
C'est l'architecture résumée sur la plateforme : chaque agent a une identité révocable, aucun compte de service partagé ne porte d'accès production : know your agent.
La cryptographie agentique s'appuie sur des objets que DuoKey gouverne déjà ailleurs sur la plateforme :
| Objet gouverné | Rôle pour les agents |
|---|---|
| Clés / KMS | Les agents demandent un déchiffrement d'enveloppe ou un usage sous politique ; pas de garde exclusive par le fournisseur cloud |
| Certificats / PKI | Identités machine et charge de travail pour les agents qui ont besoin de TLS ou mTLS, sans PKI tenue sur tableur |
| Secrets | Du matériel court et propre à l'agent au lieu d'un .env copié ou d'un AppRole partagé |
| Agilité cryptographique / PQC | Renouvellements et changements d'algorithme sous le même plan d'automatisation que celui des agents |
Les agents ne sont pas un silo produit à part. Ce sont des principaux sur le même plan de contrôle que les certificats, les clés et les secrets.
Q : Qu'est-ce que la gestion des clés des agents IA ?
C'est la pratique qui consiste à donner à chaque agent IA ses propres identifiants, limités et révocables, et à garder les clés qu'il utilise dans un KMS ou un service de signature plutôt que dans son processus. Chaque action est journalisée avec l'agent et la personne qui en est responsable.
Q : Est-ce la même chose que donner une clé d'API à chaque agent ?
Non. Une clé d'API reste un secret unique qu'on peut copier et rejouer. Une identité cryptographique d'agent est émise, attestée et révocable comme un principal, avec une politique et un matériel de clé conçus pour que la compromission d'un agent n'entraîne pas celle de l'identifiant de la flotte.
Q : Qu'est-ce que la gestion des clés d'un serveur MCP ?
Elle couvre deux sujets : protéger les identifiants qu'un serveur MCP utilise pour atteindre les systèmes en aval (OAuth 2.1 pour les transports HTTP, pas de transmission du jeton client, secrets hors des fichiers de configuration), et encadrer ce qu'un agent IA peut faire quand il pilote une plateforme de gestion des clés via un serveur MCP.
Q : Qu'est-ce qu'un KMS agentique ?
Un KMS que des agents IA peuvent utiliser et piloter via une interface standard comme MCP, sous une politique explicite, chaque action étant liée à une identité nommée. DuoKey le met en œuvre avec un endpoint MCP cloisonné par tenant, des packs de capacités à activer et les droits propres de l'utilisateur connecté.
Q : Faut-il du MPC pour chaque agent ?
Pas pour chaque bot en lecture seule à faible risque. Pour les agents qui signent, paient ou déchiffrent des données régulées, le MPC supprime la clé unique en clair que recréent les comptes de service partagés et les secrets de coffre simples. Voir MPC vs HSM et le cas d'usage portefeuille agentique.
Q : Quel lien avec l'IAM des humains ?
Le SSO et la MFA des humains restent en place. Les agents ont besoin d'un modèle d'identité non humaine parallèle, avec les propriétés que les équipes sécurité attendent déjà pour les personnes : identité unique, moindre privilège, révocation et piste d'audit qui nomme l'acteur.
Les agents opèrent déjà en production. Les comptes de service partagés ne tiennent pas face à cette réalité. La cryptographie agentique fait de chaque agent un principal cryptographique révocable, avec une attestation sur ses actions, des clés tenues hors de son processus et une politique qu'il ne peut pas réécrire. C'est ce que « know your agent » veut dire en pratique, et c'est pourquoi elle a sa place à côté du KMS, de la PKI et des secrets, sur la même plateforme.
Écrit par
Nagib Aouini
Ressources associées
Dites-nous où le contrôle est difficile aujourd’hui. Nous vous aiderons à définir une prochaine étape concrète.
