Zenity Labs: one prompt to a public AgentCore agent could return temporary credentials tied to a default role not scoped to that agent

An agent's execution role decides what it can reach. The agent presents signed credentials, and the cloud checks the signature and the policy ^[5]. It does not check intent, and it does not check whether a human or a model typed the prompt ^[5]. After the metadata request, nothing in that path concerns the model.

The DEV Community write-up of the Zenity disclosure frames the chain as three links. Content has to reach a tool, the tool has to reach credentials, and the credentials have to reach resources the agent has no business touching ^[6]. Break any one and the chain ends as a chat transcript ^[6]. In the reported case the first link was one HTTP request from the model ^[3]. The third was a default execution role whose permissions were not scoped to that one agent ^[2].

The write-up turns this into a review of five permission patterns in your own role ^[12]. They are an invoke permission scoped to all agent runtimes in a region instead of a named list; list or describe access wide enough to catalogue the account's agents, log groups and other resources, all of them; a read permission on conversations or events across agents and users; a secrets read broad enough to reach credentials the platform was meant to keep from the agent; and a memory write that crosses agents or users ^[11]. The write-up puts the review at about an hour ^[15]. That review covers roles a team widened until a demo stopped failing ^[14].

AWS moved newly deployed agents to IMDSv2 by February 14, 2026, within 51 days of the first report ^[9][16]. The wider default-role permissions took until September 29, which the summary counts as 278 days after the report ^[10]. That was at least nine days before the SecTor talk ^[17].

The write-up says IMDSv2 applies to newly deployed agents. It does not say what happened to agents already running, so an older deployment needs a direct check.

AWS described the original behavior as documented and expected, according to the disclosure summary, and pointed customers to granting a role only the permissions its workload needs ^[13]. That is the position as the write-up reports it. The material does not include an AWS statement.

We think the audit claim holds on the mechanics alone. Because the cloud checks the role's policy, the policy is the document that sets the damage, and it is in the customer's account ^[5][14]. The write-up's own summary is that the blast radius was a role property, not a model property ^[8].