Zenity AgentCorruption a révélé une voie de détournement à l’échelle d’un compte AWS AgentCore

Les chercheurs de Zenity AgentCorruption ont découvert qu’un seul prompt malveillant pouvait exposer des identifiants AWS temporaires depuis un agent Amazon Bedrock AgentCore accessible publiquement. Ces identifiants auraient ouvert des voies d’accès à chaque runtime AgentCore partageant le compte, la région et le rôle par défaut aux autorisations étendues concernés. Cette découverte a transformé un problème familier d’injection de prompt en une défaillance de sécurité cloud à l’échelle d’un compte.

L’attaque ne reposait ni sur la compromission d’un modèle fondamental, ni sur une intrusion chez un client AWS sans lien, ni sur le vol d’un mot de passe administrateur. Elle combinait la capacité d’un agent à effectuer des requêtes HTTP avec des identifiants de métadonnées et des autorisations Identity and Access Management excessives. Zenity affirme que la chaîne permettait d’atteindre des agents privés, du code source, des historiques de conversation, des secrets stockés et de la mémoire à long terme.

Cette combinaison importe davantage que le chiffre accrocheur d’un seul prompt. AWS présentait AgentCore comme une infrastructure gérée permettant d’exploiter en toute sécurité des agents en production, avec notamment l’identité, la mémoire, les outils, l’observabilité et des runtimes isolés. AgentCorruption a montré comment ces services connectés pouvaient amplifier la compromission d’un agent lorsque leurs frontières d’autorisation étaient trop larges.

Une précision importante s’impose également. Zenity a divulgué les problèmes plusieurs mois avant de publier ses recherches le 8 octobre 2026. Les chercheurs ont indiqué qu’AWS avait restreint le rôle d’exécution par défaut avant la publication, tandis que la documentation AWS impose désormais des contrôles de métadonnées plus stricts et déconseille l’utilisation en production de politiques étendues générées par CLI.

Le résultat ne prouve pas que chaque déploiement AgentCore actuel demeure vulnérable à l’intégralité de cette chaîne. Il montre que les équipes ne peuvent pas considérer une infrastructure d’agents gérée comme un substitut au principe du moindre privilège. La sécurité des agents doit désormais couvrir conjointement le comportement du modèle de langage, les identifiants d’exécution, les autorisations cloud, l’intégrité de la mémoire et les déplacements latéraux.

Comment Zenity AgentCorruption a transformé un prompt en identifiants AWS

La première défaillance a franchi la frontière entre une entrée linguistique non fiable et une identité cloud de confiance.

Selon les recherches AgentCorruption de Zenity, un agent AgentCore exposé a accepté un prompt lui demandant d’interroger un point de terminaison local de métadonnées. La requête ciblait 169.254.169.254, une adresse link-local utilisée par les environnements de calcul AWS pour fournir des métadonnées de charge de travail et des identifiants de rôle temporaires.

Le service concerné est l’Instance Metadata Service, souvent abrégé en IMDS. L’environnement Firecracker microVM d’AgentCore utilise un MicroVM Metadata Service apparenté, ou MMDS, afin de rendre les identifiants du rôle d’exécution disponibles au sein de la charge de travail.

Ce mécanisme de livraison d’identifiants a une finalité légitime. Un agent peut avoir besoin d’une autorisation temporaire pour lire un objet S3 approuvé, appeler un autre service AWS ou accomplir une tâche métier. Les identifiants temporaires évitent également d’intégrer des clés d’accès permanentes dans le code ou les images de conteneur.

Le problème survient lorsqu’un prompt non fiable peut amener un outil à contacter le point de terminaison de métadonnées. Zenity indique qu’un outil compatible HTTP a envoyé la requête depuis l’intérieur de la microVM, de sorte que le service de métadonnées l’a traitée comme une requête locale de charge de travail. La réponse a exposé la clé d’accès temporaire, la clé secrète et le jeton de session du runtime de l’agent.

Il s’agit d’un schéma de falsification de requête côté serveur, généralement appelé SSRF. Un attaquant incite un composant côté serveur à demander une destination qu’il ne peut pas atteindre directement. Ici, l’agent serait devenu le composant demandeur parce que ses outils pouvaient effectuer des appels HTTP sortants.

L’injection de prompt fournissait l’intention, tandis que l’outil HTTP fournissait la capacité. Le service de métadonnées fournissait ensuite une identité cloud. Aucun de ces éléments, pris isolément, n’aurait produit le rayon d’impact signalé.

Un modèle se contentant de générer du texte non sécurisé n’aurait pas volé d’identifiants. Un point de terminaison de métadonnées protégé contre les outils de l’agent aurait bloqué cette voie. Un rôle d’exécution aux autorisations strictement limitées aurait contenu les conséquences, même après le vol des identifiants.

AWS documente désormais explicitement cette propriété d’exposition des identifiants. Ses recommandations sur les identifiants indiquent que le code ou les acteurs présents dans une microVM peuvent appeler le point de terminaison de métadonnées et accéder aux identifiants disponibles. AWS recommande donc aux clients de limiter les rôles d’exécution aux seules autorisations requises par leurs charges de travail.

Zenity a initialement signalé le problème de métadonnées à AWS le 25 décembre 2025. Les chercheurs indiquent qu’AWS a clos ce signalement comme informatif le 12 avril 2026. AWS leur a précisé que les agents nouvellement déployés utilisaient IMDSv2 depuis le 14 février.

IMDSv2 exige un jeton de session avant qu’un client puisse récupérer des métadonnées. Cette conception bloque de nombreuses attaques SSRF conventionnelles, car l’attaquant ne peut pas toujours contrôler la requête préliminaire de jeton et ses en-têtes.

Un agent autonome modifie cette hypothèse. Si l’agent peut effectuer des requêtes suffisamment flexibles, il peut obtenir le jeton puis récupérer les identifiants. Zenity soutient que l’obligation d’utiliser IMDSv2 a accru les frictions sans éliminer le problème de confiance sous-jacent.

AWS est ensuite allé au-delà de l’adoption facultative. Les recommandations actuelles pour les runtimes indiquent que les runtimes AgentCore sans MMDSv2 activé sont refusés depuis le 30 juin 2026. Ce contrôle améliore le niveau de base, sans pour autant justifier les autorisations excessives associées à des identifiants auxquels le code d’exécution légitime peut toujours accéder.

La leçon essentielle est architecturale. L’injection de prompt devient une compromission cloud lorsqu’un agent peut traduire des instructions en langage naturel en opérations réseau et d’identité privilégiées. Filtrer la phrase malveillante ne traite qu’une seule couche de cette voie.

Le rôle par défaut a fait d’un agent le problème de tous

Les identifiants volés sont devenus un levier à l’échelle du compte parce que le rôle d’exécution testé confiait à un agent un accès régional à d’autres agents.

Zenity a soumis un deuxième rapport le 12 janvier 2026, portant sur les autorisations à l’origine de la compromission initiale. Les chercheurs ont indiqué que le rôle par défaut n’était pas limité au runtime qui l’assumait. Plusieurs autorisations s’appliquaient aux ressources AgentCore dans l’ensemble du même compte AWS et de la même région.

La première étape d’expansion a utilisé CloudWatch Logs. Zenity affirme que logs:DescribeLogGroups permettait à l’identité compromise de répertorier les noms de groupes de journaux régionaux. Les conventions de nommage d’AgentCore exposaient dans ces noms des identifiants de runtimes et de ressources de mémoire.

Les attaquants n’avaient pas besoin d’un inventaire préexistant d’agents privés. Ils pouvaient, selon les informations rapportées, déduire les identifiants de runtime à partir de métadonnées opérationnelles déjà visibles par le rôle. La découverte a transformé une identité volée, d’un simple point d’appui local, en carte des ressources voisines.

Le rôle contenait également des autorisations régionales pour Amazon Elastic Container Registry. Zenity affirme que des noms de référentiels prévisibles ont permis aux chercheurs d’associer des runtimes AgentCore à des images de conteneur. L’extraction de ces images exposait le code applicatif et potentiellement une configuration sensible intégrée aux artefacts déployés.

Cette découverte remet en cause une hypothèse courante sur les runtimes gérés. Une microVM peut isoler une session en cours d’une autre, tandis qu’IAM autorise toujours cette session à récupérer des ressources sans rapport. L’isolation du calcul et l’isolation des autorisations résolvent des problèmes différents.

Vint ensuite bedrock-agentcore:InvokeAgentRuntime. L’analyse du rôle de Zenity montre que la politique testée couvrait des ressources runtime génériques dans la région. Les identifiants volés pouvaient donc invoquer des agents privés auxquels un utilisateur externe n’était jamais censé accéder.

Un bot d’assistance public peut disposer d’outils limités et de données soigneusement filtrées. Un agent privé de facturation peut avoir accès à des fichiers financiers, des API internes ou des systèmes de transaction. L’invocation à l’échelle régionale reliait le point d’entrée exposé à l’agent plus sensible.

Zenity a démontré cette voie contre un agent de facturation de test. Les chercheurs ont énuméré ses outils, identifié un fichier nommé billing.json et demandé à l’agent d’en renvoyer le contenu. Ce scénario illustrait un déplacement latéral au moyen d’API AgentCore légitimes plutôt qu’une seconde exploitation logicielle.

La mémoire des conversations a encore élargi les dommages. AgentCore Memory stocke des événements à court terme par ressource mémoire, acteur et session. Les stratégies à long terme peuvent conserver des faits extraits, des préférences, des résumés et des leçons pour de futures interactions.

Zenity indique que le rôle compromis pouvait lister les acteurs et les sessions, puis appeler ListEvents afin de récupérer le contenu des conversations. Ces autorisations couvrant des ressources mémoire génériques, les chercheurs auraient ainsi accédé à des conversations appartenant à d’autres agents et utilisateurs.

Les données exposées pouvaient inclure des informations personnelles, du code source, des plans internes, des dossiers clients ou des identifiants collés lors d’un dépannage. La plateforme ne peut pas déterminer si un secret saisi dans une conversation aurait dû s’y trouver. L’autorisation doit empêcher dès le départ que des charges de travail sans lien lisent la session.

Les autorisations d’écriture ont créé une menace distincte pour l’intégrité. Zenity a constaté que le rôle pouvait créer et supprimer des événements de mémoire. Un attaquant pouvait injecter un faux contexte dans une session active, supprimer des résultats d’outils ou influencer ce que l’agent croyait s’être produit.

Ce risque diffère du vol de données ordinaire. Un agent manipulé peut continuer à se présenter comme un service d’entreprise fiable tout en agissant sur la base d’un contexte fourni par un attaquant. Les utilisateurs peuvent ne pas voir l’instruction hostile, car elle réside dans l’état de session stocké plutôt que dans leur prompt visible.

AWS a déclaré à Zenity le 25 février que son équipe traitait le problème sous-jacent. Les chercheurs ont vérifié à nouveau le 22 juin et signalé que le rôle par défaut restait inchangé. Cette chronologie a laissé le rôle étendu au cœur de la chaîne non résolue pendant plusieurs mois.

Lors d’un examen final le 29 septembre, Zenity a constaté d’importantes restrictions. Les chercheurs ont indiqué qu’AWS avait supprimé les autorisations permettant l’invocation entre runtimes, l’accès à des conversations privées et la récupération via Secrets Manager. D’autres autorisations avaient également été restreintes.

Cette correction modifie nettement l’évaluation actuelle des risques. La chaîne publiée documente ce que les chercheurs ont obtenu avec les paramètres par défaut antérieurs, et ne prouve pas que les mêmes autorisations sont encore associées aujourd’hui. Les rôles créés par les clients, les politiques copiées et les déploiements plus anciens méritent néanmoins un examen direct.

L’isolation gérée s’est heurtée à une réalité surautorisée

AgentCorruption a mis au jour un conflit entre la promesse d’isolation d’AgentCore et les voies d’autorisation partagées qui entourent chaque runtime isolé.

AWS a lancé AgentCore en disponibilité générale en octobre 2025, le présentant comme une infrastructure destinée à exécuter des agents de façon sécurisée à grande échelle. La plateforme associait l’isolation des runtimes à l’identité, la mémoire, les passerelles, l’automatisation de navigateur, l’exécution de code et l’observabilité.

Chaque capacité répond à un véritable problème de déploiement. Les agents ont besoin d’un état entre les conversations, d’identifiants pour les services connectés, d’un accès gouverné aux outils et d’une traçabilité pour les actions imprévisibles. Construire indépendamment tous ces composants augmente les coûts et la complexité.

Cependant, l’intégration crée aussi des dépendances de sécurité. Un runtime peut être isolé sur le plan informatique tout en disposant d’un rôle d’exécution capable d’invoquer un autre runtime. Un coffre de jetons peut maintenir les secrets hors du code applicatif, tandis qu’une identité trop largement autorisée peut demander ces secrets.

C’est le renversement central de Zenity AgentCorruption. Les contrôles connectés de la plateforme gérée étaient censés permettre une utilisation sécurisée en production. Avec les paramètres par défaut testés, ces mêmes connexions auraient, selon les chercheurs, propagé la compromission au-delà des frontières entre services.

Les pratiques de sécurité des runtimes actuelles d’AWS reconnaissent plus directement cette distinction. La documentation avertit les clients de ne pas utiliser en production les politiques de développement générées par la CLI. Elle recommande des ARN de runtime précis plutôt que des déclarations de ressources avec caractères génériques.

Les recommandations indiquent également qu’un rôle d’exécution doit disposer de privilèges égaux ou inférieurs à ceux des principaux autorisés à l’invoquer. Cette règle offre un moyen utile d’évaluer les agents publics. Si un utilisateur anonyme peut invoquer un runtime, celui-ci ne devrait pas hériter d’autorisations indisponibles aux utilisateurs anonymes.

L’accessibilité publique ne rend pas automatiquement un agent dangereux. Elle modifie le niveau de confiance accordé à chaque instruction qui atteint le modèle. Le rôle d’exécution doit supposer qu’une partie des entrées acceptées sera malveillante, trompeuse ou conçue pour manipuler des outils.

L’authentification aide à identifier les appelants, mais elle n’élimine pas l’injection de prompt. Un compte client légitime peut soumettre des instructions hostiles. Des documents et pages web compromis peuvent également transmettre une injection indirecte de prompt après qu’un utilisateur a demandé à un agent de les résumer.

Les contrôles de passerelle peuvent réduire l’exposition en validant les requêtes avant qu’elles n’atteignent un runtime. Les garde-fous peuvent détecter des schémas d’attaque connus, tandis que les intercepteurs peuvent restreindre les opérations selon l’identité et le contexte. Ces contrôles ne fonctionnent que si les appelants ne peuvent pas contourner la passerelle et invoquer directement le runtime.

Les recommandations de sécurité d’AgentCore préconisent désormais de restreindre l’invocation du runtime au rôle d’exécution de la passerelle lorsque celle-ci constitue le point d’entrée prévu. Cette approche déplace l’autorisation hors de la boucle de décision du modèle. L’agent ne peut pas contourner un refus IAM par la conversation.

Le périmètre des ressources IAM reste la limite de confinement la plus robuste. Un agent de support client ne devrait pas recevoir une autorisation générique lui permettant d’invoquer tous les runtimes. Une autorisation d’écriture en mémoire devrait désigner la ressource mémoire précise, le périmètre de l’acteur et le besoin métier, partout où le service permet cette granularité.

Le même raisonnement s’applique aux dépôts de conteneurs et aux journaux. Les métadonnées opérationnelles semblent souvent moins sensibles que les données applicatives. Pourtant, les noms, identifiants, points de terminaison et structures de dépôts peuvent devenir un système de découverte facilitant les déplacements latéraux.

Les organisations doivent aussi séparer les environnements selon leur niveau de confiance. Les agents publics et les agents internes ne devraient pas partager de rôles d’exécution uniquement parce qu’un outil de configuration rend ce choix pratique. Les fonctions sensibles peuvent être réparties entre plusieurs comptes AWS ou régions lorsque les contrôles au niveau du compte assurent une isolation plus claire.

Aucun filtre de prompt ne peut garantir qu’un modèle rejettera toutes les variantes malveillantes. Les modèles interprètent le sens plutôt que d’appliquer une grammaire de commandes finie. Les attaquants peuvent reformuler leurs requêtes, dissimuler des instructions dans des données récupérées ou exploiter des conflits entre le contexte système et le contexte utilisateur.

Cette limite ne rend pas le déploiement d’agents impraticable. Elle modifie l’endroit où les défenseurs doivent placer leur confiance. Les défenses au niveau du modèle peuvent réduire les manipulations réussies, tandis que les contrôles cloud déterministes limitent ce qu’un modèle manipulé peut faire.

Les équipes devraient traiter les prompts comme des entrées non fiables et les outils comme des interfaces privilégiées. Chaque appel d’outil nécessite une décision d’autorisation fondée sur l’utilisateur authentifié, la ressource demandée et l’opération permise. Le choix du modèle d’appeler un outil ne devrait jamais constituer à lui seul une autorisation.

Pour les organisations qui documentent ces décisions, un ensemble consultable de bases de connaissances d’ingénierie peut aider à relier la responsabilité des runtimes, les politiques IAM, les modèles de menace et les procédures d’incident. Cet historique devient important lorsque plusieurs équipes déploient des agents via des comptes cloud partagés.

L’empoisonnement de la mémoire a transformé une intrusion en contrôle persistant

L’élément le plus déterminant de la chaîne n’était pas le vol d’identifiants, mais la capacité de corrompre ce dont les agents de confiance se souviendraient par la suite.

AgentCore Memory prend en charge les états à court et à long terme. La mémoire à court terme enregistre les événements tour par tour d’une session. La mémoire à long terme extrait des informations réutilisables afin qu’un agent puisse rappeler des préférences, des faits, des résumés ou des enseignements antérieurs.

Cette persistance améliore l’utilisabilité. Un agent de support peut se souvenir d’un dossier non résolu, tandis qu’un assistant professionnel peut conserver des préférences de mise en forme. Elle crée également un canal d’entrée durable susceptible d’influencer les décisions futures.

L’étude de Zenity sur l’empoisonnement de la mémoire indique que le rôle dérobé pouvait découvrir des identifiants de mémoire via les journaux CloudWatch. Il pouvait ensuite lister les acteurs, les sessions et les stratégies de mémoire configurées.

Les chercheurs ont utilisé CreateEvent pour ajouter du contenu hostile aux conversations d’autres agents. L’extraction de mémoire a traité ces événements et converti leur contenu en enregistrements à long terme. Les sessions ultérieures pouvaient récupérer ces enregistrements comme contexte de confiance.

Un attaquant n’avait donc pas besoin de répéter l’injection de prompt initiale à chaque interaction. Une instruction implantée pouvait survivre au-delà de la session compromise et affecter des conversations ultérieures. L’interface visible continuerait pourtant d’apparaître comme l’agent officiel de l’organisation.

Zenity décrit cela comme un contrôle persistant de commande et de contrôle. Cette expression doit être comprise comme la caractérisation par les chercheurs de leur environnement de test. Le résultat comportemental exact dépend de la configuration de la mémoire, de la logique de récupération, du comportement du modèle, des outils et des contrôles d’autorisation.

Le mécanisme démontré demeure néanmoins sérieux. Une fausse préférence pourrait indiquer à un agent d’envoyer des données vers une adresse contrôlée par l’attaquant. Un fait fabriqué pourrait rediriger un flux de travail, tandis qu’un résumé empoisonné pourrait présenter de manière erronée l’approbation antérieure d’un client.

La manipulation de l’historique à court terme ajoute des risques immédiats. Un événement assistant inséré peut apparaître au modèle comme une décision qu’il a déjà prise. Un résultat d’outil supprimé peut retirer des éléments qui auraient autrement empêché une action dangereuse.

La sécurité applicative traditionnelle considère souvent les journaux et l’historique comme des preuves après un incident. Les systèmes d’agents peuvent réinjecter activement l’historique stocké dans les décisions futures. Les atteintes à l’intégrité de ces données peuvent donc modifier l’exécution, et pas seulement entraver l’enquête.

La mémoire complique également la remédiation. La rotation des identifiants volés met fin à l’accès continu aux API, mais elle ne supprime pas automatiquement chaque enregistrement empoisonné. Les intervenants doivent identifier les sessions, événements, résumés et mémoires extraites que l’identité compromise a touchés.

Les recommandations actuelles d’AWS sur la mémoire préconisent la validation des entrées, des garde-fous avant la persistance et des tests réguliers d’injection de prompt. Elles insistent également sur des politiques de moindre privilège pour les ressources mémoire.

Ces contrôles devraient être associés à la provenance. Un enregistrement à long terme devrait conserver suffisamment de métadonnées pour indiquer quel utilisateur, agent, session et processus d’extraction l’a créé. Les équipes de sécurité ont besoin d’un moyen efficace de mettre en quarantaine les mémoires associées à une identité compromise.

Les actions à haut risque ne devraient pas s’appuyer sur le contexte rappelé comme preuve d’autorisation. Un agent peut se souvenir qu’un utilisateur préfère un compte bancaire donné, mais un transfert exige toujours une approbation actuelle, vérifiée indépendamment. La mémoire peut orienter un flux de travail sans l’autoriser.

Les organisations devraient également séparer les types de données selon leurs conséquences. Les préférences de style rédactionnel présentent moins de risques que les instructions de paiement, les attributions d’accès ou les adresses de destination. Les mémoires sensibles nécessitent des règles de création plus strictes, une rétention plus courte et un contrôle renforcé.

La surveillance doit couvrir les écritures autant que les lectures. Des rafales inhabituelles de CreateEvent, des accès mémoire inter-agents ou des modifications affectant de nombreux acteurs peuvent signaler un abus. CloudTrail, les journaux applicatifs et les données d’observabilité AgentCore devraient alimenter des alertes liées au comportement attendu de la charge de travail.

C’est ici que l’incident dépasse AWS. Toute plateforme d’agents combinant mémoire persistante et outils est confrontée à un problème d’intégrité similaire. Les détails de mise en œuvre diffèrent, mais la question de confiance reste constante.

Quelles informations l’agent est-il autorisé à mémoriser, qui peut les écrire, et quelles décisions pourront ensuite en dépendre ? AgentCorruption montre que des réponses incomplètes peuvent transformer un accès initial temporaire en influence durable.

Ce que les clients AgentCore devraient vérifier dès maintenant

La chaîne historique complète a été resserrée avant publication, mais les autorisations définies par les clients et les anciennes configurations déterminent l’exposition restante de chaque déploiement.

La première vérification concerne le rôle d’exécution associé à chaque runtime AgentCore. Les équipes devraient lister les actions et ressources autorisées, puis supprimer les autorisations sans rapport avec la fonction documentée du runtime. Les caractères génériques méritent une justification précise plutôt qu’une acceptation systématique.

Les rôles de production ne devraient pas hériter de politiques générées pour des prototypes. AWS présente désormais les autorisations générées par la CLI comme des commodités de développement et conseille aux clients de créer des alternatives à périmètre restreint. Un déploiement de test réussi ne prouve pas que son rôle est adapté à la production.

La deuxième vérification porte sur l’application de MMDSv2. Les runtimes actuels devraient définir requireMMDSV2 sur true dans leur configuration de métadonnées. Les équipes devraient vérifier la configuration déployée plutôt que de supposer qu’une mise à jour de la plateforme a correctement modifié chaque runtime historique.

MMDSv2 doit néanmoins être considéré comme une couche parmi d’autres. Si un agent contrôle légitimement un client HTTP flexible, un shell ou un interpréteur de code, il peut effectuer des requêtes que des protections SSRF simplistes supposaient impossibles à construire pour des attaquants. La politique réseau devrait bloquer tout accès inutile aux points de terminaison de métadonnées.

La troisième vérification concerne l’accessibilité entrante. Les équipes devraient identifier les runtimes qui acceptent une invocation directe publique, IAM ou fondée sur JWT. Les agents publics nécessitent les rôles les plus restreints, car leurs entrées proviennent du public le moins fiable.

Lorsqu’AgentCore Gateway assure l’application des politiques, l’invocation directe des runtimes devrait être restreinte. Sinon, un attaquant pourrait contourner les garde-fous de la passerelle et appeler le point de terminaison du runtime via un autre chemin autorisé. L’authentification et les identifiants utilisateur doivent provenir de principaux vérifiés.

La quatrième vérification couvre les déplacements latéraux. Un runtime ne devrait pas invoquer des agents sans rapport, lister des groupes de journaux régionaux, extraire des images ECR sans rapport ou énumérer des ressources mémoire. Ces autorisations devraient être isolées par ARN de runtime et par fonction métier.

La cinquième vérification concerne la confidentialité des conversations. Les équipes de sécurité devraient tester si une identité de runtime peut lister les acteurs, sessions ou événements appartenant à une autre charge de travail. Elles devraient également vérifier que les politiques de ressources et les politiques d’identité produisent conjointement le refus attendu.

La sixième vérification porte sur l’intégrité de la mémoire. Les équipes devraient recenser les principaux disposant de CreateEvent, DeleteEvent et d’un accès à la mémoire à long terme. Les alertes devraient distinguer les écritures normales de sessions utilisateur des modifications inter-agents ou à volume élevé.

La septième vérification concerne les identifiants stockés. AgentCore Identity peut conserver des jetons tiers hors du code applicatif, mais IAM contrôle toujours qui peut les récupérer. Les rôles de runtime ne devraient pas avoir un accès étendu aux clés API ni aux valeurs Secrets Manager.

Les enquêteurs examinant une éventuelle exposition historique ont besoin de davantage que des instantanés des politiques actuelles. Ils doivent analyser les événements CloudTrail, les journaux d’invocation d’exécution, l’activité liée aux métadonnées, les extractions d’images ECR, les appels d’API de mémoire et les accès à Secrets Manager durant la période concernée.

Les identifiants temporaires expirent, mais leurs effets peuvent perdurer. Un attaquant pourrait copier du code source, conserver un secret récupéré, modifier l’historique des sessions ou implanter une mémoire à long terme avant l’expiration. Les plans de réponse doivent prévoir la rotation des identifiants et la validation de l’état.

Deux incertitudes restent centrales. Les conclusions de Zenity proviennent de déploiements contrôlés par les chercheurs, et aucune preuve publique citée ici n’établit une exploitation généralisée dans des environnements clients. AWS n’a pas publié de bulletin de sécurité dédié décrivant la chaîne AgentCorruption complète.

Cette absence doit empêcher les affirmations excessives, sans pour autant écarter la recherche. Zenity a publié des exemples détaillés d’autorisations, des chemins d’exploitation et des dates de divulgation. La documentation mise à jour d’AWS confirme indépendamment que le code exécuté au runtime peut accéder aux identifiants de métadonnées et que les politiques de développement étendues ne conviennent pas à la production.

Le premier signal à surveiller est la publication par AWS d’un avis formel, d’une analyse rétrospective ou de recommandations supplémentaires pour migrer les politiques. Une telle documentation préciserait les configurations concernées et indiquerait si les clients doivent corriger manuellement d’anciens rôles.

Le deuxième signal est un durcissement supplémentaire de l’accès aux métadonnées depuis les outils contrôlés par l’agent. Un contrôle empêchant les charges de travail d’exécution d’atteindre les points de terminaison d’identifiants réduirait la dépendance au comportement du modèle. Une politique de sortie granulaire pourrait également contenir d’autres chemins SSRF.

Le troisième signal est une protection de la mémoire visible par les clients. Une meilleure provenance, des autorisations d’écriture limitées, des alertes d’intégrité et des outils de quarantaine en masse faciliteraient la détection et l’inversion de l’empoisonnement de mémoire. Ces capacités deviennent importantes à mesure que la mémoire à long terme s’intègre aux flux de travail critiques de l’entreprise.

Zenity AgentCorruption met finalement à l’épreuve une affirmation plus large concernant les agents d’entreprise. Une infrastructure gérée peut réduire la complexité opérationnelle, mais elle ne peut pas fusionner en toute sécurité l’identité, la mémoire et l’accès aux outils dans un seul rôle bénéficiant d’une confiance étendue.

Les développeurs doivent désormais poser une question concrète pour chaque agent déployé : que se passe-t-il après que le modèle suit la pire instruction qu’il puisse recevoir ? Tracez les appels d’outils qui en résultent, les identifiants, les autorisations, les agents accessibles et les mémoires modifiables.

Si la réponse dépasse la tâche étroite de cet agent, considérez cette portée comme un défaut de sécurité actif. Examinez le rôle, isolez les runtimes publics, testez les limites de mémoire et confirmez directement les paramètres AWS actuels. L’agent le plus sûr n’est pas celui qui rejette toujours la manipulation. C’est celui dont les autorisations cloud empêchent qu’une réponse manipulée ne se transforme en incident à l’échelle du compte.