AgentCore's region-wide default role let one public agent's stolen credentials reach every agent in the account

The first link in the chain is old cloud plumbing. AWS runs an Instance Metadata Service at 169.254.169.254 that hands temporary credentials to the workload calling it, and whoever captures them can impersonate that workload ^[4]. An agent should not be able to reach it. According to Zenity's technical write-up, AgentCore lacked the isolation to stop it ^[19]. The researchers built a test agent on Strands, an open-source AWS framework that ships with a web tool ^[5]. They asked it in plain language to query the service and send the output to an external server ^[5]. It complied ^[5]. "The sandbox boundary we were supposed to be fighting simply wasn't there," the researchers wrote ^[6].

After that the agent was optional. The credentials worked from the researchers' own machine, outside the platform ^[7]. The same endpoint also returned certificate and key material for an internal AWS service, plus a presigned URL to an internal S3 bucket that belonged to some other account ^[8]. Removing the web tool would not have closed the hole. Zenity says a command-line tool got the same result, since the weakness is in the platform itself ^[9]. It describes the problem as systemic, affecting agents with built-in tools across AWS accounts ^[21].

What stolen credentials can do depends on the role attached to them. According to Zenity, the role AgentCore assigned by default was scoped to all agents in the region instead of the one agent holding it, with read, write and delete rights that extended to destructive actions ^[10]. With it, the researchers listed every agent, downloaded code packages in seconds and invoked each agent individually ^[11]. Those packages often hold forgotten passwords or API keys next to the source ^[11]. Zenity's example is a pivot from a public customer service agent to an internal finance agent and its data ^[18]. Every private conversation between users and agents was readable ^[12].

Two safeguards AWS itself recommends did not hold under that role. AWS tells builders to keep credentials in a separate secured vault, but the default permissions reached the vault directly, including keys for services outside AWS ^[14]. Long-term memory was writable too. Zenity planted instructions that made agents forward future conversations to an outside destination, while users kept talking to what looked like a trusted agent ^[13].

AWS has made it harder for new agents to retrieve internal metadata and has tightened the default execution role, according to the-decoder ^[16]. The report does not say whether agents and roles created before the change were updated. Zenity's position is that companies should still assign each agent a stricter role with minimal access by hand ^[17].

I think that advice is right, and the structure of the chain shows why. It needed two separate failures: an agent that could reach the metadata service ^[19], and a default role that covered every agent in the region ^[10]. The metadata change targets the first, and as reported it applies to new agents ^[16]. The role decided how far the leak travelled, and Zenity says the most damage came from those default permissions ^[20]. If the tightened default applies only to roles created after the change, accounts built before it keep the region-wide policy until someone rewrites it ^[16].