The agent handed over its own identity

On 8 October 2026 the security firm Zenity published a write-up it calls AgentCorruption: a chain that starts with an agent running inside AWS's Bedrock AgentCore and ends with an attacker holding temporary cloud credentials. The first step is ordinary server-side request forgery. The agent is induced to fetch a URL, and that URL resolves to the instance metadata service at 169.254.169.254 — the address every cloud virtual machine can reach to ask about itself. What the agent finds there is a set of temporary AWS Security Token Service credentials, the short-lived keys a workload uses to prove who it is. Zenity's researchers describe the initial reach as coming out of the agent's own Firecracker microVM, the lightweight virtual machine AWS uses to isolate one agent from the next.

The published account says no exotic bug was required for this first hop. The metadata endpoint is meant to be reachable by the workload it belongs to; the question is whether the workload should be able to be talked into reaching it by something it fetched. The finding reads less as a broken lock than as a door left unlocked by default, and the rest of the chain is what a door left unlocked buys.

The credentials the agent picks up are those of the role AWS assigns when a developer has not set one of their own. According to the write-up, that default role was scoped far wider than a single agent needs — wide enough, in Zenity's telling, to reach every other AgentCore agent in the same AWS account and the same region, not merely the one that fetched the metadata. From there the researchers list what the identity could do: read the private conversations other agents were holding, pull the container images and source code behind them, harvest credentials out of AWS Secrets Manager, and write new entries into an agent's memory store. That last one matters because it persists. An attacker who plants a malicious memory can leave instructions for the agent to find on a later run, after the temporary credentials have long since expired.

The claim is not that any of this was observed in the wild. It is a reproduction against the platform as configured by default, and its weight rests on how ordinary the starting point is. The chain does not require the victim to have made a mistake so much as to have accepted the defaults.

Zenity says it reported the IMDS access to AWS on 25 December 2025 and the overprivileged default role on 12 January 2026. AWS, it says, made newly deployed agents require IMDSv2 by default on 14 February 2026, which hardens the endpoint against exactly this kind of request, and narrowed the default execution role on 29 September 2026. No CVE was assigned. AWS disputes the framing. In statements carried by Dark Reading, The Next Web and The Decoder, the company said the research "inaccurately paints expected and documented behavior as a vulnerability" — that the behavior the research describes is expected and documented.

The dispute is not only about the code. Zenity sells AI-agent security products, which is a reason to read its threat framing with the usual discount applied to any vendor describing the problem it also sells a fix for; AWS, for its part, is the party whose defaults are on trial. The Next Web's headline was corrected after publication to say the affected scope was agents in the same account and region, rather than a broader claim. What is not in dispute is the shape: an agent that can be prompted into an outbound request, a metadata service that answers it, and a default identity broader than the task at hand. Which of those three a given deployment treats as a bug is, for now, a matter of position rather than fact.