Zenity researchers found that one prompt could compromise all AI agents in an AWS account

Meta description: Zenity Labs found a chain of flaws in Amazon Bedrock AgentCore that let one public agent hand over credentials and take over every agent in the same AWS account and region.

Tags: Amazon Bedrock AgentCore, AI agent security, Zenity Labs, AWS credentials, prompt injection

Security researchers at Zenity Labs say a single publicly accessible AI agent running on Amazon Bedrock AgentCore was enough to seize control of every other AgentCore agent in the same AWS account and region. The chain of vulnerabilities, which the firm calls "AgentCorruption," allowed an attacker with nothing more than chat access to one public agent to read private conversations, copy source code, and harvest stored credentials.

The finding matters beyond one platform. AgentCore is AWS' managed environment for running enterprise AI agents with tools, memory, and access management, and AWS has opened it to all enterprises, counting Sony and Ericsson among its users. The episode shows how quickly a convenience-first default configuration can turn a helpful assistant into an entry point for an entire cloud environment.

Background: how AgentCore is supposed to work

AgentCore gives agents three things that make them useful: tools to act, memory to persist context, and identity management to authenticate against other services. That third piece is where the trouble started.

AWS workloads commonly obtain temporary credentials from the Instance Metadata Service (IMDS) at the internal address 169.254.169.254. Those credentials let a workload impersonate the instance it runs on. An AI agent should never be able to reach that endpoint, because anything that captures the credentials can act as the instance from anywhere.

Development: from one prompt to a region-wide takeover

Zenity built a test agent with Strands, AWS' open-source agent framework, which ships with a web tool. According to the firm's technical write-up, the agent lacked proper isolation from the metadata service. Asked in plain language to query that service and forward the results to an external server, the agent complied. "The sandbox boundary we were supposed to be fighting simply wasn't there," the researchers wrote.

The response contained the agent's full temporary AWS credentials, including access keys and a session token, plus certificate and key material for an internal AWS service and a presigned URL for internal S3 storage outside the researchers' account. The credentials worked from the researchers' own machine, so the agent was no longer needed. Zenity says removing the web tool would not have closed the hole, since the flaw sat in the platform; the team also reproduced the attack through a command-line tool.

The second half of the chain was permissions. AgentCore's default execution role was not scoped to the agent that received it. It applied across every agent in the same account and region, with read, write, and delete rights. An automated script listed all agents, pulled their container images, and copied source code in seconds. Because those packages often carry forgotten passwords and API keys, an attacker could pivot from a public customer service agent to an internal finance agent. The researchers could also read every private conversation between users and agents, and for agents with long-term memory enabled, plant instructions that redirected future conversations to an external destination.

Latest: what AWS changed, and when

Zenity says it reported the findings to AWS on December 25, 2025. AWS subsequently made IMDSv2, the hardened version of the metadata service that the attack relied on, the default for new AgentCore deployments. Around August, according to Zenity's updated account, AWS also revised AgentCore's default execution role so agents could no longer invoke other agents, read private conversations, or retrieve credentials from AWS Secrets Manager. Other permissions were restricted as well.

Zenity still recommends that companies define custom roles with narrower access, and notes that it sells a security platform for AI agents, giving it a commercial interest in this research area. Zenity CTO Michael Bargury framed the underlying tension: "Cloud security is about segmentation and least-privilege access. But AI agents need creative freedom to be useful."

The AgentCore case fits a pattern Zenity has documented before. In its AgentFlayer research, zero-click attacks pushed Salesforce Einstein, Copilot Studio, and Cursor to redirect customer data or leak credentials. With AgentForger, a tampered ChatGPT link created an autonomous agent in OpenAI's Workspace Agents with approval requirements disabled; OpenAI fixed that issue within four days. Google DeepMind lists long-term memory manipulation as a separate attack class in its "AI Agent Traps" taxonomy, and the red-teaming study "Agents of Chaos" documented researchers remotely controlling an OpenClaw agent through an externally editable document in its memory file.

OpenAI CEO Sam Altman has argued agents should receive only the minimum access they need. According to Zenity, AgentCore's default role broke that rule, and the gap between OpenAI's four-day fix and months of broad defaults in AgentCore is the number to watch as enterprises scale agent fleets that mix public and internal workloads in one environment.