The researchers' proof-of-concept involved an agent with a web-request tool that was prompted to call the local metadata endpoint at 169.254.169.254, which is where AWS workloads get temporary AWS credentials. Since the request came from inside the agent's Firecracker microVM, it returned credentials for the agent's execution role.
This created a server-side request forgery (SSRF) vulnerability that was triggered by a prompt injection. "Exploitation didn't require a vulnerability in the chat interface; it required only that the agent have a tool to make the request and that the tool be permitted to call the metadata service," the researchers said.
Zenity discovered that the broad permissions typically given to the default execution role allowed them to find agents, obtain container images, invoke other agents and access session events.
They also discovered permissions that could be used to access conversations and implant false memories that would affect the agent's future responses. The researchers added that the latter capability could be used to implant "instructions" that would cause the agent to take specific actions.
In addition, they found that these same permissions could be used to access API keys and secrets stored in AWS Secrets Manager, which could lead to lateral movement to other services and data.
According to Zenity, metadata access was reported to AWS on Dec. 25, 2025, and excessive permissions in the execution role were reported on Jan. 12, 2026. AWS started the migration to Instance Metadata Service Version 2 in February 2026, and then made it mandatory. On Sept. 29, 2026, Zenity confirmed that AWS had removed the permissions that could be used to invoke other agents, chat with them or access the Secrets Manager. The researchers stated that the problems they reported had been addressed.
AWS pushed back against the suggestion that this was a vulnerability, noting that it is normal for an agent to have access to its own execution role credentials via the metadata service. In addition, the company stated that cross-account access to agents is not possible without the appropriate permissions on the execution role and resources.
Security teams should create their own IAM roles with limited permissions, block all outbound network connectivity except what is necessary, isolate agents that are accessible over the public internet and monitor logs in CloudTrail and CloudWatch for anything unusual, the researchers recommended. They also suggested that organizations ensure that the AgentCore Gateway cannot be bypassed to access agents directly.
An AI agent's access to tools and permissions in the cloud can create security issues if not properly restricted, and this discovery shows why companies need to carefully control and monitor such access before actually launching an agent into production.
