A single chat message was enough for a group of security researchers to take control of all artificial intelligence agents deployed within the same Amazon Web Services account and region. The finding, revealed by the firm Zenity Labs, places the security of platforms used by companies to build autonomous AI agents at the center of the debate.
The discovery is particularly relevant because AWS has opened its Bedrock AgentCore service to all companies, and Amazon counts companies like Sony and Ericsson among its clients. If a customer service agent, exposed to the public, can become a gateway to internal finance systems or sensitive data, the risk affects any organization that has adopted this technology.
How an agent surrendered its own credentials
The flaw, which Zenity dubbed AgentCorruption, relied on the Instance Metadata Service that AWS maintains at the internal address 169.254.169.254. That service provides temporary credentials to workloads so they can authenticate, and anyone who manages to capture them can impersonate the original instance.
According to Zenity's technical report, AgentCore lacked the necessary isolation to prevent an agent from reaching that service. The researchers set up a test agent with Strands, an open-source AWS framework that includes a web browsing tool, and asked it in natural language to query the metadata service and send the result to an external server.
The agent obeyed without resistance. The researchers described that the isolation boundary they expected to find simply did not exist.
Valid credentials outside the platform
The metadata service returned the agent's full temporary credentials, including keys and a session token. By testing them from their own equipment, outside of AWS, the researchers confirmed they remained valid. From that moment on, they no longer needed to interact with the agent to continue the attack.
The same service also exposed certificate material and keys from an internal AWS service, as well as a pre-signed S3 storage URL that did not belong to the researchers' account. According to Zenity, removing the agent's web tool would not have solved the problem, because the defect resided in the platform itself. In fact, the attack also worked through a command-line tool.
Default permissions that reached the entire region
The element that turned a specific flaw into a massive breach was AgentCore's default permissions. According to the report, those permissions were not limited to the agent that received them, but applied to all agents in the same account and region, with read, write, and delete capabilities that allowed for destructive operations.
With that level of access, the researchers listed all available agents, downloaded their code packages in a matter of seconds, and invoked each one of them. An automated script extracted the container images of all agents in the region and copied their source code, material that often contains passwords or API keys forgotten by developers.
From customer service to financial data
The risk scenario described by Zenity is concrete: an attacker could start from a public customer service agent and jump to an internal finance agent, accessing its information. The researchers also read private conversations between users and agents across the affected region.
In agents with long-term memory enabled, they also managed to alter that memory to condition their future behavior. Zenity detailed in another post how they planted instructions that caused agents to forward subsequent conversations to an external destination, without users noticing anything strange while continuing to converse with an agent that seemed trustworthy.
AWS recommends that its customers store passwords and API keys outside of agents, in secure storage. But according to Zenity, AgentCore's default permissions nullified that protection by allowing agents to access those credentials, including keys for services outside of AWS.
AWS’s response
Zenity claims to have communicated the findings to AWS on December 25, 2025. Following the notice, AWS made IMDSv2, a more secure version of the metadata service, the default option for new AgentCore deployments.
According to Zenity's updated account, around August, AWS also modified the default execution role. The new role no longer allows agents to invoke other agents, read private conversations, or retrieve credentials stored in AWS Secrets Manager. AWS also restricted other permissions, although researchers still recommend that each company create its own roles with more limited access.
It should be noted that Zenity markets a security platform for AI agents, so it has a direct commercial interest in these types of findings.
The firm's CTO, Michael Bargury, summarizes the underlying conflict: cloud security is based on segmentation and least privilege, while AI agents need freedom of action to be useful.
A pattern already known on other platforms
The AgentCore findings follow a pattern that Zenity had already documented in other environments: an innocuous-looking input ends up turning the agent against its own organization. In their previous research dubbed AgentFlayer, zero-click attacks caused Salesforce Einstein, Copilot Studio, and Cursor to divert customer data or leak credentials.
In another case, called AgentForger, a manipulated link in ChatGPT was enough to create an autonomous agent in OpenAI's Workspace Agents with approval requirements disabled. OpenAI fixed that flaw in four days, a much shorter period than the months it took for the excessive AgentCore permissions to be resolved after Zenity's notice.
Regarding the risk of manipulating agent memory, Google DeepMind includes this technique as a category of its own within its vulnerability taxonomy for AI agents. According to that framework, a few poisoned documents in a knowledge base can be enough to divert a system's responses.
What to check if you use agents in AgentCore
Zenity's findings leave a series of practical checks for companies that already have agents deployed in Bedrock AgentCore.
It is advisable to verify which execution role existing agents use, as those created before the AWS changes may retain permissions that allow invoking other agents or reading others' conversations.
It is also advisable to assign each agent its own role with the minimum necessary permissions, rather than relying on the platform's default role, just as the researchers explicitly recommend.
Reviewing code packages for forgotten passwords or API keys is another key step, especially if those packages could have been downloaded during the period when credentials were exposed.
Separating public-facing agents from those that manage internal information reduces the risk of a breach in the former reaching the latter, especially if they share an account and region. Finally, it is advisable to confirm that new deployments use IMDSv2 and monitor any agent with web tools capable of querying internal addresses.
What it implies for companies
Although AWS has tightened AgentCore's defaults, the role change applies only to new deployments, so existing agents may need a manual review. Researchers insist that reliable defense involves creating one's own limited roles, without relying on the platform's default configuration.
For any company with public-facing agents, the recommendation is to treat every received message as a potential hostile instruction. The AgentCorruption case demonstrates that a single conversation was enough to expose private conversations, source code, and credentials for an entire AWS region.
Frequently asked questions
What is AgentCorruption?
It is the name the security firm Zenity Labs gave to a vulnerability detected in Amazon Bedrock AgentCore, which allowed taking control of all AI agents in the same AWS account and region from a single message sent to an agent.
What data was exposed?
The researchers accessed private conversations between users and agents, source code from agent packages, and temporary credentials, including keys that worked outside the AWS platform.
Has AWS already fixed the flaw?
AWS changed IMDSv2 to the default option in new deployments and modified the default execution role around August to prevent agents from invoking other agents or reading private conversations, but agents created before these changes may remain exposed if not manually reviewed.
Which companies use AWS Bedrock AgentCore?
AWS has opened this platform to all companies and cites companies like Sony and Ericsson among its clients.
What should companies with agents in AgentCore do?
Zenity recommends creating custom execution roles with minimum permissions for each agent, reviewing code for forgotten credentials, separating public from internal agents, and confirming that deployments use IMDSv2.
Does Zenity Labs have any commercial interest in this finding?
Yes, Zenity sells a security platform aimed at artificial intelligence agents, so it has a commercial interest related to this type of vulnerability research.
