One Prompt Opened Every Door
in the Building.

What actually happened

The chain had two links, and both matter.

Link one: the agent fetched its own keys. Cloud servers run an internal metadata service — AWS calls it IMDS — that hands out temporary credentials to software on the machine. Zenity tricked a public agent, via prompt injection, into requesting that address. The agent returned the temporary credentials for its default execution role. In web-security terms, this is a server-side request forgery: the server was fooled into making a request on the attacker’s behalf.

Link two: the keys opened every door. Those credentials belonged to the agent’s default execution role — and that role wasn’t limited to the one agent. Its permissions extended across AgentCore resources in the account and region. With them, the researchers listed other agents, invoked internal ones they were never meant to reach, read private conversations, and extracted long-term memories.

AWS has since patched it. Since February 14, 2026, newly deployed agents use IMDSv2, which requires a session token for metadata requests — blocking the simple forged request Zenity used. And by September 29, AWS had stripped the default role of the permissions that reached other agents, private conversations, and Secrets Manager. Zenity reported no evidence of in-the-wild exploitation.

AWS, for its part, disputes the vulnerability framing: the company says an agent accessing its own execution-role credentials through the metadata service is documented and expected behavior, recommends least privilege, and notes that cross-account access needs explicit authorization on both sides. That distinction doesn’t erase the demonstrated blast radius of the original default permissions.

Now here’s the part that should bother you more than the prompt injection.

They isolated the bodies. Not the permissions.

Each AgentCore agent runs in its own Firecracker microVM — its own little virtual machine. That is genuine, serious compute isolation. The kind of engineering you brag about.

But the permissions weren’t isolated. The agent’s execution role wasn’t limited to that agent. Its permissions extended across AgentCore resources in the account and region. The attacker didn’t need to escape the VM. The stolen credentials already reached beyond it.

Most of the coverage will file this under “prompt injection strikes again.” That’s the wrong lesson — and it’s the comfortable one, because it locates the failure in a malicious input that defenders can theoretically filter.

The real failure was the default. The platform’s default permissions allowed credentials stolen from one agent to reach other agents that should have remained off-limits. Prompt injection was just the key that turned in the lock. The lock itself was built wrong.

The old assumption that died here: if IAM is set up, the cloud is safe for agents. IAM answered “is this credential valid?” Nobody asked the harder question: which agent is holding it, and is this action within its authority?

This is what standing authority looks like

There’s a distinction worth tattooing on every agent platform: a standing grant is not situated authority.

A standing grant says: this credential may touch these resources. It’s static, issued once, and it travels with whoever holds it — employee, contractor, or a chatbot that got confused by a prompt.

Situated authority asks something different, every single time: this agent, here, now, for this purpose — may it? The grant is the floor. The situation is the ceiling. AgentCorruption happened in the gap between the two.

Here’s the uncomfortable extension. AWS fixed the default. But the mental model that produced the default — fleet-wide trust with per-agent capability — is everywhere. Zenity is already investigating other cloud platforms for the same pattern. And beyond the cloud: every agent framework that issues one service account, one API key, one “agent role” to a whole swarm is recreating this building. One key. Many rooms. Many agents.

The question to ask your own stack

When your team demos its agent fleet, ask the unsexy question nobody put on the roadmap slide: If one of our agents gets tricked tomorrow, what exactly does the attacker’s blast radius look like — one agent’s permissions, or everyone’s?

If the honest answer is “everyone’s,” you don’t have per-agent authority — you have a fleet-wide blast radius.

That’s the problem we’re working on at Intent Checkpoint: making authorization specific to the agent, action, and purpose — and ensuring that these boundaries are enforced outside the agent’s reasoning loop. Because a permission that reaches beyond its intended task is not made safe simply by putting an agent in a separate VM.

One prompt opened every door in the building. The fix isn’t a better lock on the front door. And “its own badge” has to mean more than a separate name: it means permissions scoped to the resources and operations that agent is actually authorized for.