Zenity's AgentCore research: the prompt was the way in, the agent's cloud role decided the damage

Prompt injection is usually discussed as a model problem: how to stop an agent from following instructions hidden in its input. Zenity Labs’ new research on Amazon Bedrock AgentCore is a reminder that the more expensive question comes after the injection succeeds. What can the agent’s own cloud identity reach?

In the researchers’ tested environment, the answer was far more than one agent should. Zenity reports that, starting from a single public-facing agent, it obtained the credentials of that agent’s execution role, and that the role’s permissions extended to every agent in the same AWS account and region: other agents could be invoked, their container images retrieved, and their memory, including private conversations between users and agents, read and altered.

Two cautions frame everything below. First, this is the researchers’ account of their own test configuration, published on October 8 as a series of posts; we found no public AWS statement on it, and AWS closed the first of Zenity’s two reports as “informative”. Second, Zenity sells security products for AgentCore agents. Neither point makes the findings wrong, but both belong next to them.

The role, not the prompt, set the blast radius

The core finding is about scope. According to Zenity, the default execution role attached to agents “wasn’t scoped to the specific agent”: its permissions covered agent runtimes, memory and logs across the region rather than the resources of the agent it belonged to. The researchers call the result “wide lateral movement”.

That is a familiar cloud failure in a new place. A workload role written with wildcards is a risk on any compute service. On an agent platform, the risk is sharper for two reasons. The workload takes instructions in natural language from whoever can talk to it, so the path from outside input to the role is short. And the neighbors it can reach are other agents, whose memory holds what users told them, which is often exactly the personal and business data the platform was supposed to keep apart.

The memory finding deserves its own line. Zenity reports that the role could not only read memory but write to it, which turns a confidentiality problem into an integrity one: an agent that trusts its memory can be steered by whoever can add to it. We made the general point when we wrote that agent memory is enterprise data storage; this is what it looks like when the write path is open.

What an agent's execution role should reach

This agent's own resources

• Its runtime
• Its memory
• Its logs
• Its model access

Scoped by resource, not by wildcard

Everything else in the account

• Other agents
• Their memory and sessions
• Shared secrets
• Container images

Reached only through an audited call under another identity

What AWS changed, and what it leaves to you

Zenity’s timeline runs for most of a year. It reported the initial access issue on December 25, 2025, and the overprivileged default role on January 12, 2026. AgentCore moved to IMDSv2 only, a hardening of how workloads obtain credentials, on February 14, 2026, according to the researchers. In June, they say, the default role was still unchanged. During a final review on September 29, Zenity observed “substantial changes” to the default execution role: cross-region agent execution, reading private conversations and access to Secrets Manager were removed, and other permissions were significantly restricted. Zenity does not publish the role’s permissions before and after.

Three consequences follow for teams running agents on AgentCore, or on any platform that attaches a cloud role to an agent.

A safer default does not rewrite roles you already have. Zenity does not say whether existing roles were updated. IAM roles in a customer account normally change only when someone changes them, so agents deployed with the earlier default deserve a direct review of their execution roles rather than an assumption.

Scope each role to one agent. Runtime, memory, logs and secrets should be named by resource. Separating public-facing agents from internal ones, by account where the stakes justify it, limits what one compromise can reach; Zenity notes that many organizations run both kinds side by side.

Treat outbound requests from agent tools as a security boundary. Any tool that fetches URLs on the agent’s behalf can be aimed somewhere unexpected. Egress rules enforced outside the agent, the kind of boundary we discussed in our look at agent containment, and credentials that never enter the agent’s environment, as in AWS’s own Strands Box design, both shrink what a manipulated agent can do.

The lesson is not specific to AWS. Every managed agent runtime gives the agent an identity in the cloud underneath it, and that identity is usually created by deployment tooling, reviewed by nobody in the AI program, and invisible in the agent’s own audit trail. Prompt injection will not be fully prevented. How far it travels is decided in IAM, before the first prompt arrives.