The Default Role, Not the Model: How One Prompt Took Over Every Agent in an AWS Account

Key takeaways

• One prompt to one public-facing agent compromised every AgentCore agent in the same AWS account and region — Zenity Labs disclosed the AgentCorruption chain on October 8, 2026 at SecTor in Toronto, after a responsible disclosure that began December 25, 2025.
• The blast radius was a role property, not a model property — the default execution role carried bedrock-agentcore:InvokeAgentRuntime, bedrock-agentcore:ListEvents, a cross-agent memory-write permission, bedrock-agentcore:GetResourceApiKey, and secretsmanager:GetSecretValue, all scoped across the account's region rather than to the one agent.
• The fix took 278 days — AWS moved AgentCore to IMDSv2 by February 14, 2026, but Zenity's June 22, 2026 re-check found the default role unchanged; the permission removals landed by September 29, 2026.
• Agent memory is a persistence surface — the researchers planted memories that redirected agents' future conversations to an attacker-controlled destination, while users kept talking to what appeared to be a trusted enterprise agent.
• AWS called the behavior "documented and expected" — and recommends customers grant execution roles only the permissions their agents need. The default-role check is the customer's job, on any managed platform.

On October 8, 2026, at the SecTor conference in Toronto, Zenity Labs disclosed AgentCorruption: a chain of flaws in Amazon Bedrock AgentCore, AWS's managed platform for deploying and operating AI agents. A single prompt to one public-facing agent — an internet-facing customer service agent, for example — returned the temporary AWS credentials assigned to that agent's machine. Those credentials belonged to a default IAM role whose permissions were scoped not to the one agent but to every AgentCore agent in the same AWS account and region. With them, the researchers invoked internal agents they were never authorized to touch, read private conversations across agents and users, downloaded agent container images to extract source code, pulled API keys and OAuth tokens from AWS Secrets Manager, and planted memories that kept working after the session ended.

None of that required a model failure. The model's only job in the chain was to make one HTTP request when asked. Everything after that was IAM. This article maps the five-step chain, the specific permissions that made each step possible, the 278-day disclosure timeline, and the five questions any team should ask before deploying agents on a managed agent platform — whichever vendor's platform it is.

The attack chain, step by step

Zenity Labs published the full research as a five-part technical series; the chain compresses to five moves.

Step 1: prompt injection to IMDS. AgentCore agents run inside Firecracker microVMs whose network isolation did not block the instance metadata service. Any agent tool capable of making an outbound HTTP request sends that request from within the instance itself — an SSRF primitive. One prompt directed the exposed agent to call 169.254.169.254, the Instance Metadata Service, which handed back the temporary IAM credentials of the role assigned to the workload. The entry cost was chat access to a single agent with a commonly used tool.

Step 2: account-wide discovery. The credentials belonged to a default execution role that was not scoped to the specific agent. Among its permissions was DescribeLogGroups, which the researchers used to enumerate every agent and its ID across the account's region. A second discovery path came for free: the Elastic Container Registry repository names matched the agent IDs, so the role's ECR pull permission let the researchers download any agent's container image and read its source code in full.

Step 3: lateral movement. The role included bedrock-agentcore:InvokeAgentRuntime, scoped to the entire region. The researchers could invoke any AgentCore agent in the account — including internal and sensitive agents they were not authorized to access. The worked example in the disclosure: an attacker entering through the internet-facing customer service agent moves laterally to an internal finance agent in the same region, invokes it, and accesses its data, tools, and credentials.

Step 4: data and credential access. bedrock-agentcore:ListEvents returned all private conversations across all agents, users, and sessions — the platform's privacy boundaries, dissolved. bedrock-agentcore:GetResourceApiKey and secretsmanager:GetSecretValue then reached the credentials AgentCore deliberately keeps away from the agent: API keys, OAuth tokens, and Secrets Manager entries, including credentials used to connect to enterprise resources and third-party services beyond AWS.

Step 5: persistence through memory. The role also carried a memory-write permission — bedrock-agentcore:CreateEvent on BedrockAgentCoreMemory. The researchers created new memories across different agents and users that persistently altered agent behavior and hijacked the agents' goals across future sessions, directing conversations to an attacker-controlled destination. The compromise survived the session that created it.

The chain below maps the five moves and what each one exposed:

The role, not the model

The structural lesson is in what the five steps did not involve. No jailbreak, no alignment failure, no sophisticated prompt engineering beyond "call this URL." Zenity's co-founder and CTO Michael Bargury framed the root cause as a design tension every platform ships with: "Cloud security is all about segmentation and least-privilege access. AI agents, however, need their creative space to be useful. Mixing the two creates an inherent conflict." His conclusion: "Every company deploying agents in the cloud will run into the same fundamental choices to be made between agency and least privilege."

AgentCore resolved that conflict in favor of agency — for the platform's convenience, not the customer's security. The default execution role was broad so that agents would work out of the box, and its permissions covered every agent resource in the account region. AWS's own statement, published with the research, says the behavior is "documented and expected," that agents can access their own execution-role credentials through the metadata service, and that "as a best practice, we recommend that customers grant their execution roles only the permissions their agents need," pointing to its credentials management, runtime permissions, and least-privilege guidance.

Read those two facts together and the buyer's position is unambiguous: the platform treats the default role as a starting point, and the blast radius of a compromised agent as the customer's configuration problem. That is a defensible position for a cloud vendor to take — IAM least privilege has been the customer's job since IAM existed. But it collides with the marketing frame around managed agent platforms, which is that the platform handles the operational hardening so your team does not have to. The AgentCorruption chain is what that collision looks like in practice: the platform's default was the vulnerability, and the platform's documentation was the mitigation.

278 days from disclosure to fix

The disclosure timeline is the second lesson. Zenity reported the initial IMDS access on December 25, 2025. AWS moved AgentCore to IMDSv2-only for newly deployed agents by February 14, 2026, and closed that first report as "informative" on April 12. But Zenity's second report — the blast radius of the default role, filed January 12, 2026 — moved slower. On February 25, AWS said the team was actively working on it while the default role stayed the same. On June 22, 2026, Zenity re-checked and confirmed the permissions remained unchanged. The substantial fix — removing the permissions that allowed wide agent execution, reading private conversations, and accessing Secrets Manager — was observed on September 29, 2026, 278 days after the first disclosure and days before public release.

Date	Event
Dec 25, 2025	Zenity discloses initial IMDS access to AWS
Jan 12, 2026	Zenity discloses the default-role blast radius report
Feb 14, 2026	AgentCore updated to IMDSv2-only for newly deployed agents
Feb 25, 2026	AWS confirms work in progress; default role unchanged
Apr 12, 2026	AWS closes the IMDS report as "informative"
Jun 22, 2026	Zenity re-check: default role still unchanged
Sep 29, 2026	Default role hardened — cross-agent, conversation-read, and Secrets Manager permissions removed

Two implications for any team counting on a managed platform's defaults. First, a convenience default can be a standing vulnerability for the better part of a year even after a responsible disclosure — the window between "we reported it" and "it is fixed" is measured in months, and your agents run in it. Second, the fix itself is the proof of the thesis: AWS did not retrain a model or add a safety filter. It edited a role policy. The blast radius was an IAM document the whole time.

Memory is a persistence surface

The most forward-looking part of the chain is step 5. Reading data is a breach; modifying memory is a takeover. The researchers used the role's memory-write permission to plant instructions that survived the session, redirected future conversations to an attacker-controlled destination, and left the agent appearing to operate normally. An incident response that stops the agent, rotates its credentials, and patches the injection vector does not remove a planted memory. If the memory store is not part of the response, the compromise persists through the cleanup.

This is the same behavior-modification class that pushed Anthropic to cut off live internet access for all internal agent evaluations, as the company disclosed in October 2026 — the subject of Two Frontier Labs, One Admission. The containment article covers the frontier-lab admission that alignment training is not enough to control agent behavior. AgentCorruption shows the same problem one layer down, at the platform level: a memory store writable by anything with the right IAM permission is a persistence mechanism, and the kill-switch architectures covered in Kill Switch by Design need to treat memory as part of the compromised state, not just the runtime.

Five questions before you deploy on any managed agent platform

AgentCore is the worked example, not the exception. Zenity's press release makes the general point itself: enterprises routinely run customer-facing and internal agents side by side in the same cloud environments, and a single unexpected weakness in one agent can collapse the boundaries of an entire environment. The platform will differ; the permission classes will rhyme. Before any agent goes live on a managed platform, get written answers to these five:

1. What exactly is in the default execution role? Not "is it secure by default" — the policy document, permission by permission. Flag every permission scoped to * or to all agents in the account. AgentCorruption's chain is the five-permission answer to this question.
2. Can one agent discover the others? Any account-wide list or describe permission turns one compromised agent into an inventory of targets. DescribeLogGroups was the enumeration step; every platform has an equivalent listing surface.
3. Can one agent invoke another? Agent-to-agent invocation is the lateral-movement primitive. If the platform cannot scope invocation to explicit, per-agent allowlists, treat every agent in the account as one trust domain — because that is how the attacker will treat it.
4. Where do tool credentials live, and which role can read them? A secrets gateway only moves the risk if no agent role can call GetSecretValue on it. The AgentCorruption role could read exactly the credentials the platform design was supposed to keep away from agents.
5. Can memory be written by anything other than the agent itself, in its own session? Cross-agent and cross-user memory writes turn the memory store into a persistence surface. If the answer is a permission you can scope, scope it; if it is not, the memory store belongs in your incident-response plan as attacker-controlled state.

Related reading

• Bedrock vs OpenAI: Choosing a Managed AI Platform for Production Agents — the managed-platform comparison this incident lands on: cost, privacy, and vendor stability, with the default-role question now added to the due-diligence list
• 126 Incidents in One Month: The First Comprehensive AI Security Inventory — the frequency statement behind this incident: agent-layer exploits were the largest attack-vector class in September 2026
• AI Agent Governance Checklist: A Pre-Deployment Review — the full pre-deployment review, including least-privilege execution roles and cross-agent discovery as checklist items

A mid-market industrial distributor running two agents on a managed platform — a public quoting agent in front of its BigCommerce storefront and catalog, and an internal agent with NetSuite pricing tiers and inventory access — has exactly the topology AgentCorruption exploited: one internet-facing agent and one back-office agent in the same account. The pattern we build against gives each connector module its own least-privilege role, registers every tool the agent may call, scopes memory per agent, and writes an audit trail that would show a memory-write from outside the session. The point is not that a scoped build is immune to a platform-side flaw; it is that the blast radius of the next one is set by the role policy your team reviewed, not the one the platform shipped as a default.

One-week discovery. You get a system inventory, workflow map, and fixed scope — whether or not you build with us.

Request a scoped build.