AgentCore and the Metadata Problem

A single prompt to a public-facing Bedrock AgentCore chatbot was enough for Zenity Labs researchers to retrieve temporary AWS credentials from the environment’s Instance Metadata Service.

That is the useful fact in the AgentCorruption research. The rest is blast radius.

Tamir Ishay Sharbat, director of security research at Zenity Labs, described the issue at SecTor 2026 in Toronto. Bedrock AgentCore is AWS’s managed platform for deploying and operating agents. Zenity tested agents deployed through the platform and found they could reach IMDS, the metadata service that exposes information such as temporary credentials, instance IDs, and configuration data.

According to Zenity, an AgentCore agent ran inside a Firecracker MicroVM without the network isolation needed to prevent access to the metadata endpoint. Any agent that could make HTTP requests could be induced to send a request to IMDS. In the demonstrated case, the researchers used a support agent. The agent complied and returned temporary credentials.

This is an old cloud failure mode in a new wrapper. IMDS exposure has been a known problem for years because metadata services sit close to workloads and hand out credentials meant for those workloads. If an attacker can trick the workload into querying metadata, the workload becomes the credential fetcher. In classic cloud incidents, server-side request forgery often played that role. In this case, the public agent did.

The agentic part matters because the interface is intentionally natural-language driven. A public-facing agent exists to accept instructions and perform work. If that agent also has network reachability to sensitive infrastructure services, prompt handling becomes part of the cloud control plane, whether the architecture admits it or not.

Zenity said the initial credential access was only the first step. After retrieving temporary credentials, the researchers examined the permissions attached to the default AgentCore role. They found broad permissions across AgentCore resources in the same AWS account and region, rather than permissions limited to the specific agent.

With those permissions, the researchers said they could invoke other agents, read sessions, and access secrets from AWS Secrets Manager. Sharbat also said the access enabled lateral movement across the AWS environment, privileged-account access, and memory poisoning attacks against agents. In Zenity’s framing, one prompt to an overprivileged public agent could compromise an entire AgentCore region.

AWS disputes the way the research characterizes the issue. In a statement to Dark Reading, AWS said the research “inaccurately paints expected and documented behavior as a vulnerability.” AWS said an agent can access resources in another AWS account only when the developer explicitly grants permissions on both the agent execution role and the target resource. AWS also recommended granting execution roles only the permissions agents need.

The two accounts still point at the same operational concern: agent execution roles are now high-value infrastructure. If an agent can be prompted by an external user, can make HTTP requests, and can obtain credentials with broad permissions, the security boundary is weaker than many teams will assume from the phrase “managed platform.”

AWS updated AgentCore in February so that all new agents deployed on the platform use IMDSv2, which requires authentication. Zenity also said AWS changed AgentCore’s default role, removing permissions that allowed agents to invoke other agents, read private conversations, and access secrets stored in Secrets Manager, along with other restrictions.

For teams running agents in cloud environments, the practical work is familiar but less optional. Treat public-facing agents as untrusted input processors with execution privileges. Their roles should be scoped to the specific work the agent performs, not to broad platform-level actions. Agent credentials should have narrow resource access, narrow regional assumptions, and no ambient permission to read unrelated sessions or secrets.

Network reachability deserves the same treatment. If an agent does not need metadata access, block it. If it needs cloud credentials, prefer mechanisms that avoid exposing a general metadata endpoint to prompt-controlled behavior. Where IMDS is present, require IMDSv2 and verify that deployed agents actually use the updated behavior rather than assuming new platform defaults apply retroactively.

Secrets are another pressure point. An agent that can read from Secrets Manager is effectively a programmable secret retrieval interface. That may be intended for some workloads, but it should be rare, explicit, and tied to specific secret ARNs. Broad secret access turns prompt injection from an application-layer nuisance into credential exposure.

The same applies to agent-to-agent invocation. Giving one agent the ability to invoke others can be useful for orchestration, but it also creates lateral movement inside the agent platform. If that permission is present by default, every public agent becomes a potential starting point for reaching private workflows.

Zenity said it has not seen evidence that the flaw was exploited in the wild before AWS’s fix. Sharbat attributed part of that to the difficulty of identifying which agents are deployed through AgentCore. He also said Zenity is looking at other cloud platforms and believes the IMDS weakness is not specific to AWS.

The important design lesson is narrower than “AI and cloud do not mix well.” Cloud platforms already have a model for this class of failure: isolate workloads, constrain credentials, and assume exposed interfaces will eventually be made to send requests they should not send. Agent platforms need to inherit that model directly. A prompt is input. An execution role is authority. Putting them together without tight boundaries gives attackers a short path from language to infrastructure.

See also: NordVPN for tunneled traffic when operating outside controlled networks.

---

#ad Contains an affiliate link.