One public-facing AI agent on AWS could read, rewrite, and delete every other agent in the region

Security researchers at Zenity Labs reported a chain of vulnerabilities in Amazon Bedrock AgentCore, AWS's platform for running enterprise AI agents with tools, memory and access management, that they named AgentCorruption. According to the researchers, an attacker with nothing more than chat access to one publicly reachable agent could take over every AgentCore agent in the same AWS account and region, exposing private conversations, source code and stored credentials. Zenity says the problem was systemic and affected agents with built-in tools across multiple AWS accounts.

The entry point was the Instance Metadata Service, an internal AWS endpoint at 169.254.169.254 that hands out temporary credentials so instances and workloads can authenticate to AWS. Anyone who captures those credentials can impersonate the workload they belong to. An agent should not be able to reach that service, but Zenity says AgentCore lacked proper isolation. The team built a test agent on Strands, an open-source AWS framework that ships with a web tool, and asked it in plain language to query the metadata service and send the results to an external server. The agent complied. In their account of the work, the researchers describe the sandbox boundary they expected to fight as simply absent.

A single chat message in a customer support window was enough to make the agent transmit its own AWS credentials to an outside server. Those credentials worked from the researchers' own machine, outside the platform, so the agent was no longer needed to continue the attack. The metadata service also returned certificate and key material for an internal AWS service, plus a presigned URL for internal S3 storage that did not belong to the researchers' account. Removing the web tool would not have closed the hole, Zenity says, because the flaw sat in the platform; the team also completed the attack through a command-line tool.

What turned one compromised agent into a regional takeover was the breadth of AgentCore's default permissions. They were not scoped to the agent that received them but applied to every agent in the same account and region, with read, write and delete access sufficient for destructive operations. Using that access, the researchers ran an automated script that pulled the container images of all agents in the region and copied their source code. They could list every agent, download code packages within seconds and invoke each one. Those packages frequently contain forgotten passwords or API keys alongside source code, so the blast radius can extend past the agents themselves. In practice, this suggests an attacker could pivot from a public-facing customer service agent to an internal finance agent and reach its data.

The stolen access also let the researchers read private conversations between other users and any AgentCore agent in the region. For agents with long-term memory enabled, they could alter that memory to shape later behavior; their separate writing on memory poisoning describes planting instructions that caused agents to forward future conversations to an external destination, while users kept talking to an agent that appeared trustworthy. AWS advises keeping passwords and API keys out of agents and in secure storage, but Zenity says the default permissions undercut that advice by letting agents reach the stored credentials, including keys for services outside AWS.

Zenity says it reported the findings to AWS on December 25, 2025. AWS subsequently made IMDSv2 the default for new AgentCore deployments, a hardened version of the metadata service that the attack had used as its way in. The researchers also say AWS changed AgentCore's default execution role around August, so that it no longer permits agents to invoke other agents, read private conversations or retrieve credentials from AWS Secrets Manager, and that other permissions were restricted substantially. Zenity still recommends that companies define custom roles with narrower access, and lays out those recommendations in an analysis of the default role. Zenity sells a security platform for AI agents, a business interest worth noting when weighing its account of the severity and scope.

Zenity CTO Michael Bargury framed the underlying tension between cloud security and agent capability, saying cloud security is about segmentation and least-privilege access while AI agents need creative freedom to be useful. That trade-off applies to any company running agents in the cloud, and it sharpens when public-facing and internal agents share an environment, where one flaw can cross security boundaries for the whole system. A likely reading is that the fix so far reduces the default blast radius rather than removing the need for deliberate role design, since any agent that can be prompted in natural language remains a potential path to whatever it is allowed to touch.

The AgentCore case fits a pattern Zenity has documented elsewhere, in which an innocuous-looking input turns an agent against its own organization. Its AgentFlayer research described zero-click attacks that made Salesforce Einstein, Copilot Studio and Cursor redirect customer data or leak credentials, and its AgentForger work found that a tampered ChatGPT link was enough to create an autonomous agent in OpenAI's Workspace Agents with approval requirements disabled. OpenAI fixed that vulnerability within four days, according to the researchers, whereas AgentCore's broad default permissions persisted for months after the report. AWS has made AgentCore generally available to enterprises, and Amazon says its users include Sony and Ericsson.

Agent memory has drawn similar scrutiny. Google DeepMind lists long-term memory manipulation as its own attack class in a taxonomy of AI Agent Traps, finding that a few poisoned documents in a knowledge base can steer responses. The red-teaming study Agents of Chaos had researchers remotely controlling an OpenClaw agent through an externally editable document linked from its memory file, while another agent gave up unredacted bank details. OpenAI CEO Sam Altman has argued agents should get only the minimum access they need, a principle Zenity says AgentCore's default role violated.

Why it matters: Teams running agents on Amazon Bedrock AgentCore should check their execution roles rather than rely on platform defaults, because the reported flaws let one chat-accessible agent reach credentials and data belonging to every agent in the same account and region. The platform-level fixes AWS has shipped, IMDSv2 by default and a narrower default role, reduce the exposure for new deployments, but existing agents and custom setups may still carry the older broad permissions. Product teams that mix public-facing and internal agents in one account should treat that arrangement as a shared trust boundary and scope credentials per agent, an inference drawn from the reported behavior rather than a claim by the researchers or AWS. Anyone building on agent frameworks with tool access should expect prompt-driven credential theft and memory poisoning to remain live risks.