AgentCorruption: One Prompt Hijacked Every Bedrock AgentCore Agent

Zenity Labs says a single chat message to one publicly reachable agent was enough to take over every agent in the same AWS account. The research, published on October 8, 2026 under the name AgentCorruption, targets Amazon Bedrock AgentCore, AWS's managed platform for building and running AI agents. AWS has since patched parts of the problem, but the chain is a clean illustration of why agent platforms need the same cloud hygiene as any other workload, and a little more. If you want the background on how hostile text steers an agent, start with our guide to indirect prompt injection.

TL;DR: the AgentCorruption chain at a glance

What did Zenity actually find?

Zenity's own write-ups describe AgentCorruption as "a chain of flaws in AgentCore that let us turn a simple prompt to a single exposed agent into control over every agent in the same AWS account and region." The series is split into four posts on labs.zenity.io: initial metadata access, memory poisoning, credential theft from AWS Secrets Manager, and the default execution role.

The story is told in five steps, and none of them is exotic. Each is a well-known cloud attack pattern, and AgentCore's contribution was making the early steps unusually easy.

Step 1: A prompt that reaches the metadata service

AgentCore runs each agent session in an ephemeral Firecracker microVM. Like an EC2 instance, the microVM has a metadata service at the link-local address 169.254.169.254, which hands the workload its identity and configuration. Reaching that address from a compromised workload is, in Zenity's words, "cloud hacking 101".

The researchers built a test agent with the Strands SDK, AWS's open-source agent framework, whose built-in tools include http_request and shell. They asked it, in plain language, to fetch the metadata endpoint. It did, and returned the response. Zenity reports that the same worked through a command-line tool, which points at the platform rather than at one risky tool. In their words, "The sandbox boundary we were supposed to be fighting simply wasn't there."

This is the classic server-side request forgery shape, with a language model acting as the confused deputy. Anything that lets an agent make a request on an attacker's behalf, whether a weather lookup, a browsing tool or a DevOps shell, becomes a request-forgery primitive when the network underneath is not locked down.

Step 2: Stealing the agent's identity

Walking the metadata paths returned the name of the agent's execution role and then a full set of temporary STS credentials: access key ID, secret access key and session token. Zenity exported them to its own machine, confirmed they were live, and from that point no longer needed the agent at all.

The metadata service offered more. According to Zenity, the user-data endpoint exposed the container configuration, including account ID, ARNs and the agent's container image URI in Amazon ECR, and the instance tags included certificate and private-key material for an internal AWS service and a presigned URL to an internal S3 bucket outside the researchers' account. Zenity says it verified the key material by comparing moduli with OpenSSL.

Step 3: The default role does the rest

Stolen credentials are only as powerful as the role behind them. The Decoder's summary of the research says AgentCore assigned a default execution role that applied across the whole region, with read, write and delete rights. With it, the researchers could list every agent, download code packages in seconds and invoke each agent. Packages, as in most real deployments, often contained forgotten passwords or API keys.

The consequence is lateral movement of a very modern kind. A public customer-support agent becomes a doorway to an internal finance agent, and private conversations between users and agents become readable.

Step 4: Memory poisoning

For agents with long-term memory, Zenity says it planted instructions that made agents forward later conversations to an external destination, quietly and persistently. This is the same persistence idea that researchers have shown against other agent products, and it is why the memory layer deserves the same scrutiny as the tool layer. Our write-up of the Agent Zero memory-provenance benchmark covers how memory origin tracking can help.

Step 5: Secrets Manager

The default permissions also reached AWS Secrets Manager, the very service AWS recommends for keeping credentials out of code. That put keys for services outside AWS within reach too.

What has AWS fixed, and what hasn't it?

Per The Decoder's reporting on the Zenity research, the timeline looks like this:

Zenity calls the fix partial and still recommends that companies give agents custom, narrower roles. We have not found an AWS security bulletin that describes these changes in AWS's own words, so treat the remediation details as Zenity's account, relayed by The Decoder, rather than an AWS confirmation. If you run AgentCore, check the platform documentation at aws.amazon.com/bedrock/agentcore and your own agents' deployed configuration rather than assuming you inherited the newer defaults.

Why this matters beyond one AWS service

Agents turn old bugs into one-sentence exploits

SSRF to the metadata service has been a staple of cloud breaches for years, and IMDSv2 exists precisely to blunt it. What changes with agents is the exploit effort. You no longer craft a malicious request; you ask politely. A public chat window plus a general-purpose HTTP or shell tool is a request-forgery endpoint by design, and the model's willingness to help is the vulnerability.

Least privilege is the real control

Zenity's CTO Michael Bargury, quoted by The Decoder, pointed at the tension between least-privilege security and the freedom agents need to be useful. A region-wide default role resolves that tension in the wrong direction. The same pattern shows up in incidents we have covered, such as PixelLeak, where agents' convenient defaults leaked internal material, and Plugin4Shell, where agent tooling became a path to code execution.

Isolation claims need testing

Firecracker microVMs are a serious isolation technology, and the microVM boundary did what it was designed to do. The failure was in what sat inside and beside it: reachable metadata, and an identity that was too powerful. Compare the design questions in our piece on agent sandbox isolation on Google Cloud. Isolation is a property of the whole system: network egress, identity, secrets and tooling, not just the compute boundary.

Vendor response speed is part of the story

Zenity's related work includes AgentFlayer, covering zero-click attacks on several enterprise agent products, and AgentForger, in which a crafted ChatGPT link created a rogue agent in OpenAI's workspace agents. The Decoder reports that OpenAI closed the AgentForger issue within four days, while the AgentCore permissions problem persisted for months after the December report. That comparison comes from Zenity's perspective, and AWS has not, as far as we found, published its own timeline, so read it as one side of a disclosure story.

What should teams on AgentCore, or any agent platform, do now?

This checklist applies broadly to any managed or self-hosted agent runtime.

1. Give every agent its own execution role. Start from zero permissions and add only the actions that agent needs. Never share one role across a public-facing agent and an internal one.
2. Redeploy older agents. Defaults applied to newly deployed agents may not reach agents created earlier. Confirm IMDSv2 and role settings on what is actually running.
3. Remove unneeded tools from public agents. A support bot rarely needs a shell or an arbitrary HTTP client. If it needs web access, restrict destinations with an allow list.
4. Block link-local egress. Where your platform allows it, deny traffic to 169.254.169.254 from agent code paths that do not need it.
5. Treat code packages and images as secret-bearing. Scan them for keys and tokens, rotate anything found, and move credentials into a secrets manager with narrow, per-agent access.
6. Audit memory. If agents keep long-term memory, log writes, record where instructions came from, and review what each agent can write to its own store.
7. Log and alert on agent identity use. Credentials used from outside the platform, or an agent role listing other agents, should page someone.
8. Add runtime guardrails. Policy engines and monitoring from the AI agent security platforms category and open projects like NVIDIA's OpenShell and Sentry can catch exfiltration attempts that prompts alone will not stop.

If you are choosing where to run models and agents, note that AgentCore also sits behind newer model launches on AWS, such as Grok 4.7 on Amazon Bedrock. The model is one choice; the permissions around it are another, and the second is the one that decides blast radius.

What readers are asking

Can an attacker do this to my agent without any special access? In Zenity's setup the entry point was a publicly reachable chat interface, such as a customer support window. That is why public exposure plus powerful tools is the risky combination.

Is this only an AWS problem? The specific flaws are AgentCore's, but the pattern, an agent steered into reaching a metadata endpoint or an overpowered identity, applies to every cloud and every agent framework. Credential-harvesting from metadata services has been a cloud staple for years.

Does this count as an agent attacking third parties? No. This is researcher-run, authorized testing disclosed to the vendor. For cases where agents themselves affected real organizations, see our tracker at /felony-bench and the explainer on agent legal liability.

What is still unconfirmed? AWS's own statement. The remediation timeline here comes from Zenity as relayed by The Decoder; we have not seen an AWS bulletin that confirms every detail, and the count of affected customers is not public.

Bottom line

AgentCorruption is less a story about a clever exploit than about defaults. A model that politely obeys, a network path that should have been closed and a role that should have been narrow combined into account-wide takeover from one message. AWS has moved the defaults in the right direction, per Zenity, but the lasting lesson is that agent security is ordinary cloud security with a more persuasive attacker interface. Audit your roles, your egress and your stored secrets this week.

Primary sources: Zenity Labs: Initial IMDS access, Zenity Labs: One role to rule them all, and The Decoder's report.

Related reading

• What is indirect prompt injection? A guide for agent builders
• AI agent security platforms compared
• Google Cloud agent sandboxes: five things about isolation
• PixelLeak: agents posted internal screenshots to public GitHub
• Plugin4Shell: RCE through AI coding agents
• NVIDIA's open agent safety platform
• Agent Zero memory provenance benchmark

Details reflect Zenity Labs' publications and press coverage as of October 8, 2026; AWS defaults may change.