One public agent, too much access: the AgentCore lesson

A chatbot’s instructions can say “do not reveal secrets” all day. If the workload behind it can fetch credentials and those credentials can reach other workloads, the real boundary is somewhere else. That is the point of Zenity Labs’ AgentCorruption research, reported by THE DECODER on 8 October and updated on 9 October.

The timing matters. Zenity says it notified AWS on 25 December 2025. This is new coverage of older findings and subsequent fixes, not evidence that every AgentCore deployment is currently exposed in the same way. The reported reach was within one AWS account and region, not across AWS customers.

How the reported chain worked

Zenity built a test agent with a web tool and gave it a plain-language instruction to query an internal metadata endpoint and send the result out. According to the researchers, the agent complied and exposed temporary AWS credentials. They say a command-line route also worked, so simply removing the web tool was not the whole answer.

With those credentials, the team reported permissions broad enough to list and invoke other AgentCore agents in that account and region, read private conversations, retrieve code packages and alter long-term agent memory. A public support bot could therefore become a bridge into an internal agent. The worry is not just a bad answer in one chat; it is a workload identity that has more authority than that chat should ever need.

The account comes from Zenity’s research as described by THE DECODER. I have not reproduced the attack, and Zenity sells agent-security products. The specific exploit path and scope should be read as reported findings, not as a fresh audit of AWS today.

What AWS changed

THE DECODER reports that AWS made IMDSv2 the default for new AgentCore deployments after the disclosure. Zenity also says AWS narrowed the default execution role around August 2026, removing default access to invoke other agents, read their private conversations and fetch credentials from Secrets Manager, among other restrictions. Existing deployments and custom roles need their own review; a safer default does not prove that an individual account is correctly configured.

The check worth doing in your own stack

Map each public-facing agent to its actual workload identity and the APIs that identity can call. Check whether it can reach metadata or internal services, read secrets, invoke sibling agents, access their logs or mutate shared memory. Grant each agent a narrowly scoped role and segment public workloads from internal ones. Test those boundaries with realistic prompts and tool calls, then examine the cloud audit trail for what was actually attempted.

Prompt rules still matter for behaviour, but they are not a substitute for network and permission controls. The practical question is simple: if someone persuades your least-trusted agent to use every capability it has, what else can that identity touch?