What can your AI agent's execution role reach?

In October 2026, researchers at Zenity Labs published a chain they call AgentCorruption. According to The Next Web, one prompt to a public-facing agent on Amazon Bedrock AgentCore led to control over other agents in the same AWS account and region. The prompt was simple. What made it matter was the permission set of the role the agent ran as.

The short answer to the question in the title: an AI agent can reach whatever its execution role can reach, and anyone who can steer the agent may be able to borrow that role. AWS disputes that this was a vulnerability and says the behavior is documented. Both readings point to the same thing to check.

In this piece, we will cover:

• What the AgentCorruption research describes, and what AWS says
• What an execution role is and why it sets the blast radius
• Which related AgentCore findings appeared in 2026
• How to check the execution roles of your own agents
• Where nerl0 fits, and what this does not show

What happened in the AgentCorruption research?

According to The Next Web, the agent Zenity tested had a common web-request tool. Asked in plain language, it fetched the instance metadata service and returned the temporary credentials of its execution role. Zenity says a shell tool gave the same result.

With those credentials, the researchers report that they listed all agents, downloaded container images and source code, and invoked internal agents they were not meant to reach. The Next Web also reports that the role allowed reading users' private conversations with agents and reading secrets in AWS Secrets Manager, including credentials for services outside AWS.

Zenity also describes a persistence step. The researchers wrote a fake conversation event into agent memory. It was stored as a lasting instruction to visit a researcher-controlled web page before every answer, so editing that page changed the agent's behavior later.

Note the scope. The Next Web corrected its original headline: the research covered one account and one region, not every agent in a region.

What does AWS say?

AWS does not treat this as a vulnerability. In its statement, quoted by The Next Web and CSO Online, AWS says the research presents expected and documented behavior as a flaw. It adds that access to another account's resources needs explicit grants on both the execution role and the target resource. AWS recommends giving execution roles only the permissions an agent needs.

The timeline below is Zenity's account, as reported by The Next Web and CSO Online.

Let's Data Science points out that this is a historical research chain plus later changes. It is not proof that every current deployment is exposed. The outcome depended on the permissions of each workload identity.

What is an execution role, and why does it set the blast radius?

An execution role is the identity an agent runtime assumes when the agent acts. It is a non-human identity: no person logs in with it, but it holds real permissions. The model decides what to try. The role decides what is possible.

This is why the prompt is only the entry point. Prompt injection changes what the agent attempts. The execution role decides how far the attempt can go. A narrow role keeps a successful injection small. A broad role turns it into access to everything the role can touch, including other agents and the secrets they use.

CSO Online quotes analyst Fred Chagnon, who compares the pattern to the server-side request forgery behind the 2019 Capital One breach. In the agent case, he says, the trigger is an agent fetching a URL. The old lesson about metadata services and broad roles still applies. What is new is that a plain-language request can start it.

Is this the only AgentCore finding in 2026?

No. Several reports this year point at the same pairing of tools and roles.

• April 2026, Unit 42: according to CSO Online, Palo Alto Networks Unit 42 reported that AgentCore Runtime used a microVM metadata service without session token enforcement, which could let credentials be extracted through server-side request forgery.
• June 2026, AWS bulletin: AWS published CVE-2026-12530 for the install_packages() helper in the bedrock-agentcore Python SDK. An incomplete blocklist let package-name arguments redirect pip to another index or read files in the sandbox. Version 1.6.1 fixes it.
• September 2026, BeyondTrust: Infosecurity Magazine reports a second SDK flaw, CVE-2026-16796, that got past the first fix and is fixed in 1.18.1. BeyondTrust said the impact depends on the permissions of the Code Interpreter's execution role.
• September 2026, Unit 42: CSO Online reports that default AgentCore Harness configurations let prompt injection steer the agent into exfiltrating credentials managed by AgentCore Identity. AWS closed that report as informative under the shared responsibility model.

Each finding has its own entry point. The common thread is what the identity behind the agent was allowed to do once it was reached. Adversa AI's November 2026 roundup of agent security resources lists AgentCorruption among the month's main items.

How do you check what your agents' roles can reach?

1. List every agent and its role. Include agents built by teams outside security, and code interpreters or sandboxes that carry a role of their own.
2. Read the permissions, not the role name. Zenity says the default role it tested held read, write and delete permissions across AgentCore and other AWS services in the region, according to CSO Online.
3. Mark the tools that leave the sandbox. Web-request and shell tools are the ones the research used. Analysts quoted by CSO Online advise treating them as high-risk and restricting egress.
4. Follow the path to sensitive stores. Check whether the role can read a secrets store, conversation history or container images. Those are the hops that turned one agent into many in the research.
5. Remove what each agent does not need. This is AWS's own recommendation. Do it per agent, not per account.
6. Check again after every change. Zenity's timeline shows that defaults change. A review from last quarter describes last quarter.

Where nerl0 fits

nerl0 maps every AI agent and non-human identity and what each can reach. It connects read-only through each platform's own interfaces and reads configuration and permission data, never the contents of data stores.

The Security Graph shows authority paths: agent, credential, role, crown-jewel data store. Every step is an observed relationship. A question like "which agents can reach our secrets store, and through which role?" is one you can ask the Agent in plain language. If you activate it as a Question, it is measured again with every scan. The guide on how to read the Security Graph walks through a path step by step.

Issues carry severity, evidence, an owner and a recommended breakpoint, such as the one permission on a role that removes the most paths. The next scan verifies the fix.

To shrink a broad role, follow least privilege for AI agents in five steps.

Summary

The AgentCorruption research, which AWS disputes as a vulnerability, shows how far one agent can reach when its execution role is broad. The prompt opened the door, and the role decided how far it went. Start with a list of agents and their roles, read the actual permissions, and remove what each agent does not need. Then check again after every change, because defaults change too.

Sources

1. Zenity says one prompt took over every AgentCore agent in an AWS account, The Next Web, accessed Nov 12, 2026
2. AWS's repeated problems with AI agent controls illustrates the autonomous agent dilemma, CSO Online, accessed Nov 12, 2026
3. AWS Updated AgentCore After AgentCorruption Research, but Disputes the Finding, Let's Data Science, accessed Nov 12, 2026
4. Amazon Bedrock AgentCore Flaws Could Expose AWS Credentials, Infosecurity Magazine, accessed Nov 12, 2026
5. CVE-2026-12530: Improper neutralization of argument delimiters in AWS Bedrock AgentCore Python SDK install_packages(), Amazon Web Services, accessed Nov 12, 2026
6. Top AI agent security resources, November 2026, Adversa AI, accessed Nov 12, 2026