AgentCorruption is a chain of security findings in Amazon Bedrock AgentCore, disclosed by Zenity Labs on October 8, 2026, in which a single prompt to one public-facing agent returned cloud credentials that reached every AgentCore agent in the same AWS account and region.

Zenity Labs published the research alongside a talk at SecTor 2026 in Toronto. The chain starts small: a public-facing AgentCore agent equipped with an ordinary tool that can make outbound web requests. The researchers' prompt instructed the agent to call the instance metadata endpoint at 169.254.169.254 — the service that hands temporary AWS credentials to cloud workloads. Because an AgentCore agent runs inside a Firecracker microVM and the request originated inside that VM, the metadata service answered with the credentials of the agent's execution role. No software bug in the chat surface was needed; the agent used an allowed tool, as instructed.

The reach of those credentials is what made the finding serious. Zenity reports that the default execution role was not scoped to the one agent: it carried DescribeLogGroups (enough to enumerate agent IDs across the account's region), bedrock-agentcore:InvokeAgentRuntime (invoke any agent in the account and region), bedrock-agentcore:ListEvents (read private conversations across agents, users and sessions), bedrock-agentcore:CreateEvent (write new agent memories), ECR image pulls (agent source code), and bedrock-agentcore:GetResourceApiKey plus secretsmanager:GetSecretValue (API keys, OAuth tokens and other stored credentials). The researchers also demonstrated persistence: planted memories that redirected an agent's future conversations to an attacker-controlled destination.

AWS disputes the framing. In its statement, carried in Zenity's own publication, AWS says the metadata behavior "is documented and expected," that an agent can reach another account's resources only with explicit permissions on both sides, and that customers should grant execution roles only the permissions their agents need. Per the disclosure timeline Zenity published: the metadata finding was reported on December 25, 2025 and closed by AWS as "informative" on April 12, 2026, with AWS noting that AgentCore had moved to IMDSv2-only for new deployments as of February 14, 2026. The over-broad default role, reported January 12, 2026, was still unchanged when Zenity re-checked on June 22 — and was substantially hardened by September 29, when Zenity observed that the permissions for cross-agent invocation, conversation reads and Secrets Manager access had been removed. Zenity states the reported issues are fixed. This is published attack-chain research, disclosed and remediated before publication — not a reported breach.

Why does one compromised agent keep becoming all of them?

Strip the AgentCore specifics away and the structure is familiar. An AI agent with an outbound-request tool, running inside credentialed compute, is a proxy into that machine's identity. Server-side request forgery against the metadata service is one of the oldest moves in cloud security — what is new is that the "server-side code" making the forged request is a language model following whatever instructions reach it. Prompt injection turns every network-capable tool into the attacker's HTTP client, with no exploit required.

The second structural gap is where the identity boundary sat. The platform's default execution role answered the question "what can AgentCore workloads do in this account?" rather than "what can this agent do?" Once authorization is scoped to the platform instead of the individual agent, every agent in the account's region shares one blast radius. Zenity's own example: an attacker entering through an internet-facing customer-service agent could move laterally to an internal finance agent deployed in the same region. AWS's own credentials-management page now warns, in its own words, that "any code or actor running inside the VM can access these credentials by calling the metadata endpoint," and its runtime guidance tells customers that CLI-generated policies "are designed for development and testing" and are not suitable for production.

The third gap is time. Platform defaults move slowly: by the published timeline, the over-broad role was reported on January 12, 2026, confirmed unchanged on June 22, and hardened only by September 29. Teams who deployed in that window inherited a security posture they never reviewed — and a default that is safe today says nothing about the role attached to agents deployed last spring.

What should teams running cloud agents check now?

Most of this list is AWS's own hardening guidance, and none of it requires new tooling. Review the execution role on every deployed agent: replace default or CLI-generated roles with per-agent custom roles scoped to specific resource ARNs, and explicitly deny invocation permissions the agent does not need. Confirm metadata-service protections: AgentCore runtimes have required MMDSv2 since June 30, 2026 — runtimes without it cannot be invoked — and if your agents run elsewhere, check what your platform's equivalent setting is and whether it is on. Audit every tool that can make network requests for localhost and link-local reach; AWS recommends URL filtering or allowlisting at the tool level. Separate public-facing agents from internal ones — ideally by account, at minimum by role. Review which identities can write to agent memory, since memory is now a persistence mechanism. And validate inbound payloads: AWS's guidance includes enforcing that the prompt field is a string, because structured content blocks can dispatch tools directly, bypassing model reasoning. Finally, remember the shared-responsibility line: prompt-injection prevention and input validation sit on the customer's side of it.

How Waxell handles this

Waxell cannot change what a cloud platform's metadata service does, and this research ran inside a managed platform's own tooling. What the incident illustrates is the general requirement: the controls that limit what a compromised agent can do have to live outside the agent's own environment — a point AWS's own best-practices page makes when it recommends fronting runtimes with a governed gateway so that policy is applied before traffic reaches the agent's world.

That is the job the Waxell MCP Gateway does for the MCP tool calls an agent fleet makes. Each tools/call that traverses the gateway is resolved to a real user identity and evaluated against policy rules before the upstream ever sees the call — and the result is checked again on the way back. For the specific shapes in this research: a deny or require_approval rule can gate tools capable of arbitrary outbound requests, and a parked call shows the reviewer the exact arguments — a link-local metadata URL in a web-request call is visible at the moment of review, and reviewers are notified by email or webhook when a call parks. On the return path, the gateway's DLP actions scan tool results for credentials and can block a result when a scanner hits, and egress_block blocks results that carry URLs or hosts outside an allowlist. A rate_limit rule acts as the runaway backstop. These sit within 50+ policy categories across the platform, and rule changes propagate to the gateway fleet within 30 seconds.

Every decision — the identity, the rule that fired, allow or deny or approval — lands in an audit log that stores no payloads, holds for years and exports to CSV. When the question after an incident like this is "which agent called what, with whose identity, and what did policy do about it," that record answers it.

The honest scope note: the gateway governs the calls configured to traverse it. An agent holding direct upstream credentials bypasses it, and platform-internal tooling of the kind this research used never crosses an MCP boundary. The architectural lesson stands either way — an agent's permissions and its tool traffic need an enforcement point the agent cannot reach from inside its own prompt.

FAQ

What is AgentCorruption?

AgentCorruption is the name Zenity Labs gave to a chain of security findings in Amazon Bedrock AgentCore, published October 8, 2026. A single prompt to one public-facing agent retrieved its execution-role credentials via the instance metadata service, and the default role's breadth let the researchers invoke other agents, read conversations, plant memories and pull stored secrets across the AWS account and region.

How did a prompt injection reach cloud credentials?

The targeted agent had a tool that could make outbound web requests. The prompt told the agent to call the metadata endpoint at 169.254.169.254, which serves temporary credentials to the workload it runs on. Since the request came from inside the agent's microVM, the service answered — a server-side request forgery driven entirely by instructions, not by a code exploit.

Did AWS classify AgentCorruption as a vulnerability?

No — AWS says the metadata behavior is documented and expected, and it closed Zenity's first report as "informative." AWS still changed the surrounding defaults: IMDSv2-only for new deployments as of February 14, 2026, MMDSv2 required for all runtimes since June 30, 2026, and a substantially hardened default execution role observed by September 29, 2026.

Is the issue fixed?

Zenity states that the issues described in its research have been patched and the underlying problems addressed, and its September 29 review confirmed the default role no longer allows cross-agent invocation, conversation reads or Secrets Manager access. The durable customer-side work remains: custom least-privilege execution roles, scoped tool network access and separation of public-facing from internal agents.

Does the Waxell MCP Gateway stop prompt injection?

It constrains what an injected agent can do rather than preventing injection itself. The gateway scans tool descriptions for embedded instructions at fingerprint time, before any agent calls the tool, and its policy gate — deny rules, approval holds, result-side DLP and egress blocking — limits the blast radius of whatever instructions an agent ends up following. Injection prevention inside the model remains the agent operator's responsibility.

Sources

• Zenity Labs (Tamir Ishay Sharbat and Lana Salameh), "AgentCorruption: How A Single Prompt Collapsed The Entire Cloud Security Model", October 8, 2026

• Zenity, "Zenity Labs Discloses AgentCorruption, a Chain of AWS AgentCore Flaws", October 8, 2026

• AWS, "Understanding Credentials Management in Amazon Bedrock AgentCore", retrieved October 14, 2026

• AWS, "Security best practices for AgentCore Runtime", retrieved October 14, 2026

• Cyber Security News (Guru Baran), "One Prompt Could Hijack AWS AI Agents and Steal Cloud Credentials", October 10, 2026

See the Waxell MCP Gateway hold a risky tool call for approval, live — book a 30-minute demo.