One Prompt, Every Agent in the Region: Zenity's AgentCorruption Turns IMDS Access Into Full AgentCore Takeover
On 8 October 2026, Zenity Labs disclosed AgentCorruption at SecTor 2026 in Toronto: a chain of flaws in Amazon Bedrock AgentCore that let researchers take over every AgentCore agent in an AWS account and region starting from a single prompt to one public-facing agent. The entry was almost embarrassingly direct — ask the agent, in plain language, to fetch the Instance Metadata Service — and the blast radius was everything: private conversations, long-term memories, agent source code, Secrets Manager credentials, and persistent behavioural hijack via poisoned memory. Zenity describes the flaws as systemic to AgentCore, affecting any agent equipped with built-in tooling.
The ask that worked
The attack began with a prompt to a public-facing agent carrying a commonly used tool capable of outbound requests, instructing it to reach the AWS Instance Metadata Service (IMDS) at its link-local address. AgentCore's infrastructure let the request through, and the agent returned a full set of live temporary STS credentials — access key ID, secret access key, and session token — belonging to its execution role. Zenity exported the credentials onto its own machine, outside AgentCore entirely, and confirmed they were live. Those credentials did not belong to one sandbox. They belonged to a default IAM role whose permissions spanned all AgentCore agents in the same account and region, so one customer-service agent became a lateral-movement springboard into the internal finance agent next door: invoke it, read its data and tools, take its credentials and its private conversations.
Zenity's point about the fix most teams would reach for first is worth quoting: removing the raw HTTP tool changes nothing, because the isolation failure sits at the platform level, not the tool level — anything that can generate outbound traffic reaches IMDS the same way. The team reproduced the identical result through several tools, including Strands' built-in shell tool.
Enumeration at machine speed
From that foothold the researchers chained enumerability weaknesses and internal APIs into region-wide compromise. AgentCore names each agent's container repository after the agent (bedrock-agentcore-<agent_name>), and the execution role carried ECR read — so an automated tool pulled every agent's container image in the region within seconds, yielding source code, dependencies, and baked-in secrets, inspected as root. The role's READ, WRITE and DELETE reach across AgentCore and regional AWS services delivered the rest: all private conversations and long-term memories across users and sessions, API keys and OAuth tokens from Secrets Manager and environment variables (credentials agents use against enterprise resources and third parties beyond AWS), and destructive actions within the region.
Then came persistence. AgentCore's memory functionality accepted attacker-written entries, so the researchers planted malicious memories that redirected all future conversations to an attacker-controlled destination and quietly hijacked agent goals across sessions. Users would keep talking to what looked like a trusted enterprise agent while it operated under outside instructions. Memory is state, and state the attacker can write is a backdoor that survives the session.
The timeline is the second finding
Zenity found most of this in late 2025 and disclosed to AWS on 25 December 2025. AWS moved the entrance first: IMDSv2-only became the default for AgentCore on 14 February 2026. But when Zenity re-checked on 22 June 2026, the default execution role's permissions were unchanged — the keys to every agent in the region were still sitting behind a narrower door. AWS removed the dangerous grants (invoking other agents, reading conversations, Secrets Manager access) between 22 June and 29 September, and Zenity confirmed the environment fixed as of 8 October. The February patch closed the entrance vector; the actual privilege problem lived on for months afterward. That is the pattern defenders should internalise: the metadata call was the headline, the role was the vulnerability, and fixing the first without the second left the takeover intact.
AWS, for its part, told press the research mischaracterises expected and documented behaviour as a vulnerability. That dispute matters less than the outcome both sides agree on: the defaults changed — IMDSv2 enforced, the execution role cut down. Whatever the behaviour was documented as, AWS does not document it that way anymore.
AWS's year of agent holes
AgentCorruption is the third AgentCore credential problem in twelve months, and the three rhyme. In April, Palo Alto Networks' Unit 42 alerted AWS to a regression in which the AgentCore Runtime's microVM Metadata Service (MMDS) lacked session-token enforcement, exposing credentials to plain SSRF. In September, Unit 42 reported that default AgentCore Harness configurations let prompt injection steer agents into exfiltrating plaintext credentials from AgentCore Identity — the harness's built-in shell tool, enabled by default and running as root, reaching into the same memory space where credentials resolve — which AWS closed as merely informative under its shared-responsibility model, as we covered at the time. Three different doors, one room: the agent's credentials are reachable from the agent's workload, and every fix so far has closed one path while the design keeps offering others. The October Loom control-plane takeover (CVE-2026-103956, CVSS 10.0) showed the same overprivileged-default disease in SageMaker's agent stack the same week.
Zenity CTO Michael Bargury frames it as structural, not a bug count: cloud security is segmentation and least privilege, agents need creative space to be useful, and mixing the two is an inherent conflict every enterprise deploying cloud agents will have to adjudicate. “Enterprises should be mindful of that inherent conflict, and plan their security controls accordingly.”
What to do
- Verify you are on the fixed defaults, not just a recent version. Confirm AgentCore deployments enforce IMDSv2 and that execution roles no longer carry cross-agent invoke, conversation-read, or Secrets Manager grants. The June re-check proved version recency was not the same as fixed.
- Scope one execution role per agent, minimum privilege, and split trust tiers across accounts or regions. Customer-facing and internal agents sharing a region under one broad role is the exact topology AgentCorruption weaponised. A finance agent should never be invokable with a support agent's credentials.
- Treat agent memory as writable attacker state. Audit long-term memories for instructions no legitimate workflow wrote, and alert on memory writes that reference external destinations. A poisoned memory outlives every session fix.
- Rotate everything reachable. Any API key, OAuth token, or secret an agent could read during the exposure window — including third-party credentials outside AWS — should be treated as compromised, and ECR pull patterns reviewed for bulk image retrieval.
- Block and alert on IMDS-shaped egress from agent workloads where your platform allows it, and assume any tool with outbound traffic is an IMDS client until the platform proves otherwise.
Verification note: the SecTor disclosure date and venue, the single-prompt-to-regional-takeover chain, the IMDS-to-STS credential path (access key ID, secret, session token, exported and confirmed live), the default-role overbreadth, the ECR repository naming and seconds-scale region-wide image pull, the conversations/memories/Secrets Manager/env-var impacts, the malicious-memory persistence mechanism, the platform-not-tool isolation-failure finding with Strands reproduction, the December/February/June/September timeline, Bargury's quoted framing, and AWS's documented-behaviour response were read directly from Zenity Labs' 8 October press release and CSO Online's 8 October technical coverage. The April MMDS and September Harness Unit 42 findings are as CSO reported Unit 42's accounts; we did not re-test any AgentCore environment.
Sources: