AgentCorruption: What One Prompt Showed About Agent Permissions in the Cloud

On October 8, 2026, Zenity Labs published a research series it calls AgentCorruption. The team says a single prompt to one public-facing agent on Amazon Bedrock AgentCore was enough to get that agent's cloud credentials, and that the credentials reached every other AgentCore agent in the same AWS account and region. Source

There is a dispute about how to label this. Zenity calls it a chain of flaws and says AWS has patched it. AWS has told a news outlet that the research describes documented behavior and is not a vulnerability. Both statements can be true in part, and the useful lesson for builders sits between them. An agent that can make web requests is a request-forgery tool that a stranger can steer with plain language, and the cloud role behind it decides how much damage that stranger can do. Source

This article is based on Zenity's write-ups, AWS's own documentation and two news reports. We have not reproduced the research ourselves, so every claim below is attributed to the party that made it.

What AgentCore is

Amazon Bedrock AgentCore is AWS's managed platform for building, deploying and running AI agents. Zenity describes each agent as a container that runs on a serverless runtime inside its own Firecracker microVM, with memory, tools, gateways and identity services around it. Source

AWS's documentation describes the same isolation. Each user session runs in a dedicated microVM with its own CPU, memory and filesystem, and the microVM is terminated and its memory sanitized when the session ends. Source

That isolation is real, and it is aimed at keeping one customer, or one session, away from another. The AgentCorruption story is about something different: what the agent itself is allowed to reach once it is running.

Step one: the agent fetches its own credentials

Cloud workloads usually get temporary credentials from a local metadata service at the link-local address 169.254.169.254. On EC2 it is called IMDS. Zenity says AgentCore uses a close equivalent, the microVM Metadata Service, or MMDS. Reaching it from a compromised workload is, in Zenity's words, cloud hacking 101. Source

Zenity deployed a simple agent built with the open-source Strands SDK and gave it a standard HTTP request tool. It then asked the agent, in plain language, to call the metadata address and send the result to a listener the researchers controlled. Zenity says the microVM did not restrict that traffic, and the agent returned the temporary credentials of its execution role. The researchers say they then used those credentials from their own machine and confirmed they worked. Source

The attack needs no exploit code. It needs an agent with a tool that makes HTTP calls, which describes most useful agents. A weather agent calls APIs, a research agent browses, and a DevOps agent runs shell commands. Zenity says it got the same result through a shell tool as well. Source

AWS's documentation is direct about this part. It says any code or actor running inside the microVM can reach the execution role credentials through the metadata endpoint, and it tells customers to scope execution role permissions carefully. Source

Step two: the role decides the blast radius

Stolen credentials are only as dangerous as the role behind them. Zenity says the default role attached to AgentCore workloads was not scoped to the single agent. It says the role covered AgentCore resources across the whole region. Source

According to Zenity, that let the team:

• list the agents in the region and find their identifiers

• pull the container images of other agents

• invoke other agents they were never meant to reach

• read private conversations across agents, users and sessions

• write new memory events that changed agent behavior in later sessions

• read API keys and other secrets that AgentCore Gateway uses for outside tools

Source

The memory item deserves a second look. In Zenity's account, a planted memory told an agent to visit a web page the researchers controlled before every answer and follow what the page said. Editing the page later would change the agent's instructions without any new memory write. In a video demo, a user kept chatting while the conversation was sent to the researchers' server. Source

Nothing in a normal chat window would show that. The agent looks the same to the user, and the changed behavior sits in stored state.

The disclosure timeline

Zenity published dates for both reports. It reported the metadata access to AWS on December 25, 2025. In April 2026 AWS closed that report as informative and said that since February 14, 2026 new AgentCore agents launch with the stricter version of the metadata service. Zenity reported the broad default role on January 12, 2026. It says the role was unchanged in June, and that on September 29, 2026 it saw that AWS had removed the permissions for cross-region agent execution, reading private conversations and reading Secrets Manager secrets, and had narrowed others. Source

Dark Reading reports the same changes and calls the flaw now patched. It also notes that the researcher tied the pattern to the 2019 Capital One breach, where a request-forgery bug led to metadata credentials. Source

The Next Web reports that the disclosure has no CVE identifier, and that it corrected its own headline because the research covered one AWS account and region, not every agent everywhere. Source

What AWS says

AWS's statement to The Next Web says the research inaccurately paints expected and documented behavior as a vulnerability. It says an agent can reach resources in another AWS account only if the developer grants permissions on both the agent's execution role and the target resource. It recommends that customers give execution roles only the permissions their agents need. Source

The AWS documentation matches that view in two places. It says the policies the AgentCore command line tool generates are meant for development and testing, grant broad access, and are not suitable for production. AWS Docs It also tells teams to avoid wildcard resources and to use the full ARN of each runtime in IAM policies. Source

The documentation also says that from June 30, 2026 agent runtimes must have the stricter metadata version enabled, or they cannot be invoked. Source

So the two sides agree on the mechanics and disagree on the framing. Zenity says a default should not hand an agent that much reach. AWS says the reach is something customers are told to narrow. For a team shipping an agent this month, the framing matters less than the question of which roles are in your account today.

A checklist for your own agents

None of this is specific to AWS. The same pattern applies to any cloud where an agent runs with an identity. Here is a practical list that follows from the sources above.

1. Treat every HTTP or shell tool as an outbound request an attacker can write. If a stranger can chat with the agent, a stranger can ask it to call internal addresses. Restrict the destinations the tool may reach, and block the metadata address from the agent's network path where your platform lets you.

2. Turn on the stricter metadata version everywhere. AWS says new AgentCore agents use it and that runtimes need it from June 30, 2026. Check your older runtimes anyway.

3. Write a role per agent. Name the exact runtime ARN in each policy. Avoid wildcards, and do not carry a development policy into production. AWS says the generated ones are for testing.

4. Remove permissions the agent never uses. Zenity's list of reach includes listing agents, reading conversations, writing memory and reading secrets. Ask whether each agent needs any of them. Most do not.

5. Keep secrets away from the execution role. Use the platform's identity service for outside tools, and give the role no direct read access to the secret store.

6. Treat agent memory as untrusted input. Log memory writes, show them to a reviewer for sensitive agents, and expire them. A stored instruction is a prompt that survives restarts.

7. Separate public and internal agents. Zenity's overview says organizations routinely run customer-facing and internal agents side by side in the same cloud environments. Put them in different accounts or at least different roles. Source

8. Alert on unusual role use. Credentials used from an address outside your cloud, or a role listing agents it never lists, are signals worth an alarm.

Where this fits in agent operations

AgentCorruption is one more case where the model was not the weak part. The path ran through a normal tool, a normal metadata service and a role that was wider than the job. That is an operations problem, and it is the kind that shows up when agents move from a demo to a shared environment.

Our AgentOps services page covers the work around that move, including tool access, permissions, logging and review for agents in production. If you are running agents on a managed cloud platform and have not reviewed their roles, that review is a small piece of work with a clear result.