One prompt was enough to hijack every AI agent in an AWS account

Companies are racing to put AI agents in front of customers. A support bot answers questions on the website, an internal agent books invoices, another one reads the code base and suggests fixes. Very often all of them live side by side on the same cloud platform. New research from the security firm Zenity Labs shows why that neighborhood can be dangerous. According to the researchers, a single chat message sent to one public facing agent on Amazon Bedrock AgentCore was enough to take control of every AgentCore agent in the same AWS account and region.

Zenity calls the chain of problems AgentCorruption. The findings were published in detail this week and reported by The Decoder on 8 October 2026, with further coverage from The Next Web. AWS pushes back hard on the framing and says the research "inaccurately paints expected and documented behavior as a vulnerability." Both sides agree on one thing: the issue has been mitigated, and it never crossed the boundary between different AWS accounts.

This article explains what AgentCore is, how the attack worked step by step, what an attacker could reach, what AWS changed, why the two sides disagree, and what teams that run agents in the cloud should take away from it.

What Bedrock AgentCore is

Bedrock AgentCore is the platform AWS offers for running enterprise AI agents in production. It handles the plumbing that every serious agent needs: a runtime that hosts the agent, tools such as web browsing or code execution, short and long term memory, and identity and access management so the agent can call other AWS services. AWS made AgentCore available to all enterprise customers, and Amazon names companies such as Sony and Ericsson among its users.

The appeal is obvious. Instead of building a secure agent stack from scratch, a team writes the agent logic, often with Strands, an open source agent framework from AWS, and lets the platform run it. That convenience is also the weak point Zenity went after. When a platform hands every agent a set of default permissions, those defaults decide how much damage a single compromised agent can do.

The attack, step by step

Step one was a normal chat. The researchers built a test agent with Strands and its bundled web tool, then exposed it like a customer support bot. They did not need any special exploit code. They simply asked the agent, in plain language, to query an internal address and send the result to an outside server.

Step two was the leak. Inside AWS, the Instance Metadata Service at the internal address 169.254.169.254 hands out temporary credentials so that a workload can authenticate with other AWS services. An AI agent should not be able to reach that service on behalf of a stranger. According to Zenity, AgentCore lacked proper isolation, so the agent followed the instructions and returned its full temporary credentials, including access keys and session token. "The sandbox boundary we were supposed to be fighting simply wasn't there," the researchers wrote.

Step three was taking the keys outside. The stolen credentials worked on the researchers' own machine, outside the AgentCore platform. From that moment they no longer needed to talk to the agent at all. The metadata service also exposed certificate and key material for an internal AWS service and a presigned link to internal S3 storage that did not belong to the researchers' account.

Zenity stresses that removing the web tool would not have helped. The weakness sat in the platform, not in one tool, and the team repeated the attack through a command line tool as well.

Step four was spreading. This is the part that turns a bad bug into a serious one. AgentCore's default permissions were not limited to the single agent that received them. According to Zenity, they applied to every agent in the same account and region and included read, write and delete rights. With those credentials the researchers could list every agent, download their code packages in seconds and invoke each of them. An automated script pulled the container images of all agents in the region and copied their source code.

Step five was persistence. For agents with long term memory enabled, the researchers could rewrite that memory. In a separate write up on memory poisoning, Zenity describes planting instructions that made agents forward future conversations to an outside destination. Users would keep chatting with what looked like a trusted agent, while their messages quietly leaked.

What an attacker could reach

The list of exposed assets is what makes this case uncomfortable for anyone running agents in production:

• Private conversations between other users and any AgentCore agent in the region.
• Source code of every agent, including the code packages that often contain forgotten passwords or API keys.
• Stored secrets. AWS recommends keeping keys in secure storage such as Secrets Manager instead of inside the agent. According to Zenity, the default permissions let agents read those stored credentials anyway, including keys for services outside AWS.
• Other agents' behavior, by invoking them directly or by poisoning their memory.

The practical risk is lateral movement. An attacker who starts at a harmless looking customer service bot could jump to an internal finance agent and read its data. The public agent becomes the front door to everything else that shares its account and region.

What AWS changed, and how long it took

Zenity says it reported the AgentCore findings to AWS on 25 December 2025. After that, AWS made IMDSv2 the default for new AgentCore deployments. IMDSv2 is the hardened version of the metadata service and makes it much harder to pull credentials with a simple request, which was exactly the entry point in this attack.

According to Zenity's updated account, AWS also changed AgentCore's default execution role around August 2026. The new role no longer lets agents invoke other agents, read private conversations or fetch credentials from Secrets Manager, and AWS significantly narrowed other permissions too.

That is a real improvement, but the timing is part of the story. By Zenity's account, the overly broad default role stayed in place for months after the report. For comparison, Zenity says OpenAI fixed a separate agent flaw it reported, called AgentForger, within four days.

Two very different readings

The two companies describe the same facts in very different words.

Zenity's statement thanks AWS for working together to fix "the misconfigurations and insecure defaults" and repeats that the proof of concept compromised all AgentCore agents in the same region and account through one prompt to one public agent. It also makes clear that the issue did not cross the account boundary and has been fully mitigated.

AWS says the research describes expected and documented behavior. In its view, an agent can only reach resources in another AWS account if a developer explicitly grants permissions on both the agent's execution role and the target resource, and customers should give execution roles only the permissions their agents need.

Both statements can be true at once. The attack stayed inside one account, which is what AWS emphasizes. But inside that account, the defaults that many teams never touch gave one public agent the keys to all the others, which is what Zenity emphasizes. Defaults matter because most people never change them.

There is one more piece of context worth knowing. Zenity sells a security platform for AI agents, so it has a business interest in finding and publicizing exactly this kind of weakness. That does not make the findings wrong, and the technical details were confirmed by AWS's own fixes, but readers should keep it in mind.

Part of a bigger pattern

AgentCorruption is not an isolated case. Zenity has documented a series of attacks where a harmless looking input turns an agent against its own organization. In its AgentFlayer research, zero click attacks made Salesforce Einstein, Microsoft 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 steps switched off.

Memory is becoming its own attack surface. Google DeepMind lists long term memory manipulation as a separate class in its taxonomy of AI agent traps and found that a few poisoned documents in a knowledge base can steer answers. In the red teaming study "Agents of Chaos," researchers controlled an agent remotely through an editable document linked in its memory file.

Zenity CTO Michael Bargury sums up the tension: "Cloud security is about segmentation and least privilege access. But AI agents need creative freedom to be useful." Classic cloud workloads do a fixed job. Agents are built to follow instructions they have never seen before, and that is exactly what an attacker exploits.

What teams running agents should do now

The good news is that the fixes are mostly boring, which is how good security usually looks:

• Write your own execution role. Do not rely on the platform default. Give each agent only the actions and resources it really needs. Zenity still recommends custom, narrow roles even after the AWS changes.
• Separate public and internal agents. A customer facing bot and a finance agent should not share an account and region if you can avoid it. Separate accounts create a hard boundary that AWS itself says the attack could not cross.
• Enforce IMDSv2 everywhere, also on older deployments created before the new default.
• Keep secrets out of code packages, and scope access to secret stores per agent.
• Treat agent memory as data that can be attacked. Review what gets written to long term memory and who can change it.
• Log and alert on agent to agent calls, bulk downloads of code packages and unusual metadata requests.

The bottom line

AgentCorruption is a reminder that an AI agent is not only a chatbot. It is a piece of software with credentials, and anyone who can talk to it can try to talk it into using them. Zenity showed that, on AgentCore's old defaults, one friendly sounding message could open every agent in an account and region. AWS has closed the gaps it accepts as gaps and says the rest is documented behavior. For everyone building with agents, the lesson is the same either way: the permissions you never configured are the ones an attacker will use.

Sources: The Decoder report with AWS and Zenity statements, The Next Web coverage, and Zenity Labs' technical write ups linked from those reports.