What is IMDS, and why is obtaining its credentials so serious?
IMDS (Instance Metadata Service) is the internal address cloud compute instances use to query information about themselves, including the temporary credentials of the execution role attached to the instance. If you can make the instance request 169.254.169.254 and carry the result out, you effectively hold that role's permissions — and those credentials can be used from outside the instance.
IMDSv2 requires a session Token on every request, blocking the simplest SSRF path, but it doesn't change how powerful the credentials are. What ultimately determines the damage is what the role was granted.
Why does AWS call this 'expected behavior' while Zenity insists it's a vulnerability?
AWS's position is that the permission model is controlled by developers by design: for an agent to reach other resources, permissions must be explicitly granted on both the execution role and the target resource. Zenity's position is that the default attached role already spans the region's AgentCore resources, most developers never change defaults, and so the default is effectively the real security level.
Both have a point; the disagreement is over who owns the default. For developers there's one practical conclusion: don't assume the default role is least-privilege.
Why is the memory-injection backdoor more dangerous than a one-off Prompt Injection?
A one-off prompt injection only affects the current conversation. In this case the researchers got the system to store a forged event as a persistent user instruction: before every answer, visit a page and follow its content. Because the instruction points to an external page, the attacker can change the agent's behavior later just by editing the page, without touching the agent's memory again.
The defensive focus is controlling long-term memory writes: which sources, and after what checks, may be stored as instructions that shape every future answer.
I don't use AgentCore — should I care?
Yes. The core of this chain isn't an AgentCore-only feature but three generic conditions holding at once: the agent has a tool that can make network requests, the runtime doesn't Block the metadata address, and the execution role is overly broad. Any cloud or self-built environment where all three hold carries similar risk. Zenity says it is evaluating other cloud platforms too.
The cheapest self-check is to list each agent's tools and role permissions and look for the combination of "can send outbound requests" plus "role can read a lot."
On October 8, 2026, Zenity Labs disclosed at SecTor 2026 a vulnerability chain in AWS Bedrock AgentCore, dubbed "AgentCorruption." Zenity's claim: an attacker who sends a single prompt to a public-facing AgentCore agent can work their way to other agents in the same AWS account and region. AWS's response is that this paints "expected and documented behavior" as a vulnerability. Both accounts are worth reading, because every link in this chain is something developers may be repeating in their own agent deployments.
Step one: the entry point is an ordinary public agent. The researchers used an agent built with the Strands SDK with the built-in http_request or shell tool enabled. The attacker simply asks it, in natural language, to make a request to a given address. Zenity characterizes this as SSRF and stresses that "the isolation failure is at the platform level, not the tool level," so any tool capable of producing outbound traffic yields the same result.
Step two: reaching IMDS. Each agent run starts a Firecracker microVM, but the microVM doesn't Block traffic to the metadata service (169.254.169.254). The agent returns the execution role's temporary STS credentials (access key, secret key, session Token), which the researchers could use outside AgentCore and verified with sts get-caller-identity.
Step three: an overly broad default execution role. Zenity says the role AgentCore attaches by default is "badly overprivileged": logs:DescribeLogGroups lists every agent's ID and name in the region, and ECR image access is scoped to repository/*, meaning any image in the account and region can be pulled — potentially exposing source code, dependencies, and leftover hard-coded keys.
Step four: reading and calling other agents. Per The Next Web's summary, the same role let the researchers list all agents, download each agent's container image and source, invoke internal agents they shouldn't reach, read private conversations of users and agents, and obtain API keys from Secrets Manager, including credentials the agents use for services outside AWS.
Step five: a backdoor through memory injection. The researchers wrote into an agent's long-term memory so the system stored a forged conversation event as a persistent user instruction: before every answer, visit an attacker-controlled web page and follow its content. From then on, editing that page changes the agent's behavior at will with no new memory needed. In Zenity's demo, the user chats normally while the conversation is sent to the researcher's server. Note that public material doesn't confirm this memory injection spreads on its own to other agents, and Zenity says it found no evidence of exploitation in the wild before the fix.
AWS's statement says this "inaccurately paints expected and documented behavior as a vulnerability": agents can access other resources only if the developer explicitly grants permissions on both the execution role and the target resource, and it recommends customers grant execution roles only the permissions their agents need. Zenity maintains the default role's scope is itself the problem. On the timeline: Zenity reported the IMDS issue in late December 2025 and the overbroad default role in January 2026; AWS says that since February 14, 2026 newly deployed AgentCore agents start with IMDSv2 only; in April 2026 AWS closed the first report as "informative"; Zenity says the default role was unchanged in June, and in its final pre-publication check on September 29 found permissions reduced, with cross-agent invocation, reading private conversations, and Secrets Manager access removed. Public reporting doesn't say whether existing agents have been migrated to IMDSv2.
Zenity researcher Tamir Ishay Sharbat drew an analogy to the 2019 Capital One breach, which was also SSRF against an EC2 IMDS to obtain credentials, rooted in a lack of least privilege. In his words, even if someone reaches IMDS, the blast radius will be a lot smaller. That's why this chain is instructive for anyone running agents in the cloud: agent tooling makes "send an outbound request" something natural language can drive, handing the SSRF entry point to anyone who can talk to the agent.
If you run public-facing agents on AgentCore or any managed cloud platform, these steps are more practical than waiting for the vendor's next patch: audit each agent's execution role, replace wildcard resources like repository/* with explicit ones, and confirm that logs, ECR, and Secrets Manager permissions are actually needed; confirm existing agents (not just new deployments) enforce IMDSv2 and restrict egress to 169.254.169.254; avoid enabling shell and arbitrary HTTP request tools on public-facing agents; move keys and .env files out of container images; and review long-term memory write paths so a single conversation event can't become a permanent instruction. Assume an attacker will eventually reach IMDS, and aim to make what they can do with the credentials very small.