Glonce

Zenity says one prompt could hijack every Amazon Bedrock AgentCore agent in an account

securityThe Glonce editorsThe Decoder🔥71Glonce rating71Impact62Novelty60Relevance95Surprise62Players78Credibility75
Zenity says one prompt could hijack every Amazon Bedrock AgentCore agent in an account

Researchers at Zenity Labs say a single publicly accessible AI agent on Amazon Bedrock AgentCore was enough to take over every AgentCore agent in the same AWS account and region. AgentCore is AWS' platform for running enterprise AI agents with tools, memory, and access management. Zenity calls the chain of vulnerabilities "AgentCorruption." An attacker needed only chat access to one public agent, and the researchers say a single prompt exposed private conversations, source code, and stored credentials. According to Zenity, the problem was systemic and affected agents with built-in tools in multiple AWS accounts.

The entry point was the AWS Instance Metadata Service, reachable at the internal address 169.254.169.254, which hands out temporary credentials that let instances and workloads authenticate with AWS. Anyone who captures those credentials can impersonate the instance. An agent should not be able to reach that service, but AgentCore lacked proper isolation, according to Zenity's technical blog post. The researchers built a test agent with Strands, an open-source AWS framework that ships with a web tool. Asked in plain language to query the metadata service and send the results to an external server, the agent complied. "The sandbox boundary we were supposed to be fighting simply wasn't there," the researchers write.

The stolen credentials also worked on the researchers' own machine outside the platform, so the agent was no longer needed to continue the attack. The metadata service additionally exposed certificate and key material for an internal AWS service and a presigned URL for internal S3 storage that did not belong to the researchers' account. Zenity says removing the web tool would not have helped, because the flaw was in the platform itself; the researchers also ran the attack through a command-line tool.

The second half of the problem was permissions. AgentCore's default permissions were not limited to the agent receiving them. According to Zenity, they applied to every agent in the same account and region and granted read, write, and delete access, which allowed destructive operations. With them, the researchers could list every agent, download their code packages in seconds, and invoke each one. Those packages often hold forgotten passwords or API keys next to the source code. An attacker could, for example, move from a public customer service agent to an internal finance agent and reach its data. The researchers could also read all private conversations between users and agents.

For agents with long-term memory enabled, the researchers could alter that memory. In their post on memory poisoning, they describe planting instructions that made agents forward future conversations to an external destination, while users kept talking to a seemingly trusted agent and noticed nothing. AWS recommends keeping passwords and API keys apart from agents in secure storage, but according to Zenity's post on credential theft, the default permissions let agents access those stored credentials, including keys for services outside AWS.

Zenity says it reported the findings to AWS on December 25, 2025, after which AWS made IMDSv2, a more secure version of the metadata service, the default for new AgentCore deployments. According to Zenity's updated account, AWS also changed the default execution role around August. The updated role no longer lets agents invoke other agents, read private conversations, or retrieve credentials from AWS Secrets Manager. AWS significantly restricted other permissions as well, but the researchers still recommend that companies create custom roles with narrower access. The article summarizes the state of play as a partial fix.

Zenity CTO Michael Bargury sees a conflict between cloud security and what agents need to work. "Cloud security is about segmentation and least-privilege access. But AI agents need creative freedom to be useful," he said. Every company running agents in the cloud faces that tradeoff, he suggests, especially when public-facing and internal agents share an environment, where one vulnerability can compromise boundaries across the whole system.

The article places the findings in a pattern Zenity has documented before. In its AgentFlayer research, zero-click attacks made Salesforce Einstein, Copilot Studio, and Cursor redirect customer data or leak credentials. With AgentForger, a tampered ChatGPT link was enough to create an autonomous agent in OpenAI's Workspace Agents with approval requirements disabled. OpenAI fixed that within four days, while AgentCore's overly broad default permissions persisted for months after Zenity's report. AWS has made AgentCore available to all enterprises, and Amazon says its users include Sony and Ericsson. The article also cites Google DeepMind's "AI Agent Traps" taxonomy, which lists long-term memory manipulation as a separate attack class and finds that a few poisoned documents in a knowledge base can steer responses, and the red-teaming study "Agents of Chaos," in which researchers remotely controlled an OpenClaw agent through an externally editable document linked in its memory file.

Key facts

  • Zenity Labs says chat access to one public Amazon Bedrock AgentCore agent, via a single prompt, let it take over every AgentCore agent in the same AWS account and region; the chain is named "AgentCorruption."
  • A test agent built with Strands, asked in plain language, queried the metadata service at 169.254.169.254 and sent the credentials to an external server; the credentials then worked on the researchers' own machine.
  • Broad default permissions let the researchers list all agents, download their code packages, invoke them, read private conversations, and alter long-term memory so agents forwarded future conversations elsewhere.
  • Zenity reported the findings on December 25, 2025; AWS made IMDSv2 the default for new deployments and later tightened the default execution role, but the fix is only partial and Zenity still advises custom, narrower roles.
  • Zenity also sells a security platform for AI agents, which the article notes gives it a business interest in reporting such flaws.

Why it matters

AgentCore is AWS' platform for running enterprise AI agents, and the reported flaw broke the boundary between agents that should have been separate. One public-facing agent, such as a customer service bot, became a way into internal agents, for example a finance agent, along with their data. The case also shows how an agent's own helpfulness is the weakness: the agent followed a plain-language request to fetch its own credentials. Zenity frames this as part of a broader pattern, citing its earlier AgentFlayer and AgentForger work, and notes that OpenAI fixed AgentForger within four days while AgentCore's broad default permissions persisted for months.

Who it affects

Companies running agents on Bedrock AgentCore, especially those that keep public-facing and internal agents in the same AWS account and region. According to Zenity, the problem was systemic and affected agents with built-in tools in multiple AWS accounts. The exposure reached the users of those agents too, since the researchers could read all private conversations. AWS has made AgentCore available to all enterprises, and Amazon says its users include Sony and Ericsson.

How to use it

The practical advice comes from the researchers. They still recommend that companies create custom execution roles with narrower access and assign them to their agents manually, rather than relying on the default role. AWS' own guidance, as the article reports it, is to keep passwords and API keys separate from agents in secure storage; Zenity says the old default permissions undermined that. New AgentCore deployments now use IMDSv2 by default. Zenity's technical posts on the metadata attack, memory poisoning, credential theft, and the default role carry the detail for teams that want to audit their own setup.

How solid is it

The findings come from Zenity's own research and technical blog posts, and the article relays them; AWS's position is conveyed only through Zenity's account, and no AWS statement is quoted. The article itself notes that Zenity sells a security platform for AI agents and so has a business interest in this kind of report. Some details are approximate: the default-role change is dated only to "around August." The report that AWS made IMDSv2 the default and tightened the default role is also Zenity's, and the article describes the fix as partial.

Risks and caveats

AWS has fixed the issue only partially. The IMDSv2 default applies to new AgentCore deployments, and the article does not say whether the fix for existing deployments is complete. Even after the role change, the researchers still advise custom roles with narrower access. The article gives no CVE identifiers or severity scores, does not report exploitation in the wild by real attackers, and does not say how many accounts or customers were affected beyond "multiple AWS accounts." The attack also depends on an attacker reaching an agent with chat access, and on memory poisoning, users would not notice anything wrong while conversations were forwarded.

“Cloud security is about segmentation and least-privilege access. But AI agents need creative freedom to be useful”

— Michael Bargury, Zenity CTO