Zenity 'AgentCorruption': one prompt to an exposed Bedrock AgentCore agent stole its role credentials, which then reached every AgentCore agent in the account and region
Zenity Labs (Oct 8) shows that agents on AWS Bedrock AgentCore run in Firecracker microVMs that could reach the metadata service at 169.254.169.254. Any agent tool that could make HTTP requests was therefore an SSRF primitive. A single chat prompt to a public-facing agent made it fetch its execution role's temporary STS credentials and post them to Zenity's listener, and those credentials worked from outside AWS. At the time, the default execution role carried wide AgentCore permissions across the region. That let Zenity invoke other agents, read their private conversations, pull secrets from Secrets Manager, and write memory events that persistently rewired other agents' behaviour. Timeline: Zenity reported the IMDS access on Dec 25, 2025 and the blast radius on Jan 12, 2026. AWS moved new agents to session-token-only metadata (IMDSv2/MMDSv2) on Feb 14, 2026. Zenity found the default role unchanged on June 22 and substantially narrowed on Sep 29. AWS's statement in the post says the behaviour is 'documented and expected': agents can read their own role credentials, and customers should grant least privilege. Palo Alto Unit 42 separately reported the token-less metadata service and a DNS-tunnelling escape from AgentCore's sandbox mode, which led to the Feb 14 change. What to do: check that runtimes enforce MMDSv2, and replace any old default execution roles with least-privilege ones. Also treat any agent tool that fetches URLs as a path to your cloud credentials.
Sources: Zenity Labs: AgentCorruption · Zenity Labs: Initial IMDS access · Unit 42: Cracks in the Bedrock