AgentCorruption : risques liés aux métadonnées et à IAM

L’étude de Zenity publiée en octobre 2026 indique que des outils influencés par le modèle pouvaient atteindre les métadonnées du runtime AgentCore et que les anciennes autorisations du rôle par défaut élargissaient l’accès. AWS considère l’accès aux identifiants du rôle propre au runtime comme attendu et recommande le moindre privilège. L’étude de Zenity ne cite aucun identifiant CVE et n’établit pas de compromission de clients.^{[1], [4]}

💡 Explication en Langage Simple (ELI5)

Imaginez un agent dans un atelier, muni d’un badge pour les tâches confiées. Selon Zenity, un outil guidé par le modèle pouvait demander ce badge au guichet interne ; les anciennes autorisations du badge ouvraient alors plus de pièces que nécessaire. AWS indique qu’il est normal que l’agent reçoive, dans l’atelier, les identifiants de son propre rôle. La défense consiste à limiter les portes ouvertes par chaque badge et à contrôler les outils autorisés à effectuer des requêtes internes.^{[1], [4]}

Concepts Clés et Termes

AgentCorruption: Nom donné par Zenity Labs à sa chaîne de recherche contrôlée sur Amazon Bedrock AgentCore. Zenity ne cite aucun identifiant CVE et son étude n’établit pas de compromission de clients.^{[1], [7]}
MMDS et identifiants du rôle d’exécution: AWS indique que le code exécuté dans une microVM AgentCore peut obtenir via MMDS des identifiants temporaires du rôle d’exécution de ce runtime. Le service considère ce comportement comme normal ; les autorisations du rôle déterminent ce que ces identifiants permettent.^{[4], [5]}
Portée des autorisations: Le rôle d’exécution définit les actions et ressources AWS accessibles au code de l’agent. Zenity rapporte que les autorisations historiques étaient étendues dans le même compte et la même région. AWS recommande le moindre privilège ; l’autorisation dépend des politiques d’identité et de ressource applicables à l’opération. AWS précise que l’accès entre comptes exige une autorisation explicite sur le rôle et la ressource cible.^{[3], [1], [6]}
CWE-918 — classification éditoriale: Cette page utilise CWE-918 comme classification éditoriale pour une requête lancée par un outil d’agent vers un service interne de métadonnées. AWS n’a pas attribué cette CWE ; l’accès aux métadonnées est un comportement documenté.^{[8], [4], [1]}

Correspondances de référentiels

Correspondance conceptuelle de FlawOpen avec MITRE CWE ; aucun fournisseur ni enregistrement CVE n’a attribué cet identifiant de faiblesse à cette démonstration de recherche. CWE-918

Déroulement de l'Attaque Étape par Étape

Étape 1

Un agent public dispose d’un outil sortant

Zenity a testé un agent AgentCore accessible publiquement et doté d’un outil capable d’envoyer des requêtes sortantes. Le scénario suppose un agent joignable et un chemin d’outil influençable par le modèle ; il ne décrit pas tous les déploiements.^{[2], [1]}

Étape 2

L’influence du modèle atteint les métadonnées

Zenity indique que son agent de test pouvait être amené à interroger son service local de métadonnées. AWS documente l’accès du code de la microVM aux identifiants MMDS ; le débat porte sur le chemin de confiance entre modèle et outil et sur l’autorité de ces identifiants, pas sur l’existence des identifiants propres au runtime.^{[2], [1], [4]}

Étape 3

La réponse représente le rôle de l’agent

AWS indique que MMDS fournit des identifiants temporaires pour le rôle d’exécution configuré. Ces identifiants n’autorisent pas automatiquement l’accès à toutes les ressources ; les politiques IAM et de ressource applicables définissent les opérations permises. AWS précise que l’accès entre comptes exige des autorisations explicites sur le rôle et la ressource cible.^{[4], [6], [1]}

Étape 4

Les anciennes autorisations ont élargi l’impact

Zenity rapporte que le rôle par défaut de l’époque autorisait des opérations sur d’autres ressources AgentCore du même compte et de la même région, notamment l’invocation, l’accès aux sessions/événements, les opérations de mémoire et l’accès aux secrets. Zenity indique qu’AWS a fortement restreint ce rôle par défaut au 29 septembre 2026. Cela ne prouve pas que les rôles gérés par les clients aient été modifiés automatiquement.^{[3], [1], [6]}

Étape 5

Les contrôles actuels protègent des frontières différentes

Zenity indique que les nouveaux agents utilisaient MMDSv2 depuis le 14 février 2026. La documentation AWS actuelle exige l’activation de MMDSv2 pour invoquer le runtime depuis le 30 juin 2026. AWS documente toujours l’accès du code de la microVM aux identifiants du rôle ; MMDSv2 ne remplace donc ni le moindre privilège IAM ni le contrôle des outils influencés par le modèle. Cette distinction est une déduction défensive fondée sur les sources.^{[5], [4], [1]}

Éléments de preuve et portée actuelle

Frontière	Éléments de preuve	Mesure défensive
Accès aux métadonnées	Zenity rapporte un accès lors de son test ; AWS documente les identifiants MMDS pour le code exécuté dans la microVM.	Considérez le code de l’agent et les outils influencés par le modèle comme porteurs du rôle d’exécution.
Autorisations du rôle	Zenity rapporte des paramètres historiques très larges. AWS indique que l’accès entre comptes exige une autorisation explicite sur le rôle et la ressource cible ; les autres opérations suivent leurs politiques IAM et de ressource applicables.	Inspectez les rôles déployés et les politiques de ressource ; vérifiez les politiques applicables à chaque opération et ne déduisez pas la portée d’un prompt ou d’une valeur par défaut du service.
Modification du rôle par défaut	Zenity dit avoir constaté qu’AWS avait restreint le rôle par défaut le 29 septembre 2026. L’étude ne dit pas que les rôles gérés par les clients ont été modifiés automatiquement ; elle ne cite aucun CVE et n’établit pas de compromission de clients.	Vérifiez les rôles effectifs dans chaque compte et chaque région ; ne supposez pas que les rôles des clients ont changé.
MMDSv2	Zenity date l’adoption de MMDSv2 pour les nouveaux agents au 14 février 2026 ; la documentation AWS actuelle l’exige pour invoquer le runtime depuis le 30 juin 2026. AWS documente toujours l’accès aux identifiants depuis la VM.	Activez MMDSv2 et limitez séparément les actions, ressources et appelants autorisés par le rôle.

Analyse de Cause Racine

Il faut évaluer séparément deux frontières : les outils influencés par le modèle peuvent envoyer des requêtes depuis le runtime, tandis que le rôle d’exécution détermine l’autorité de ces requêtes. AWS considère l’accès aux identifiants propres au runtime comme normal ; l’impact entre agents rapporté par Zenity dépendait de l’étendue historique du rôle. Activer MMDSv2 ne réduit pas les autorisations IAM, et réduire celles-ci n’empêche pas les requêtes internes pilotées par le modèle. Examinez séparément les sorties réseau des outils et l’autorisation IAM ; limiter les sorties réseau ne prouve pas que le code de la microVM ne peut pas accéder à MMDS.^{[1], [3], [4], [5]}

Code Source : Vulnérable vs Sécurisé

Exemples de déclarations IAM à titre illustratif uniquement ; ils ne représentent ni la politique historique d’AWS ni sa modification ultérieure du rôle par défaut. AWS recommande de limiter les autorisations du runtime aux ARN de ressources précis et d’éviter les jokers. La première déclaration montre une portée large ; la seconde limite l’invocation à un runtime approuvé si cette autorisation est nécessaire. Supprimez-la si elle ne l’est pas. Vérifiez la compatibilité action/ressource et les politiques de ressource associées pour le déploiement réel ; il ne s’agit pas d’une politique complète prête à déployer.^{[3], [6], [5]}

IMPLÉMENTATION VULNÉRABLE

{
  "Effect": "Allow",
  "Action": "bedrock-agentcore:InvokeAgentRuntime",
  "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT:runtime/*"
}

PATCH SÉCURISÉ ET ROBUSTE

{
  "Effect": "Allow",
  "Action": "bedrock-agentcore:InvokeAgentRuntime",
  "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT:runtime/APPROVED_RUNTIME_ID"
}

Liste de Contrôle de Sécurité pour l'Ingénierie

✓Inventoriez chaque rôle d’exécution dans tous les comptes et toutes les régions ; comparez ses autorisations effectives aux politiques AWS actuelles et aux politiques gérées par le client.^{[6], [5]}
✓Supprimez l’invocation entre runtimes, l’accès aux conversations, la récupération de secrets, l’écriture de mémoires et l’accès aux images sauf besoin documenté pour chaque action.^{[3], [6]}
✓Si un runtime doit en invoquer un autre, limitez les politiques d’identité et de ressource au runtime et au point de terminaison approuvés ; vérifiez que les autres runtimes sont refusés.^[6]
✓Activez MMDSv2 conformément aux exigences AWS, mais traitez l’accès du code de la microVM aux identifiants du rôle comme une frontière d’autorisation distincte.^{[5], [4], [1]}
✓Réduisez les destinations que les outils influencés par le modèle peuvent contacter aux besoins du service ; considérez cela comme une réduction du risque de sortie, pas comme une preuve d’inaccessibilité de MMDS depuis la VM.^[5]
✓Attribuez aux agents publics des rôles dont les privilèges ne dépassent pas ceux des principaux autorisés à les appeler ; vérifiez les autorisations effectives avec IAM Access Analyzer et des tests négatifs d’autorisation.^{[5], [6]}

Sources

← AI Security Directory →