Un agent qui tourne sur AWS, ou qui s'adresse à AWS, ne devrait jamais détenir d'identifiant longue durée. Pas d'utilisateur IAM, pas de clé d'accès dans un gestionnaire de secrets, pas de compte de service « agents » partagé. Chaque chemin d'authentification sérieux qu'offre AWS, profils d'instance, IRSA, EKS Pod Identity, fédération OIDC, IAM Roles Anywhere, AgentCore Identity, existe pour faire la même chose : échanger une preuve d'identité vérifiable contre des identifiants temporaires qui expirent d'eux-mêmes. Si votre plateforme d'agents part de cette règle, la plupart des questions difficiles se répondent toutes seules.

Hier, j'ai traité la couche protocole de ce problème sur le site jumeau : SEP-1046 donne enfin aux agents MCP un vrai parcours client credentials, avec des assertions JWT signées à la place des secrets partagés. Ce billet est la couche du dessous : quand la cible de l'agent est AWS lui-même, ou quand l'agent tourne sur AWS et doit atteindre tout le reste, à quoi ressemble réellement son identité ? La réponse, dans presque tous les cas, a la forme que SEP-1046 a retenue : un jeton signé de courte durée en entrée, des identifiants de courte durée en sortie. AWS fait tourner ce motif à grande échelle depuis des années. Il suffit d'arrêter de le combattre avec des clés statiques.

Un seul motif sous tout le reste : la fédération OIDC

Retirez les noms de produits et l'authentification des agents sur AWS se réduit à un seul mécanisme. Un fournisseur d'identité signe un JWT au sujet d'une charge de travail. Vous enregistrez l'URL d'émetteur de ce fournisseur dans IAM comme fournisseur d'identité OIDC ; IAM récupère les clés publiques depuis le jwks_uri du fournisseur via le document de découverte /.well-known/openid-configuration. La charge de travail présente son jeton à sts:AssumeRoleWithWebIdentity et obtient des identifiants de rôle qui expirent dans l'heure. La politique de confiance du rôle verrouille qui entre, avec des conditions sur les claims aud et sub du jeton.

La version que toutes les équipes plateforme connaissent déjà, c'est GitHub Actions : le runner reçoit un jeton OIDC dont le claim sub encode le dépôt et la branche, la politique de confiance du rôle matche repo:my-org/my-repo:ref:refs/heads/main, et aucune clé d'accès ne vit jamais dans les secrets du dépôt. Ce n'est pas une astuce de CI. C'est le modèle pour toute charge de travail non supervisée, agents compris. Une assertion signée, liée à une audience, valable quelques minutes, qui remplace un secret stocké : c'est exactement ce que fait private_key_jwt au niveau MCP ; l'industrie a convergé vers une seule réponse en partant de deux directions, ce qui est en général le signe que la réponse est la bonne.

L'endroit où l'agent tourne décide du mécanisme

Vous construisez rarement la fédération vous-même. Vous choisissez l'emballage qui correspond au runtime :

  • Sur EC2 ou ECS : profil d'instance ou rôle de tâche. La chaîne d'identifiants du SDK le récupère, rien à configurer dans l'agent. Si votre framework d'agents réclame ici une clé d'accès, c'est un défaut du framework, pas une exigence d'AWS.
  • Sur EKS : deux options. IRSA (IAM Roles for Service Accounts) est la plus ancienne : le cluster expose un émetteur OIDC, vous l'enregistrez dans IAM et vous annotez un ServiceAccount avec un ARN de rôle. EKS Pod Identity est la plus récente : pas d'enregistrement de fournisseur OIDC par cluster, un agent complémentaire sur le nœud échange les identifiants, et la politique de confiance du rôle cible pods.eks.amazonaws.com une seule fois au lieu d'une URL d'émetteur par cluster. Pour une flotte de clusters, Pod Identity supprime une vraie corvée ; pour un cluster unique, l'un ou l'autre convient. Les deux aboutissent au même endroit : un rôle IAM par charge de travail d'agent, aucune clé dans le pod.
  • Hors d'AWS, avec un IdP : la fédération OIDC pure, comme ci-dessus. Votre charge de travail en datacenter, votre autre cloud, votre runner SaaS s'authentifie auprès de son propre fournisseur d'identité et fédère vers AWS. C'est le motif GitHub Actions généralisé.
  • Hors d'AWS, sans IdP : IAM Roles Anywhere. Votre charge de travail présente un certificat X.509 émis par une CA que vous avez enregistrée comme ancre de confiance (AWS Private CA ou votre propre PKI) et l'échange contre des identifiants de rôle temporaires via un profil. La réserve honnête : vous héritez de la gestion du cycle de vie des certificats, émission, rotation, révocation. Si vous n'exploitez pas déjà une PKI, monter un fournisseur d'identité coûte en général moins cher en exploitation que d'en adopter une.

AgentCore Identity : la couche pensée pour les agents, au-dessus

IAM répond à « comment cette charge de travail appelle AWS ». Les agents ont deux problèmes de plus : qui a le droit d'appeler l'agent, et comment l'agent atteint des services hors AWS, Slack, GitHub, Google, au nom d'un utilisateur. C'est la tranche que couvre Amazon Bedrock AgentCore Identity, et elle mérite d'être comprise même si vous n'utilisez jamais AgentCore, parce que c'est AWS qui écrit noir sur blanc ce dont l'identité d'un agent a besoin au-delà d'un rôle.

  • Des identités de charge de travail pour les agents. Chaque agent reçoit sa propre entrée d'annuaire, pas un principal partagé. La même règle une-identité-par-charge-de-travail que pour les rôles IAM, appliquée un niveau au-dessus.
  • Authentification entrante. Les appelants atteignent l'agent soit en SigV4 pur (IAM comme d'habitude), soit via un autoriseur JWT : vous configurez une URL de découverte et les audiences autorisées, et des jetons Cognito, Okta ou Entra ID contrôlent l'accès à l'agent. AgentCore Gateway expose le même autoriseur CUSTOM_JWT pour les endpoints d'outils, et c'est ainsi qu'une passerelle façon MCP sur AWS valide les jetons dont le billet précédent décrivait l'émission.
  • Authentification sortante. Un coffre à jetons conserve les autorisations OAuth vers les services tiers, en deux temps pour le service-à-service, en trois temps quand un utilisateur a consenti une fois et que l'agent agit plus tard sur ce consentement. C'est le motif agir-au-nom-de, avec le consentement stocké côté serveur au lieu d'un refresh token collé dans une variable d'environnement.
  • Note de tarification. Via AgentCore Runtime ou Gateway, cela ne coûte rien de plus ; l'usage autonome se facture par requête réussie de jeton OAuth ou de clé API. Bon marché dans les deux cas ; le poste coûteux a toujours été l'incident que vous évitez.

La couche protocole au-dessus de tout cela continue elle aussi d'avancer. La file auth du dépôt de spec MCP contient des propositions que votre passerelle rencontrera dans l'année : securitySchemes dans les métadonnées d'outils pour les serveurs à auth mixte (SEP-1488), des erreurs d'outils standardisées qui déclenchent un flux OAuth en pleine session (SEP-1489), et des méthodes d'authentification déclarées pour les serveurs distants (SEP-2742). Si vous exploitez une passerelle MCP sur AWS, surveillez ce label comme vous surveillez les notes de version d'EKS.

L'attribution est ce que les audits demandent vraiment

Les identifiants temporaires règlent le vol ; ils ne règlent pas à eux seuls « quel agent a fait ça ». Trois habitudes ferment cet écart. Un rôle par agent, pour que la session de rôle dans CloudTrail nomme déjà la charge de travail. sts:SourceIdentity défini au moment de l'assume-role, pour que l'humain ou le système qui a déclenché l'agent survive dans chaque ligne de log en aval, même à travers un chaînage de rôles. Et des politiques de session pour réduire un rôle large à la tâche en cours, pour que le rayon d'impact d'un agent victime d'injection de prompt, ou simplement dans l'erreur, se limite aux permissions de la tâche, pas à celles du rôle. Gardez les permissions permanentes en lecture seule et verrouillez chaque action mutante ; j'ai défendu cet argument assez souvent pour que les lecteurs réguliers puissent le réciter.

À faire dès lundi

  • Lancez aws iam list-users et traitez chaque utilisateur IAM avec des clés d'accès actives appartenant à une automatisation comme un constat d'audit. Les agents sont des automatisations.
  • Associez chaque agent à son runtime et adoptez le mécanisme correspondant : rôles d'instance ou de tâche, IRSA ou Pod Identity, fédération OIDC, Roles Anywhere. Dans cet ordre de préférence.
  • Verrouillez chaque politique de confiance OIDC sur aud et sur le motif sub le plus étroit que vous puissiez écrire. Une politique de confiance sans condition sub est une porte ouverte avec un joli panneau.
  • Définissez sts:SourceIdentity dans chaque appel assume-role de vos agents et exploitez-le dans vos requêtes CloudTrail. Rattraper l'attribution après un incident ne fonctionne pas.
  • Si vous êtes sur AgentCore, placez l'autoriseur JWT devant vos agents et déplacez les autorisations OAuth tierces dans le coffre à jetons. Sinon, copiez la forme : une identité par agent, des jetons entrants validés, un consentement stocké côté serveur.

Le fil conducteur avec le billet MCP est difficile à manquer. Protocole après protocole, plateforme après plateforme, l'identité des agents converge vers des assertions signées de courte durée, la liaison d'audience et des principaux par charge de travail, et les briques existent désormais aux deux couches. Les équipes qui copient encore des clés d'accès dans des configs d'agents ne sont les précurseurs de rien du tout. Elles opposent une posture de sécurité de 2015 à des charges de travail de 2026.

À lire ensuite

Agent Toolkit for AWS: The Docs Have a New Reader couvre ce que ces agents authentifiés font concrètement de leur accès AWS. Sur le site jumeau, Enterprise MCP Auth: Agents Finally Get Service Accounts est la moitié protocole de ce billet, et ercanermis.com recense tout le reste de ce que j'écris.

Références