Zuckerberg Called Muse Ready Despite Safety Flags, NYT Reports

Security firm Zenity Labs disclosed AgentCorruption on October 8, 2026: a chain of flaws in Amazon Bedrock AgentCore that let researchers send one prompt to one public-facing AI agent and take over every AgentCore agent in the same AWS account and region. From there they read private conversations, downloaded source code, pulled API keys and OAuth tokens from AWS Secrets Manager, and planted memories that made agents secretly forward future conversations. AWS has since tightened the defaults.

How does one prompt take over everything?

Three weaknesses chained together. In plain terms:

• Step 1, the key under the mat. The researchers asked a public agent that could make web requests to visit the AWS Instance Metadata Service, the internal address that hands out temporary cloud credentials. AgentCore let it, and the agent fetched the credentials of the machine it ran on.
• Step 2, a master key. Those credentials belonged to a default role whose permissions covered every AgentCore agent in the account and region, not just the one agent. So one stolen key opened all the doors.
• Step 3, a permanent spy. AgentCore agents keep long-term memory. The researchers wrote malicious memories telling agents to send future conversations to an outside address. Users would keep chatting with what looked like a normal company agent while it quietly leaked everything.

Zenity’s example makes the stakes concrete: an attacker comes in through an internet-facing customer service agent and moves sideways to an internal finance agent in the same region, using its data, tools and credentials.

Is it fixed?

Largely. Zenity reported the findings to AWS on December 25, 2025. AWS made IMDSv2, a hardened version of the metadata service, the default for AgentCore, and cut the default role’s permissions so it can no longer invoke other agents, read private conversations or reach Secrets Manager. Zenity confirmed the changes in testing and thanked AWS for its cooperation.

The catch is the word "default." New deployments get the safer settings. Agents built earlier, or on custom roles copied from the old defaults, may still carry the broad permissions. If you run AgentCore, check every agent’s execution role and confirm IMDSv2 is enforced, rather than assuming the fix reached you.

Why does this matter beyond AWS?

Because the root cause is a design tension every cloud agent platform has. Zenity CTO Michael Bargury put it simply: cloud security is about giving each workload the least access possible, while agents need room to be useful. "Mixing the two creates an inherent conflict," he said. Companies routinely run customer-facing and internal agents side by side, and one shared role or one reachable credentials endpoint collapses the wall between them.

It is the same lesson as GitSpawn and PixelLeak: the agent does something ordinary, and the danger lives in what that ordinary action can reach. Runtime sandboxing of the kind in NVIDIA’s agent safety platform helps with the first two steps. Nothing short of treating memory as untrusted input stops the third.

What should teams running cloud agents do?

• Give each agent its own role with only the permissions it needs
• Block agents from reaching the metadata service unless they truly require it, and enforce IMDSv2
• Keep public-facing and internal agents in separate accounts or regions
• Audit agent memory regularly for instructions nobody wrote on purpose

Read Zenity’s disclosure.