A single prompt took over every AWS agent in the region

How was it fixed?|AWS switched AgentCore to IMDSv2 exclusively in February 2026 and had corrected the excessive permissions by late September 2026. Should enterprises worry?|The specific flaw is patched, but the underlying pattern of overprivileged agents and weak isolation affects most agentic platforms, so audit your own agent roles now. ---

A single chat prompt sent to one AI agent was enough to seize control of every other agent in the same Amazon Web Services account and region. That is the finding from Zenity Labs, whose research into Amazon Bedrock AgentCore, AWS's managed platform for running autonomous AI agents, exposed a chain of weaknesses that AWS has only recently finished remediating.

The most alarming part is not the credential theft itself. It is the blast radius. Because the default AgentCore role granted access to all AgentCore resources in a region rather than a single agent, stolen tokens from one exposed agent unlocked container images, agent memories, user conversations, and secrets stored in AWS Secrets Manager.

What changed

The story begins in late 2025, when Zenity researchers Tamir Ishay Sharbat and Lana Salameh tested whether an agent deployed through AgentCore could reach its own instance metadata service. The IMDS is a local endpoint, normally reachable only from inside a cloud virtual machine, that returns details about the instance: region, availability zone, subnets, security groups, and crucially, temporary security credentials tied to the workload's IAM role.

Their test worked. An attacker with nothing more than chat access to a publicly exposed agent could send a prompt asking it to fetch a URL, a classic server-side request forgery (SSRF) technique in which the agent is tricked into making a request on the attacker's behalf. The response contained the agent's temporary AWS credentials in raw JSON. AgentCore's Firecracker MicroVM, a lightweight virtualisation layer designed to isolate workloads, did not block the request.

With those credentials, Zenity demonstrated that an attacker could enumerate every other agent in the region, log into Amazon Elastic Container Registry (ECR), pull agent container images, and run them as root to inspect source code. The same tokens allowed access to the memory resources used by agents, from which user identities and full conversation histories could be extracted. Worse, an attacker could write new memories into other users' sessions, persistently altering an agent's behaviour and hijacking its goals in future conversations.

The timeline matters. Zenity disclosed to AWS in December 2025 and followed up in January 2026 with details of the overprivileged default role. On 14 February 2026, AWS switched AgentCore to IMDSv2 exclusively, which requires a session token and blocks the simplest SSRF credential theft. But the excessive permissions remained. Zenity checked again on 22 June 2026 and found nothing had changed. A final review on 29 September 2026 confirmed AWS had addressed the outstanding problems. AWS reportedly told The Register that Zenity's research misrepresents documented behaviour as a vulnerability and that developer error would be required to enable the attack.

Impact on businesses

For any organisation running AgentCore in production, the practical exposure window ran from roughly late 2025 until at least mid-2026, and possibly later. That is eight to ten months in which an agent reachable by an outsider, whether through a customer-facing chatbot, a support widget, or a partner integration, was a potential foothold into the entire agent fleet.

The sectors most exposed are those that have rushed agents into customer-facing roles. Financial services firms deploying AI assistants for account queries, healthcare providers triaging patient questions, and retailers running shopping or returns agents all typically grant those agents broad permissions to call internal APIs and read databases. Under AgentCore's old defaults, one compromised agent inherited the keys to the rest.

This is not hypothetical. The AI hacking tool that hit Korean banks showed how quickly attackers are moving to weaponise agentic systems, and the chat logs left behind in that case demonstrated that AI-assisted intrusion is now an established technique rather than a research curiosity. A prompt-based credential grab requires no malware, no phishing email, and no exploited binary. It requires a text box.

The memory poisoning angle deserves particular attention from compliance teams. If an attacker can write to an agent's long-term memory, they can seed false instructions that survive across sessions. A customer service agent could be told to approve refunds above policy limits for specific accounts. A procurement agent could be nudged toward a fraudulent supplier. Because these changes persist, they may not surface in any single conversation review and may be attributed to model error rather than intrusion.

Impact on consumers and users

The consumer-facing consequence is quieter but real. If an attacker extracted agent session data, as Zenity demonstrated, then conversations between users and AI agents were readable. Those conversations frequently contain personal information: order numbers, addresses, medical symptoms, financial circumstances. Under UK GDPR, that constitutes a personal data breach, and organisations that failed to detect it cannot have notified affected individuals within the 72-hour window.

Users may also notice unexplained shifts in agent behaviour. An agent that suddenly offers a discount it never offered before, or that seems unusually willing to bypass verification, may have had its memory tampered with. The practical advice for consumers is limited, because there is no way to inspect an agent's memory from the outside. The burden sits with the operator.

Impact on the wider industry

The AgentCore case is the clearest illustration yet of a structural problem in agentic AI: vendors ship agents with permissions scoped for convenience rather than security. A default role that covers every agent in a region is easier to document and easier to support. It is also a lateral movement buffet.

The internal links between this and wider cloud security failures are hard to ignore. The Nvidia GPU monitoring endpoints that exposed details of 12,000 AI accelerators followed the same pattern: AI infrastructure deployed fast, with observability and access controls bolted on afterwards. Similarly, mounting evidence of credential-focused intrusion, such as the China-linked hackers who built a portal for browsing stolen email, shows that stolen tokens are the currency of modern breaches. Agent platforms are simply a new mint.

AWS's response will set expectations for rivals. Microsoft, Google Cloud, and Oracle all now sell managed agent runtimes, and each faces the same design questions about isolation, default permissions, and metadata exposure. Expect procurement teams to start demanding answers in security questionnaires. Expect also a rise in agent-specific tooling. Nvidia has already moved with OpenShell and Sentry, an AI agent safety platform that runs on a separate chip, which is exactly the kind of hardware-enforced kill switch that would have limited this attack's spread.

Regulators are circling too. The EU AI Act's obligations for high-risk systems include logging and human oversight requirements that an uncontrolled agent fleet would struggle to satisfy. In the UK, the ICO has shown willingness to act on cloud misconfigurations where personal data is involved.

Key takeaways

• A chat-only attacker could steal an agent's AWS credentials with one prompt, because AgentCore's MicroVM did not block access to the instance metadata service.
• Default AgentCore roles spanned every agent in a region, turning one compromised agent into a fleet-wide takeover.
• AWS switched to IMDSv2 in February 2026 but did not correct the overprivileged roles until roughly September 2026.
• Memory poisoning allows persistent behavioural changes that survive across sessions and evade single-conversation review.
• The pattern of convenience-first permission defaults is industry-wide, not AWS-specific.

What comes next

In the coming weeks, expect AWS to publish updated guidance on least-privilege role design for AgentCore, and expect third-party auditors to begin offering agent permission reviews as a service. Over the next quarter, rival platforms will likely pre-emptively tighten their own defaults, because being named in the next Zenity-style disclosure is expensive.

Further out, look for two shifts. First, per-agent identity: rather than one role per account per region, each agent should carry its own narrowly scoped identity with short-lived tokens. Second, network egress controls at the agent runtime layer, so that an agent simply cannot reach the metadata endpoint regardless of what a prompt asks it to do.

Conclusion

This is a net positive, but only narrowly, and only because disclosure forced a fix that might otherwise have waited years. AWS deserves credit for eventually addressing both the isolation flaw and the permissions problem. It does not deserve credit for the eight-month gap between the two, nor for its initial framing of the finding as documented behaviour.

The winners are enterprises that now know to audit agent permissions before an attacker does, and the security researchers whose patient follow-ups made the fix happen. The losers are organisations that deployed agents at scale during the vulnerable window and have no way to know whether their session data was read or their agent memories were rewritten. For them, the question is not whether to keep using agentic AI. It is whether they can prove, to a regulator or a customer, that they know exactly what their agents are allowed to do.