AWS AgentCore's AgentCorruption, Explained
One prompt to a public AgentCore chatbot returned the account's own keys. Sibling agents and their memories followed. The microVM held; defaults did not.

One prompt, sent to one public-facing AWS AgentCore chatbot, came back holding the account's own temporary credentials. The agent fetched the instance metadata address at 169.254.169.254 because nothing inside its Firecracker microVM stopped it, and the metadata service answered with the execution role's keys. Zenity Labs named the chain AgentCorruption when it presented the work at SecTor 2026. The question it leaves behind is awkward: the isolation held, and the account still fell.
The research, by Tamir Ishay Sharbat and Lana Salameh, is a study in default settings. The microVM lacked network isolation that would have blocked metadata requests. The default execution role was scoped to every resource in the account and region rather than to one agent. The platform's memory and conversation stores accepted writes from any agent holding those credentials. Dark Reading's coverage and the account of AWS's response fill in the timeline below.
The chain, hop by hop
- Hop 1, SSRF to IMDS. Any agent able to make HTTP requests could ask the metadata service for temporary credentials. It is the same class of flaw that broke Capital One in 2019, relocated from a web server to an agent's tool call.
- Hop 2, one role for the whole region. Because the execution role covered all agents in the account and region, the stolen credentials enumerated siblings instead of stopping at one chatbot.
- Hop 3, images, conversations, memories. Container image repositories named for agent IDs could be pulled; InvokeAgentRuntime and ListEvents opened private chat history. CreateEvent wrote memories that future sessions would trust, a persistence mechanism that outlives reboots.
- Hop 4, the secrets store. GetResourceApiKey and Secrets Manager access turned the compromised agent into a credential broker for the environment it was supposed to serve.
Nine months between report and fix
Zenity reported the IMDS exposure in December 2025. AWS made IMDSv2 the default for new AgentCore deployments on 14 February 2026, which closed the credential hop for anything created after that date. The overprivileged role survived until 29 September 2026, when AWS removed cross-agent invocation, conversation reading and Secrets Manager access from the default role, confirmed in Zenity's final review. Through most of that window AWS characterized the behaviour as expected and documented. The researchers' scenario does not support that framing: behaviour that hands one chatbot the keys to a region is a design decision with a blast radius.
Both halves of that sentence are the story. The February fix was real, and for seven months the remaining chain needed only an agent with HTTP access and a role that still saw everything. Default scope is a security decision whether or not anyone labels it one.
What generalizes beyond AWS
Strip the product names and AgentCorruption is the seam taxonomy from our sandbox escape report wearing a cloud badge. It is a control plane the isolation boundary does not consider part of itself, vending credentials to whatever stands inside. Every platform that places a metadata service, orchestrator API or credential endpoint within reach of agent code carries this surface. Self-hosted stacks recreate the pattern with loopback control planes.
The checks that break the chain
- Require a session token on metadata, everywhere. IMDSv2 turned hop 1 from a request into a negotiation; anything still answering v1 inside a workload boundary is standing inventory for the next researcher.
- Scope execution roles per agent. Hop 2 is the amplifier. Least privilege per agent converts account takeover back into single-agent compromise, which is an incident instead of a catastrophe.
- Authorize memory writes like deployments. An appendable memory store is persistence an attacker can buy with one compromised role; treat CreateEvent-style access as production write access and alert on it.
- Map what answers from inside. Metadata services, registries, proxies and orchestrators are control planes; inventory them from a zero-public-ip baseline before a disclosure inventories them for you.
- Read conversation access as confidentiality. Private chat history reachable through an agent role is a data breach your users experience personally. Log reads of conversation stores the way reads of payment data are logged.
Krova removes the precondition rather than the chain. A Cube has no inbound address for a public-facing agent to hide behind, and no cloud metadata service inside the microVM to answer hop 1. What remains is role design and platform choice, which is why microVM isolation and the agent operations runbook still carry weight after the patches land.
FAQ
Was AgentCorruption a sandbox escape? No. The Firecracker boundary held at every hop; the chain walked through metadata vending and role scope around it. That distinction is exactly why the microVM behaviour could be called expected while the role still had to shrink.
Is AgentCore safe now? The post-29 September defaults remove the enumerated chain for new deployments. Agents created before 14 February 2026, or under custom roles, still need the same audit: metadata version, role scope, memory write access.
What is the one setting to check first? Whether anything inside your agent's network boundary answers credential requests without a session token, on AWS or anywhere else. Hop 1 has had the same shape since 2019.
No inbound address, no exposed agent
Krova Cubes boot with no public IP. Agents call out through egress you allowlist; the internet cannot reach a chatbot that does not exist to it.




