AWS décrit une identité X.509 pour les agents d’IA

Le 20 octobre 2026, AWS a publié un tutoriel présentant une architecture de référence où des certificats X.509 donnent une identité cryptographique aux agents d’IA et où leurs requêtes sont signées. Cette approche complète l’autorisation OAuth facultative de MCP pour les transports HTTP : les deux mécanismes interviennent à des niveaux différents. Le README du dépôt associé qualifie le projet de démonstration d’apprentissage et de développement, à renforcer et à faire revoir avant un usage en production.

Ce que l’identité X.509 apporte aux agents

Un certificat X.509 associe une identité à une clé publique, ce qui permet de vérifier qu’une requête a été signée avec la clé privée correspondante. Dans l’exemple d’AWS, cette identité s’inscrit dans une infrastructure à clés publiques (PKI) reposant sur EJBCA Enterprise, le service d’autorité de certification de Keyfactor.

AWS organise le parcours en trois limites de confiance : utilisateur-système, agent-agent et agent-serveur MCP. L’exemple combine quatre contrôles : des jetons à audience restreinte, des requêtes signées, une délégation signée par l’utilisateur et des vérifications de révocation par OCSP, le protocole qui consulte le statut d’un certificat.

La limite entre autorisation du transport et identité de l’agent est utile pour choisir les contrôles à mettre en place. Un jeton destiné au seul serveur MCP restreint le service auquel il peut être présenté. Il n’identifie pas, à lui seul, l’agent qui a signé une requête.

MCP autorise certains transports HTTP, tandis que X.509 identifie l’agent

Le Model Context Protocol (MCP), qui relie des applications d’IA à des outils et à des données externes, définit une autorisation OAuth facultative pour les transports HTTP. Pour les implémentations STDIO, sa spécification recommande plutôt de récupérer les identifiants dans l’environnement. La spécification d’autorisation MCP décrit ces règles par transport.

L’autorisation MCP et l’identité X.509 peuvent donc répondre à des besoins différents au sein d’un même système. La spécification de transport ne remplace pas, dans l’architecture présentée par AWS, les certificats d’agent, les requêtes signées entre agents et la délégation de l’utilisateur.

De la connexion utilisateur à la décision du serveur MCP

Dans l’exemple AWS, l’utilisateur se connecte avec OAuth via Keycloak. Le système échange ensuite le jeton de session selon la RFC 8693 afin d’en limiter l’audience au serveur MCP ; le jeton de session complet n’est pas remis aux agents.

L’application génère localement une paire de clés RSA de 2 048 bits ou plus, puis envoie une demande de signature de certificat à EJBCA. La clé privée n’est transmise ni à EJBCA ni aux autres agents. Le certificat et la clé privée sont réunis dans un paquet PKCS#12, stocké dans AWS Secrets Manager. Le profil de certificat de l’exemple prévoit une validité de sept jours.

L’utilisateur signe ensuite une assertion de délégation qui contient notamment l’empreinte SHA-256 des certificats d’agent, son identité, ainsi que les heures d’émission et d’expiration. Quand un agent appelle un outil, il signe avec RSA-PSS-SHA256 la charge utile, le nom de l’outil, ses arguments, un horodatage et un nonce, c’est-à-dire une valeur aléatoire destinée à empêcher la réutilisation d’une requête.

Le serveur MCP vérifie le statut et l’audience du jeton, la signature de la requête, l’assertion de délégation et le certificat de l’utilisateur. Il contrôle aussi que le nom d’utilisateur du jeton, le sujet de la délégation et le nom associé au certificat de l’agent concordent.

AWS organise l’identité et l’autorisation des agents autour de trois limites de confiance dans cet exemple de référence.

Nonces, fenêtre de fraîcheur et révocation

Chaque enveloppe signée contient un nonce de 128 bits et un horodatage. La durée maximale par défaut de l’enveloppe est de 60 secondes ; le cache de rejouabilité conserve chaque nonce deux fois cette durée, soit 120 secondes avec ce réglage. Une nouvelle tentative doit utiliser une enveloppe et un nonce différents.

AWS décrit une vérification OCSP à chaque requête et indique que la validation échoue si le répondeur OCSP est inaccessible. Le parcours de déconnexion décrit par AWS révoque les certificats de l’utilisateur et des agents, supprime les secrets sans période de récupération et met fin à la session Keycloak.

Prérequis et portée du dépôt

Pour suivre l’exemple, il faut notamment Keycloak 26.2 ou une version ultérieure, Python 3.9 ou une version ultérieure, EJBCA Enterprise avec REST API V1 et un répondeur OCSP, ainsi qu’un accès à Amazon Bedrock, Amazon RDS for MySQL, Amazon SES et AWS Secrets Manager. L’exemple suppose aussi des connaissances en X.509, OCSP, OAuth 2.0, signatures RSA et magasins de clés PKCS#12.

Le README d’AWS Samples décrit le projet comme une démonstration destinée à l’apprentissage et au développement, qui nécessite un renforcement de sécurité et une revue avant toute utilisation en production. Son parcours automatisé lance Keycloak et EJBCA localement dans Docker et crée des ressources AWS, dont une base RDS pour MySQL. Le README demande de nettoyer les ressources après usage ; en mode bac à sable, Amazon SES ne peut envoyer des courriels qu’à des destinataires vérifiés.

Pour étendre l’architecture, AWS cite notamment un cache de rejouabilité distribué, un répondeur OCSP hautement disponible, des clés de signature protégées par HSM et des autorités de certification propres à chaque client. Le tutoriel distingue également la PKI utilisée pour authentifier les agents des rôles IAM qui autorisent l’accès aux services AWS.