Sécuriser l'identité des agents d'IA avec une PKI X.509 sur AWS

Lorsque des agents d'IA accèdent à des bases de données, des API et des opérations métier sensibles, l'établissement d'une identité cryptographique via une infrastructure à clé publique (PKI) X.509 devient une exigence critique. Le défi principal consiste à prouver quel agent a émis une requête, à empêcher la falsification entre agents et à confirmer que chaque agent n'agit que pour le compte d'un utilisateur autorisé. Les approches traditionnelles, telles que le partage de clés API entre composants ou la transmission de tokens OAuth à travers des chaînes d'agents, ne suffisent pas à répondre aux exigences de zero-trust que les déploiements d'entreprise requièrent.

Les frameworks d'IA multi-agents utilisent de plus en plus le Model Context Protocol (MCP) pour connecter les agents à des outils externes et à des sources de données. MCP définit la manière dont un agent propulsé par un grand modèle de langage (LLM) invoque des outils tels que des requêtes de base de données ou des opérations de messagerie. Cependant, MCP ne dispose d'aucun standard d'authentification intégré. Il est indépendant du transport par conception. Cela crée une lacune critique : sans mécanismes d'identité appropriés, n'importe quel composant pourrait usurper l'identité d'un agent, rejouer des informations d'identification interceptées ou invoquer des outils sans autorisation.

Dans cet article, nous vous montrons comment combler cette lacune en utilisant Keyfactor EJBCA combiné aux services AWS. EJBCA est une plateforme PKI qui prend en charge le déploiement haute disponibilité, l'automatisation via API REST et la validation par le protocole Online Certificate Status Protocol (OCSP). L'architecture de référence utilise quatre mécanismes de sécurité complémentaires. Premièrement, des enveloppes de requêtes signées fournissent une preuve cryptographique de possession sur chaque appel d'agent. Deuxièmement, des assertions de délégation signées par l'utilisateur autorisent les agents sans partage d'informations d'identification. Troisièmement, des tokens à portée d'audience conformes à la RFC 8693 limitent la portée de l'exposition en cas de divulgation d'un seul token. Quatrièmement, la vérification de révocation OCSP en temps réel propage immédiatement les changements d'informations d'identification à travers tous les agents.

La solution utilise Amazon Bedrock pour l'inférence LLM via le AWS Strands Agents SDK. Bien que cette architecture de référence utilise une base de données comme ressource protégée, le même schéma d'authentification s'applique à tout serveur d'outils compatible MCP. Le code source complet de tous les exemples est disponible dans le dépôt GitHub associé.

À propos de Keyfactor EJBCA

Keyfactor fournit une plateforme de gestion des identités de machines largement adoptée, utilisée par plus de 1,500 clients entreprises dans le monde, selon Keyfactor. Ces organisations couvrent les services financiers, la santé, l'industrie manufacturière et le gouvernement. Keyfactor aide les organisations à établir et maintenir la confiance cryptographique grâce à la gestion du cycle de vie des certificats, aux opérations PKI et à la gouvernance des identités de machines.

EJBCA Enterprise est la plateforme d'autorité de certification (CA) et de PKI de Keyfactor, conçue pour le déploiement haute disponibilité et l'automatisation via API REST. Disponible en tant que produit entreprise, EJBCA assure l'émission de certificats X.509, la validation OCSP, la distribution des listes de révocation de certificats (CRL) et une gestion complète du cycle de vie des certificats à la fois via une console web et via une API REST. EJBCA prend en charge le déploiement sur site, en conteneurs ou sur Amazon Elastic Compute Cloud (Amazon EC2).

Le partenariat entre AWS et Keyfactor réunit des services gérés AWS (Amazon Bedrock, AWS Secrets Manager, Amazon Relational Database Service (Amazon RDS)) avec une infrastructure PKI prenant en charge la gestion du cycle de vie des certificats, l'enrôlement automatisé et la révocation en temps réel. Cette combinaison comble une lacune de l'écosystème des agents d'IA. Tandis qu'AWS fournit les couches de calcul, de stockage et d'inférence IA, Keyfactor fournit la couche d'identité cryptographique qui lie les agents à des informations d'identification vérifiables, révocables et à durée de vie courte. Cette architecture de référence conjointe, développée en collaboration par les équipes d'ingénierie d'AWS et de Keyfactor, montre comment intégrer ces technologies. Vous pouvez adapter les schémas présentés ici à vos propres déploiements multi-agents.

Aperçu de la solution

L'architecture met en œuvre trois couches d'authentification, chacune traitant une frontière de confiance différente dans la chaîne de communication des agents. Ces trois couches utilisent les quatre mécanismes de sécurité présentés précédemment : les enveloppes signées pour la preuve de possession, les assertions de délégation pour une autorisation sans informations d'identification, les tokens à portée d'audience pour la limitation de l'exposition et OCSP pour la révocation en temps réel. Les mécanismes se combinent entre les couches comme indiqué dans le tableau suivant.

La figure 1 montre les trois couches d'authentification et la manière dont les identifiants circulent entre l'utilisateur, les agents et le serveur d'outils MCP. Le diagramme illustre la séparation entre les identifiants de l'utilisateur (qui restent dans le flux de connexion), les identifiants des agents (délimités par agent) et la chaîne de délégation qui les relie.

Figure 1 : Architecture d'authentification PKI à trois couches pour les systèmes d'agents IA sur AWS

La figure 2 illustre le flux de trafic détaillé lors d'une session utilisateur typique. Elle montre la séquence des étapes d'authentification, de la connexion à l'émission des certificats, en passant par la délégation aux agents, l'invocation des outils et le nettoyage de la session.

Figure 2 : Flux de trafic d'authentification depuis la connexion de l'utilisateur jusqu'au nettoyage de session, en passant par la délégation à l'agent et l'invocation d'outils

Services AWS utilisés

Les services AWS suivants constituent le fondement de l'architecture de référence.

Présentation de la solution

Les étapes suivantes parcourent chaque composant de l'architecture, depuis la connexion initiale de l'utilisateur jusqu'au nettoyage de session. Chaque étape s'appuie sur la précédente, établissant une chaîne de confiance qui relie l'utilisateur humain à l'exécution finale de l'outil.

Prérequis

• Un compte AWS actif avec accès à Amazon Bedrock, Amazon RDS for MySQL, Amazon SES et AWS Secrets Manager.
• Keycloak 26.2 ou version ultérieure (requise pour l'échange de jetons conforme à la norme RFC 8693. Les versions antérieures utilisent un échange hérité qui est incompatible).
• Keyfactor EJBCA Enterprise avec l'API REST V1 et un répondeur OCSP configuré.
• Certificat d'administrateur de l'API EJBCA (api-admin.p12) pour l'authentification à l'API REST.
• Environnement de développement Python 3.9+.
• Familiarité avec les certificats X.509, OCSP, OAuth 2.0, les signatures numériques RSA et les magasins de clés PKCS#12.

Étape 1 : Connexion de l'utilisateur, émission de certificat et création de la délégation

Le flux de connexion établit l'identité de l'utilisateur au moyen de trois mécanismes, puis délègue l'autorité aux agents d'IA sans partager les identifiants de l'utilisateur. Cette séparation est cruciale : les agents reçoivent une preuve d'autorisation sans jamais détenir la clé privée de l'utilisateur ni le jeton OAuth de session complète.

Premièrement, l'application authentifie l'utilisateur auprès de Keycloak à l'aide d'un password grant OAuth 2.0, recevant un jeton d'accès de session complète et un jeton de rafraîchissement. Immédiatement après, l'application effectue un échange de jetons RFC 8693 pour obtenir un jeton à périmètre réduit. L'audience de ce jeton est limitée au serveur MCP. Seul ce jeton limité est remis aux agents. S'il est exposé par inadvertance, il ne peut accéder à aucun autre service de l'organisation.

Deuxièmement, l'application génère localement une paire de clés RSA 2048+ et soumet une demande de signature de certificat (CSR) à EJBCA via le point de terminaison de l'API REST pkcs10enroll . EJBCA signe la CSR et renvoie le certificat. L'application regroupe le certificat et la clé privée dans un conteneur PKCS12 et le stocke dans AWS Secrets Manager. La clé privée ne quitte jamais le périmètre de l'application. Elle n'est pas envoyée à EJBCA, n'est pas partagée avec les agents et n'est pas stockée sur le système de fichiers. Trois certificats d'agent sont émis selon le même flux basé sur la CSR, un par rôle d'agent.

Troisièmement, la clé privée de l'utilisateur signe une assertion de délégation. Il s'agit d'un document JSON listant les empreintes SHA-256 des trois certificats d'agent, ainsi que le nom de sujet de l'utilisateur, l'heure d'émission et l'expiration. Cette délégation prouve que l'utilisateur a autorisé ces agents spécifiques à agir en son nom. Les agents portent cette délégation au lieu du certificat de l'utilisateur.

# RFC 8693 Token Exchange - downscope to MCP audience
downscoped_token = keycloak.token_exchange(
    original_token, audience="mysql-mcp-server", scope="database:write"
)
# Client-side key generation (user key never leaves this flow)
private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
csr = build_csr(private_key, f"CN={username},E={username}@org.com")
user_cert = ejbca.pkcs10enroll(csr, ca_name="UserCA")
# User signs delegation over agent cert fingerprints
delegation = mint_delegation(
    username=username,
    user_cert_pem=user_cert,
    user_key_pem=private_key_pem,
    agent_cert_pems=[orch_cert, mysql_cert, email_cert]
)
# Result: {sub, agent_fingerprints[], iat, exp, user_cert_pem, signature_b64}

Étape 2 : Enveloppes signées d'agent à agent

Lorsque l'agent orchestrateur achemine une requête vers un sous-agent (tel que l'agent MySQL ou l'agent Email), il ne se contente pas de transmettre son certificat pour s'identifier. À la place, il signe l'intégralité de la charge utile de la requête, y compris le nom de l'outil, les arguments, un horodatage et un nonce aléatoire cryptographique, à l'aide de sa clé privée avec RSA-PSS-SHA256. L'enveloppe signée qui en résulte fournit une preuve de possession. L'agent destinataire peut vérifier que l'appelant détient réellement la clé privée correspondant au certificat présenté.

L'agent destinataire effectue six contrôles de validation sur l'enveloppe avant de traiter la requête :

1. Vérification de la signature : Prouve que l'expéditeur possède la clé privée (preuve de possession).
2. Fraîcheur de l'horodatage : L'enveloppe doit être datée de moins de ENVELOPE_MAX_AGE_SECONDS (60 secondes par défaut) par rapport à l'heure actuelle.
3. Unicité du nonce : Le ReplayCache rejette tout nonce déjà vu, empêchant la relecture des requêtes.
4. Validation de la chaîne de l'AC : Le certificat de l'expéditeur doit être chaîné à l'AC de confiance (UserCA.pem).
5. Autorisation des rôles : Le suffixe de rôle du CN du certificat doit figurer dans ALLOWED_CALLER_ROLES pour cet agent.
6. Vérification de révocation OCSP : Une vérification en temps réel auprès d'EJBCA confirme que le certificat n'a pas été révoqué.

Si l'orchestrateur doit renvoyer la même invite (par exemple, après une défaillance transitoire), il doit créer une nouvelle enveloppe avec un nonce frais. Les anciennes enveloppes ne peuvent pas être rejouées, même par l'expéditeur légitime.

# Orchestrator signs request to sub-agent
envelope = sign_envelope(
    payload={"tool": "query_database", "args": {"sql": "SELECT ..."}},
    cert_pem=orchestrator_cert_pem,
    private_key_pem=orchestrator_key_pem
)
# envelope: {payload_b64, cert_pem, timestamp, nonce, signature_b64, alg}
# Sub-agent verifies (six checks)
verified_payload = verify_envelope(
    envelope,
    allowed_role="orchestrator-agent",
    ca_cert_pem=ca_pem,
    replay_cache=cache
)

Étape 3 : authentification du serveur MCP

Le serveur MCP (FastMCP) est la dernière frontière de confiance avant toute opération de base de données. Il effectue quatre vérifications de validation à chaque invocation d'outil, mettant en œuvre une défense en profondeur. Même si un identifiant fait l'objet d'un accès non autorisé, les vérifications restantes empêchent toute opération non autorisée.

La séquence d'authentification :

1. Introspection du jeton : Un POST vers le point de terminaison /token/introspect de Keycloak vérifie que le jeton est actif et que son audience contient « mcp-server ». Un jeton de session complète sans la bonne audience est rejeté.
2. Vérification de l'enveloppe : L'enveloppe signée de l'agent est validée pour l'exactitude de la signature, la fraîcheur de l'horodatage, l'unicité du nonce, la confiance dans la chaîne de l'AC, la correspondance du rôle (mysql-agent), et la non-révocation OCSP.
3. Vérification de la délégation : L'assertion de délégation de l'utilisateur est validée. La signature prouve que le détenteur de la clé de l'utilisateur a autorisé cette délégation, l'empreinte du certificat de l'agent appelant figure dans la liste des entités autorisées, et le certificat de l'utilisateur est vérifié via OCSP.
4. Contrôle croisé d'identité : Le nom d'utilisateur du jeton, le sujet de la délégation et le préfixe du CN du certificat de l'agent doivent tous correspondre. Cela confirme une chaîne d'identité unique et cohérente, de l'utilisateur jusqu'à l'exécution de l'outil.

# MCP Server - Four validation checks
# 1. Token: must be active with correct audience
info = introspect(token)
assert info["active"] and "mcp-server" in info["aud"]
# 2. Envelope: proof-of-possession + freshness + replay + CA + role + OCSP
payload = verify_envelope(envelope, "mysql-agent", ca_pem, replay_cache)
# 3. Delegation: user authorized this agent + user cert not revoked
claims = verify_delegation(delegation, agent_cert_pem, ca_pem)
# 4. Cross-check: consistent identity chain
assert token_username == claims["sub"] == agent_cn.rsplit("_", 1)[0]
# All checks passed - execute tool
result = execute_sql(payload["args"]["sql"])

Étape 4 : prévention de la relecture

Chaque enveloppe signée transporte un nonce unique, une chaîne hexadécimale aléatoire de 128 bits générée avec le module secrets de Python. Le ReplayCache est un stockage en mémoire thread-safe qui mémorise chaque nonce jusqu'à l'expiration de sa fenêtre de fraîcheur (2x ENVELOPE_MAX_AGE_SECONDS). Si le même nonce apparaît dans une seconde requête, l'enveloppe est immédiatement rejetée, même si sa signature est valide et son horodatage récent.

La validation de l'horodatage complète la vérification du nonce. L'horodatage d'une enveloppe doit se situer à moins de ENVELOPE_MAX_AGE_SECONDS (60 secondes par défaut) de l'heure actuelle du serveur. Ensemble, ces mécanismes répondent à quatre scénarios d'accès non autorisé :

• Rejeu enregistré : Un utilisateur non autorisé capture une enveloppe valide et la soumet à nouveau plus tard. Le nonce a déjà été vu.
• Livraison retardée : Une enveloppe interceptée en transit arrive après la fenêtre de fraîcheur. La vérification de l'horodatage échoue.
• Réutilisation d'une requête périmée : Une ancienne enveloppe mise en cache par un proxy est soumise à nouveau. Les vérifications du nonce et de l'horodatage échouent toutes les deux.
• Falsification précalculée : Un utilisateur non autorisé ne peut pas prédire les nonces futurs pour pré-signer des enveloppes.

Étape 5 : génération de clés côté client

Une propriété de sécurité essentielle de cette architecture est que les clés privées sont générées localement et ne sont jamais transmises à aucun système externe. L'application génère des paires de clés RSA 2048+ à l'aide de la bibliothèque Python cryptography. Elle construit une CSR contenant uniquement la clé publique et les informations de sujet, et envoie uniquement la CSR à EJBCA via le pkcs10enroll endpoint.

EJBCA valide la CSR, applique le profil de certificat (validité de 7 jours, contraintes d'utilisation de la clé), le signe avec la clé de la CA et renvoie le certificat émis. L'application regroupe ensuite la clé privée détenue localement avec le certificat renvoyé dans un conteneur PKCS12 et le stocke dans AWS Secrets Manager.

Cette conception offre plusieurs propriétés de sécurité :

• La clé privée de l'utilisateur n'est utilisée qu'à la connexion pour signer l'assertion de délégation. Elle n'est jamais partagée avec les agents.
• La clé privée de chaque agent n'est utilisée que par cet agent pour signer les enveloppes. Elle n'est jamais partagée entre les agents.
• EJBCA ne voit ni ne stocke jamais les clés privées. Elle fonctionne purement comme une autorité de certification.
• Si Secrets Manager fait l'objet d'un accès non autorisé, le mot de passe PKCS12 (stocké séparément) ajoute une couche supplémentaire.
• Le matériel de clé peut être renouvelé indépendamment en se réinscrivant avec une nouvelle CSR à la prochaine connexion.

Étape 6 : déconnexion complète et révocation des informations d'identification

La déconnexion déclenche une cascade de révocations qui invalide immédiatement toutes les informations d'identification en cours. La séquence aboutit à l'absence totale d'informations d'identification valides une fois terminée :

1. Révoquer le certificat utilisateur dans EJBCA : Cela invalide immédiatement toutes les délégations en cours, car la vérification de délégation contrôle le certificat de l'utilisateur via OCSP en temps réel.
2. Révoquer les trois certificats d'agent : Cela invalide toutes les enveloppes signées en cours, puisque la vérification des enveloppes inclut OCSP.
3. Supprimer tous les secrets d'AWS Secrets Manager : en utilisant ForceDeleteWithoutRecovery pour une suppression immédiate sans fenêtre de récupération.
4. Terminer la session Keycloak : Invalide le jeton downscoped via le point de terminaison de terminaison de session.

La cascade de révocation est la propriété de sécurité clé. La révocation d'un seul certificat utilisateur au niveau PKI révoque rapidement toute l'autorité en aval des agents sans avoir besoin de révoquer individuellement des jetons, de supprimer des sessions ou de contacter chaque agent. OCSP fournit le mécanisme de propagation, et comme chaque requête vérifie OCSP, l'effet est immédiat.

Considérations de sécurité

Les choix de conception de cette architecture répondent à plusieurs propriétés de sécurité importantes pour les déploiements multi-agents en production.

Isolation des clés privées. La clé privée de l'utilisateur n'existe que pendant le flux de connexion et sert uniquement à signer la délégation. Les clés des agents sont limitées à chaque agent et ne sont jamais partagées. Aucun matériel de clé ne franchit les frontières de confiance.

Délégation comparée au partage d'identifiants. Les agents prouvent leur autorité par une chaîne cryptographique (délégation vers empreinte d'agent vers signature d'enveloppe) sans jamais détenir les identifiants de l'utilisateur. Si une clé d'agent est exposée, seule la clé de cet agent est révélée, pas celle de l'utilisateur.

Jetonss limités à l'audience. L'échange de jetons RFC 8693 produit un jeton accepté uniquement par le serveur MCP. Un jeton downscoped divulgué par inadvertance ne peut pas s'authentifier auprès des API d'administration de Keycloak, d'autres services, ni même d'une autre instance du serveur MCP.

Prévention des rejeux. La combinaison de nonces par requête et d'une fenêtre de fraîcheur de 60 secondes confirme que chaque requête est à usage unique et limitée dans le temps. Le ReplayCache est thread-safe et s'auto-nettoie.

Conception fail-closed. Chaque échec de validation entraîne un refus immédiat. OCSP injoignable : refus. Signature invalide : refus. Horodatage expiré : refus. Nonce rejoué : refus. Mauvaise audience : refus. Il n'y a aucune dégradation graceful pour les vérifications de sécurité.

Cascade de révocation. La révocation d'un seul certificat utilisateur invalide rapidement toutes les délégations, toute l'autorité des agents et toutes les enveloppes en cours. Cela est propagé via OCSP en temps réel sans nécessiter de nettoyage individuel des identifiants.

Chaîne de confiance à sens unique. La table ALLOWED_CALLER_ROLES impose que seuls orchestrator-agent peuvent appeler mysql-agent et email-agent. Les sous-agents ne peuvent pas s'appeler mutuellement, ne peuvent pas appeler vers le haut l'orchestrateur et ne peuvent pas usurper l'identité de l'utilisateur.

Considérations de gouvernance de l'IA

L'architecture PKI fournit des limites de comportement intégrées pour les agents IA de ce système. Les déploiements en production devraient utiliser Amazon Bedrock Guardrails pour appliquer le filtrage de contenu, l'évitement de sujets et les vérifications d'ancrage sur les réponses des agents, en complément des contrôles d'accès basés sur la PKI décrits dans cet article.

• Limites d'outils: l'agent IA fonctionne sous de strictes contraintes d'outils. Il ne peut invoquer que des outils MCP prédéfinis (execute_sql, describe_table, list_tables). L'agent ne peut pas exécuter de code arbitraire ni accéder à des ressources hors de son périmètre de certificat.
• Supervision humaine: toutes les actions des agents sont journalisées et auditables. AWS CloudTrail capture les appels d'API AWS, et le serveur MCP journalise chaque invocation d'outil validée avec la chaîne d'identité complète (utilisateur, agent, horodatage et opération).
• Gestion des données: Les requêtes et les résultats des utilisateurs restent dans les limites de la session authentifiée. Le token délimité par audience restreint l'accès aux données à l'instance spécifique du serveur MCP.
• Des limites de comportement basées sur les certificats: Les agents ne peuvent invoquer que les outils pour lesquels ils détiennent des certificats valides. Un agent sans mysql-agent certificat ne peut pas accéder à la base de données, quel que soit ce que le LLM pourrait générer comme instructions.

Extension de l'architecture

Vous pouvez étendre cette architecture pour prendre en charge des types d'agents supplémentaires, la mise à l'échelle horizontale et l'isolation multi-tenant. Les paragraphes suivants décrivent les points d'extension les plus courants.

• Pour ajouter de nouveaux types d'agents, il vous suffit d'ajouter une entrée dans ALLOWED_CALLER_ROLES. Les certificats sont automatiquement émis à la connexion, et l'assertion de délégation inclut dynamiquement l'empreinte du nouvel agent. Aucune modification de l'infrastructure n'est requise.
• Pour la mise à l'échelle horizontale, vous pouvez déployer le répondeur OCSP d'EJBCA en mode haute disponibilité derrière un équilibreur de charge. AWS Secrets Manager prend en charge des taux de requêtes élevés adaptés à cette charge de travail. Le ReplayCache peut être adossé à Amazon ElastiCache pour des déploiements distribués.
• Pour renforcer l'architecture pour la production, vous pouvez utiliser des clés de signature EJBCA adossées à un module de sécurité matérielle (HSM) via AWS CloudHSM ou un HSM sur site. L'agrafage des réponses OCSP réduit la latence de validation, et les journaux Certificate Transparency fournissent une piste d'audit complète des certificats émis.
• Pour les déploiements multi-tenant, vous pouvez créer des autorités de certification par tenant ou des autorités de délégation par tenant pour une isolation cryptographique des tenants. Combiné à des comptes AWS par tenant, cela offre une isolation forte entre les tenants.
• Vous pouvez également compléter l'identité des agents basée sur la PKI avec des rôles AWS Identity and Access Management (IAM). Utilisez la PKI pour l'authentification agent-à-agent et IAM pour l'autorisation des services AWS. Les deux systèmes fonctionnent indépendamment, offrant une défense en profondeur.

Nettoyage

Pour éviter des frais continus, supprimez les ressources créées lors de cette procédure :

• Supprimez l'instance Amazon RDS for MySQL (ou la pile AWS CloudFormation si vous avez utilisé l'installation par script).
• Supprimez tous les secrets d'AWS Secrets Manager, y compris les certificats utilisateurs et les certificats d'agents sous le mcp/ préfixe.
• Supprimez l'adresse e-mail d'expéditeur vérifiée d'Amazon SES.
• Arrêtez les instances Amazon EC2 exécutant Keycloak et EJBCA (si déployées pour cette démonstration).
• Révoquez et supprimez tous les certificats de test dans EJBCA à l'aide de la console d'administration EJBCA ou de l'API REST.
• Supprimez le realm Keycloak (mcp-realm) et les clients associés.
• Si vous avez utilisé la configuration par script, exécutez ./scripts/cleanup.sh (Linux) ou ./scripts/cleanup.bat (Windows) pour automatiser ces étapes.

Conclusion

Dans cet article, nous avons présenté une architecture de référence pour sécuriser les communications des agents d'IA à l'aide d'une PKI X.509 avec Keyfactor EJBCA et des services AWS. Cette architecture comble le déficit fondamental d'identité dans les systèmes d'IA multi-agents grâce à quatre mécanismes complémentaires :

• Les enveloppes de requêtes signées fournissent une preuve cryptographique de possession sur chaque appel inter-agents, rendant considérablement plus difficile pour une partie non autorisée l'usurpation de l'identité d'un agent ou la relecture de ses requêtes.
• Les assertions de délégation signées par l'utilisateur découplent l'autorisation du partage d'identifiants. Les agents prouvent qu'ils sont autorisés à agir au nom de l'utilisateur sans détenir la clé privée de l'utilisateur ni un jeton de session complète.
• Les jetons à portée d'audience selon la RFC 8693 limitent l'exposition liée à la divulgation de tout jeton à une seule frontière de service.
• La vérification de révocation OCSP en temps réel confirme que la révocation des identifiants prend effet immédiatement dans tout le système. La révocation d'un certificat utilisateur met rapidement fin à toutes les autorités d'agent en aval.

Cette architecture est indépendante des frameworks. Bien que nous l'ayons démontrée avec le SDK AWS Strands Agents et FastMCP, les mêmes schémas de PKI s'appliquent à LangChain, CrewAI, AutoGen ou tout autre framework multi-agents qui utilise des protocoles d'outils. À mesure que les agents d'IA se multiplient et accèdent à des opérations de plus en plus sensibles, l'infrastructure d'identité des agents passe d'optionnelle à essentielle.

Pour commencer avec cette architecture de référence, consultez le dépôt GitHub accompagnant l'article. Pour plus d'informations sur les services utilisés, consultez les ressources suivantes :

• Amazon Bedrock
• Guide de l'utilisateur Amazon Bedrock
• Keyfactor EJBCA Enterprise
• Spécification MCP
• SDK AWS Strands Agents
• Introducing Strands Agents, an Open Source AI Agents SDK (article de blog AWS Open Source)

À propos des auteurs