One prompt pulled AWS AgentCore role credentials from IMDS, and the default role reached every agent in the region

Zenity Labs published research on October 8 showing that agents deployed on Amazon Bedrock AgentCore could reach the instance metadata service at 169.254.169.254 from inside their Firecracker microVMs. Any agent tool able to make HTTP requests became a server-side request forgery primitive, so a single prompt from a user chatting with a public agent could return the temporary credentials of its execution role. Zenity says the default role was granted region-wide rights including bedrock-agentcore:InvokeAgentRuntime, ListEvents to read conversations, CreateEvent on agent memory, and secretsmanager:GetSecretValue, all within the same account and region. Zenity reported IMDS access on December 25, 2025 and the role scope on January 12, 2026. AWS moved AgentCore to IMDSv2-only on February 14, and Zenity found the role hardened by September 29. AWS calls the behavior documented and expected.

Why it matters

The prompt injection is the trigger, but the identity failure is the role. An agent's execution role is a non-human identity whose credentials any of its tools can reach, so its permissions are effectively granted to everyone who can talk to the agent. A default scoped to the whole region turned one public chatbot into access to every agent's conversations, memory and secrets.

If you created AgentCore agents with the default execution role, replace it with a per-agent role scoped to that agent's own resources and only the specific AWS Secrets Manager secrets it needs, and confirm IMDSv2 is enforced. Review CloudTrail for GetSecretValue and InvokeAgentRuntime calls from agent roles that do not match their purpose. Do not assume customer-facing and internal agents in one account are isolated from each other. Compare the MLflow SSRF to cloud metadata case and least privilege. Zenity's write-up is here.

Source: The Register