One chat message to a public AWS agent exposed every AgentCore agent in the same region. Keep your public bot away from your back office

A customer support chatbot became the key to a finance agent's data. The bug was in the platform, but the blast radius came from how things were grouped.

What happened

Security firm Zenity Labs published research it calls "AgentCorruption" on Amazon Bedrock AgentCore, AWS's platform for running enterprise AI agents. With chat access to a single public agent, the researchers asked it in plain language to query AWS's internal metadata service and send the result to an external server. It did, handing over its temporary AWS credentials. "The sandbox boundary we were supposed to be fighting simply wasn't there," they wrote.

The bigger problem was the default permissions. According to Zenity, they applied to every agent in the same account and region, with read, write and delete access. The researchers could list all agents, download their code packages, invoke them, read private conversations and, for agents with long-term memory, alter that memory so agents forwarded future conversations elsewhere. The Decoder notes an attacker could move from a public customer service agent to an internal finance agent.

Zenity says it reported the issues on December 25, 2025. AWS made IMDSv2 the default for new deployments and, around August, narrowed the default execution role. The researchers still recommend custom roles with narrower access. Zenity sells an agent security platform, so it has a business interest here.

My take

You probably do not run AgentCore. The pattern still applies to you. I often see a website chatbot, an internal ops agent and a reporting workflow all sharing one API key, one CRM admin token or one cloud project.

When those share credentials, your weakest public entry point sets the security level for everything. Practical fixes:

1. Put public facing bots in a separate account or project from internal agents.
2. Give each agent its own credential with only the permissions its job needs.
3. Keep keys out of code and config files that ship with the agent.
4. Treat agent memory as data an attacker can write to, and review what it stores.
5. If you deployed agents before a platform changed its defaults, check which role they actually run under.