AISubHub/Actualités IA
Développeurs

Analyse approfondie · Environ 4 min de lecture

Une architecture AWS–Keyfactor lie les appels d’agents à une délégation signée par l’utilisateur

Certificats X.509, signatures, jetons restreints et révocation prouvent une identité, pas la justesse métier d’une action en base.

Publié ici
Date de la source
Source vérifiée

Le guide du 20 octobre décrit trois couches reliant connexion utilisateur, échanges entre agents et serveur MCP. L’exemple emploie Bedrock, Strands, Keycloak et EJBCA Enterprise. Il distingue présenter un identifiant et prouver qu’une demande précise est signée par une clé spécifiquement autorisée.

Écouter les actualités

Écoutez cet article ou poursuivez la lecture des actualités.

Une architecture AWS–Keyfactor lie les appels d’agents à une délégation signée par l’utilisateur

Préparation de la lecture…

Voix de l’appareil

La voix est traitée par votre navigateur ou appareil. AISubHub n’envoie pas le texte à une API audio. Les voix et la lecture écran verrouillé dépendent de l’appareil.

La reprise peut répéter une courte phrase.

En bref

  • Il combine enveloppes signées, délégation utilisateur et échange RFC 8693 vers un jeton à audience restreinte ; le serveur recoupe les identités.
  • La fraîcheur par défaut est de 60 secondes, les nonces aléatoires font 128 bits et le cache mémoire les conserve deux fois cette fenêtre.

Séparer pouvoir de l’utilisateur et clé de l’agent

L’application authentifie l’utilisateur puis obtient un jeton plus restreint par RFC 8693. Son audience prévue est le MCP protégé, pas tous les services du jeton initial. Elle génère localement des clés RSA d’au moins 2048 bits et transmet seulement une demande de signature à EJBCA. Certificat et clé privée sont emballés pour Secrets Manager ; la clé n’est pas envoyée à l’autorité. L’utilisateur signe une délégation listant les empreintes SHA-256 des certificats autorisés et une expiration. Les agents portent une assertion d’autorisation, sans clé privée ni jeton de session complet de l’utilisateur. Chaque agent dispose de sa propre clé.

Un certificat ne prouve pas une demande récente

L’appelant signe nom d’outil, arguments, horodatage et nonce avec RSA-PSS-SHA256. Le destinataire vérifie signature, fraîcheur, nonce unique, chaîne CA, rôle autorisé et OCSP. La fenêtre de 60 secondes expire les anciennes demandes ; le cache rejette un nonce déjà utilisé même récent. Une nouvelle tentative exige une nouvelle enveloppe et un nonce neuf, sans assurer à elle seule l’unicité de l’opération métier. Le cache d’exemple est sûr entre threads mais en mémoire. Le guide cite ElastiCache partagé pour le distribué : une réplique ne doit pas oublier un nonce accepté par une autre.

Le serveur rassemble les preuves

Avant l’action en base, il contrôle activité et audience du jeton, enveloppe, délégation et empreinte autorisée, puis recoupe nom d’utilisateur, sujet délégué et identité du certificat. La table de rôles autorise l’orchestrateur à appeler les sous-agents de base ou de courriel, sans appels latéraux ou remontants arbitraires. Selon AISubHub, cela établit qui demande et au nom de qui ; permissions de base et politique par opération restent nécessaires. Les extraits d’échange et de validation du guide utilisent des chaînes d’audience différentes. Il faut aligner émetteur et vérificateur réels, sans prendre ces fragments pour une configuration prête à fonctionner.

La révocation dépend aussi de la disponibilité

Le système refuse si OCSP est injoignable ou si un contrôle échoue. La déconnexion révoque les certificats de l’utilisateur et des trois agents, supprime les secrets et termine la session d’identité. Révoquer l’utilisateur invalide la délégation aux contrôles suivants ; le guide parle de propagation immédiate par OCSP à chaque demande. Cela doit être vérifié selon répondants, caches, pannes et horloges, et non traité comme une latence universelle mesurée. Le profil de certificat dure sept jours. Haute disponibilité, état anti-rejeu partagé, rotation et conservation d’audit font partie de la recette. Guardrails et outils limités complètent l’identité, mais ni signatures ni filtres ne prouvent la justesse de chaque opération générée.

Pourquoi cela compte

Analyse AISubHub : identité et délégation doivent être imposées à la frontière de l’outil, pas seulement dans les instructions du modèle. Une chaîne valide ne prouve ni la justesse du SQL ni le respect d’une règle métier.

Limites et disponibilité

C’est une référence, pas une certification indépendante ; nous ne l’avons pas exécutée. Elle exige Keycloak 26.2 ou ultérieur et EJBCA Enterprise avec OCSP. Coûts de licence, déploiement et services ne sont pas chiffrés ici.

Sources et preuves

AWS Machine Learning Blog

Date de la source: · Source vérifiée:

Articles assistés par IA, vérifiés avec les sources primaires citées. Les affirmations des fournisseurs sont attribuées ; la présence ne vaut pas recommandation.