One Prompt Took Over Every Agent in an AWS Account: Zenity Discloses AgentCorruption

On October 8, 2026, at the SecTor conference in Toronto, AI agent security firm Zenity Labs dropped a bombshell: with a single prompt, its researchers took over every Amazon Bedrock AgentCore agent in the same AWS account and region — including internal, sensitive agents they were never authorized to touch. The vulnerability chain, dubbed AgentCorruption, turns prompt injection — something that sounds like a chat-box parlor trick — into a full infrastructure-level takeover: private conversations, long-term memories, container source code, API keys, and OAuth tokens, all harvested. Worse, attackers could implant malicious instructions into an agent's "memory," keeping the hijack alive long after the initial attack.

The part that should worry vibe developers most: it wasn't the model that failed — it was the defaults. Zenity's researchers found no clever model jailbreak. They found that AWS's default IAM execution role for AgentCore was wildly overprivileged, and that the underlying infrastructure let an agent reach the cloud metadata service. In other words, the most dangerous link in this chain was the default role you accept when you click "next" in the console.

How one prompt became an "account-wide passport"

The attack starts unsettlingly simply. Researchers sent a prompt to a public-facing AgentCore agent, instructing it to access the AWS Instance Metadata Service (IMDS) — 169.254.169.254, the address every cloud machine knows, which hands temporary credentials to workloads running on that machine. This is a classic server-side request forgery (SSRF): tricking a server into making a request on your behalf that it was always able to make.

Normally the story should end there: the agent would receive a tightly scoped set of credentials belonging to itself alone. But AgentCore's default execution role wasn't configured that way. Zenity found the role's permissions were not limited to the single agent — they covered AgentCore resources across the entire account and region: bedrock-agentcore:InvokeAgentRuntime (invoke any agent), bedrock-agentcore:ListEvents (read events and conversations), cross-agent memory write permissions, bedrock-agentcore:GetResourceApiKey, and secretsmanager:GetSecretValue (read secrets from Secrets Manager).

The chain reaction that followed:

1. Discover and invoke all agents: researchers enumerated every AgentCore agent in the same account and region and invoked them one by one — including internal sensitive agents they had no right to access. Picture it: your public customer-service agent becomes the stepping stone to your finance agent.
2. Read all private conversations and long-term memories: chat histories and persistent memories across agents, users, and sessions, all exposed. The more an agent remembers, the bigger the leak surface — the flip side of "memory" as a capability.
3. Download container images, read full source code: pulling each agent's container image from ECR laid the source code bare. For closed-source commercial agents, that's being stripped naked.
4. Harvest credentials: API keys and OAuth tokens from Secrets Manager, plus credentials in environment variables. These weren't just AWS keys — many were credentials agents used to connect to enterprise systems and third-party services, so the blast radius spilled beyond AWS itself.
5. Implant malicious memories for persistence: the nastiest step. Researchers abused the agents' memory functionality to plant long-lived malicious instructions, quietly redirecting the agent's future conversations to an attacker-controlled destination. Users kept seeing the same trusted enterprise agent, unaware it was now working for someone else.

The blast radius is a property of the policy document, not the model

AgentCorruption deserves its own article rather than a line in a weekly security roundup because it exposes a truth many vibe developers haven't internalized: when you deploy an agent to the cloud, what determines how much damage it can do isn't how smart the model is — it's what you (or the defaults) wrote into its IAM role.

Agent security discussions have centered on the model layer for years: prompt injection, jailbreaks, guardrails, output filtering. All important — but in the AgentCorruption attack path, the model behaved "perfectly normally." It just obediently executed tool calls. What failed was the identity and access layer: an overprivileged default role, a reachable IMDS, cross-agent-writable memory. Zenity CTO Michael Bargury put it sharply in the disclosure statement: "Cloud security is all about segmentation and least-privilege access. AI agents, however, need their creative space to be useful." That tension is exactly the soil AgentCorruption grew in.

For vibe developers, that judgment translates directly into action: the next time you configure an execution role for an agent in the AWS console (or any cloud), "copy the default role so the demo runs" is itself planting a landmine for your future self. Between "the demo runs" and "it's safe for production" often lies just a few lines of JSON in a role policy.

AWS called it "expected behavior": reading the dispute

There's a telling subplot to this disclosure: AWS's response. According to The Register's October 9 coverage, AWS initially characterized Zenity's report as "documented behavior" — agents were always able to fetch their own execution role's credentials through the metadata service, and developers should follow least privilege on their own. The Register's reporter noted dryly that this didn't match the scenario Zenity described — Zenity never demonstrated "an agent fetching its own credentials," but "a default role so broad it could take over the whole account."

The timeline speaks for itself. Zenity responsibly disclosed to AWS on December 25, 2025; on February 14, 2026, AWS made IMDSv2 the default for new AgentCore deployments (closing the smoothest SSRF path to credentials); on April 12 AWS called the report "informative" and closed the ticket; but on June 22 Zenity's re-check found the default role's excessive permissions untouched; only in the final September 29 review had AWS removed the permissions allowing cross-agent invocation, private-conversation reads, and Secrets Manager access. From first disclosure to full remediation: 278 days.

Bargury drew the boundaries clearly in an October 12 follow-up statement: the flaws did not cross AWS account boundaries, and had been "fully mitigated." No CVE was issued, and there's no evidence of in-the-wild exploitation. But during that 278-day window, everyone deploying AgentCore agents with default configurations was theoretically exposed — and "default configuration" is precisely what most people, especially vibe developers moving fast on an idea, are most likely to use.

Four checks for vibe developers: before your agent goes to the cloud

AgentCorruption is fixed, but it exposed a systemic pattern: agent platforms, in the name of "it just works," hand you defaults far broader than you need. Before your next agent deployment, run through these four:

1. Least-privilege execution role, one per agent. Don't reuse, don't copy the default role. Write only the actions and resources this agent's current job actually needs into the role policy. Remember the lesson: the blast radius lives in the policy, not the model.
2. Lock down IMDS: IMDSv2 plus network policy. Make sure instances only accept IMDSv2 (hop limit 1), and explicitly block 169.254.169.254 in the agent's network policy. SSRF is an old bug, but agents' tool-calling ability gives it a new vehicle.
3. Treat agent memory as a persistence attack surface. Cross-agent memory read/write permissions off by default; regularly audit what gets written into long-term memory. A malicious memory's ability to lie dormant rivals any backdoor — AgentCorruption proved it.
4. Keep secrets out of environment variables and loose Secrets Manager policies. Inject API keys and OAuth tokens on demand with minimal grants; env vars and permissive secrets policies are the two drawers credential harvesters love to open first.

The more autonomous the agent, the more the identity boundary matters

AgentCorruption pairs neatly with the earlier-reported CoreBreak (CVE-2026-18830, which targeted the InvokeHarness API to bypass model guardrails): one hit the model's logic layer, the other the platform's identity and access layer. The more capable and autonomous agents become, the more it matters under what identity they act in the cloud — because every tool call spends that identity's "credit."

The spirit of vibe coding is turning ideas into reality fast — but the "deploy to cloud" step deserves ten more minutes than writing the prompt: open the IAM console and look at what your agent is actually allowed to do. If the answer is "the default role, a bit of everything" — from today on, you know exactly what that means.