Zenity Says One Prompt Took Over Every AWS AgentCore Agent in an Account and Region — Scope Each AI Agent's Permissions Like an Employee's

Zenity Says One Prompt Took Over Every AWS AgentCore Agent in an Account and Region — Scope Each AI Agent's Permissions Like an Employee's

2026-10-10

The takeaway: A customer-facing AI agent is only as safe as the permissions it carries. On October 8, 2026, security firm Zenity Labs said that a single chat message to one public AWS agent could unlock every other agent in the same account and region, because they all shared one overly broad default role. AWS has since tightened that default, but the lesson applies to any agent you run: give each one only the access its job needs.

What happened

Amazon Bedrock AgentCore is AWS’s managed service for building and running AI agents. On October 8, 2026, Zenity Labs, an AI agent security vendor, disclosed a chain of flaws it calls “AgentCorruption” (Zenity press release, Oct. 8, 2026). The research was presented at the SecTor 2026 conference in Toronto (The Next Web, Oct. 8, 2026).

As Zenity tells it, the chain had two parts:

  1. The agent could reach its machine’s credential service. Cloud servers have an internal “metadata service” (AWS calls it IMDS) that hands out temporary login credentials to software running on that machine. Zenity’s prompt asked a public support agent to fetch that address, and the agent returned the credentials (Zenity press release, Oct. 8, 2026). This is a form of server-side request forgery (SSRF): tricking a server into making a request on the attacker’s behalf (The Register, Oct. 9, 2026).
  2. Those credentials belonged to a role that covered every agent. The default AgentCore role was scoped to all AgentCore resources in the account and region, not to the single agent (The Register, Oct. 9, 2026).

With that role, Zenity says it could invoke internal agents it was never meant to reach, read private conversations, pull secrets from AWS Secrets Manager, and plant “memories” that persistently changed agent behavior (Zenity Labs blog, Oct. 8, 2026). The Next Web adds that the researchers downloaded each agent’s container image and source code (The Next Web, Oct. 8, 2026).

The fix took nine months

Zenity’s published timeline (Zenity Labs blog, Oct. 8, 2026):

  • December 25, 2025: Zenity reports the metadata-service access to AWS.
  • January 12, 2026: Zenity reports the overprivileged default role.
  • February 14, 2026: AgentCore switches to IMDSv2 only for newly deployed agents (per AWS’s reply to Zenity). IMDSv2 requires a session token for each request, which blocks simple forged requests.
  • April 12, 2026: AWS closes the first report as “informative.”
  • June 22, 2026: Zenity finds the default role unchanged.
  • September 29, 2026: Zenity finds AWS has removed the permissions to invoke other agents, read conversations and access Secrets Manager.

The Register reported Zenity’s timeline (The Register, Oct. 9, 2026), and The Next Web noted the disclosure includes no CVE identifier (The Next Web, Oct. 8, 2026). AWS calls the behavior “documented and expected” (Zenity Labs blog, Oct. 8, 2026), and The Register reported that Amazon says Zenity’s research “misrepresents documented behavior as a vulnerability” (The Register, Oct. 9, 2026).

Important: the IMDSv2 change applied to newly deployed agents, but since June 30, 2026, AgentCore runtimes without MMDSv2 enabled can’t be invoked, per AWS’s runtime documentation (AWS AgentCore Runtime security best practices). If you deployed AgentCore agents before February 14, 2026, or customized their roles, don’t assume the new defaults reached you.

Why this matters beyond AWS

AWS’s own documentation states the core risk plainly: “any code or actor running inside the VM can access these credentials by calling the metadata endpoint” (AWS AgentCore credentials documentation). An AI agent that can browse, run code or make web requests can be talked into doing things. The question is how much damage it can do once it is.

The same pattern shows up wherever a business wires an agent into tools with a shared API key or an admin account. The blast radius is set by the credentials, not by the prompt.

What to check this week

If you run agents on AWS AgentCore

For any AI agent, on any platform

  • Separate public agents from internal ones. A chatbot on your website should not share credentials with the agent that reads your finance data.
  • Keep secrets out of the agent’s reach unless the task truly requires them, and rotate any that were exposed.
  • Review agent memory and logs for instructions you didn’t put there.
  • Ask vendors one question: “If this agent is tricked, what can its credentials touch?”

Soft next step

Zenity says AgentCorruption is patched, but the design lesson isn’t AWS-specific. Treat every AI agent like a new hire: its own account, only the access its job needs, and someone watching what it does. If you’d like a second set of eyes on how your agents and cloud permissions are set up, Yellow Coop’s fractional CTO and AI teams can help you map the blast radius before someone else does.

See cloud and security work in our track record, including the Cloud, Security & Delivery Turnaround and Zero Trust Security Program case studies; see who owns agent security; or start at contact.

Internal links: Secure, What We Do, Innovate, How We Engage, CIO vs CTO vs CISO, Track Record, Cloud, Security & Delivery Turnaround, Zero Trust Security Program, Insights.

Sources