What happened
A researcher prompt caused one AgentCore workload to access IMDS credentials, which were then used to enumerate and compromise peer agents, read their data, alter memory, and retrieve secrets.
2026-10-08
HighPrimaryAgentCorruption Let One Prompt Compromise Every AgentCore Agent in an AWS Account and Region
Analysis of Zenity Labs' AgentCorruption demonstration, where prompt injection exposed AgentCore IAM credentials and enabled cross-agent takeover within an AWS account and region.
Amazon Bedrock AgentCoreCredential exposurePrompt injection chained with instance-metadata credential exposure and overbroad cloud IAMAmazon Bedrock AgentCore workloads sharing an AWS account and region
Why it matters
Controlled account-and-region-wide compromise of AgentCore workloads, with access to private conversations, source images, persistent agent memory, API keys, OAuth tokens, and Secrets Manager values.
Missing authorization check
Workload-specific, action-bound authorization for metadata credential access, cross-agent invocation, session reads, memory writes, image pulls, and secret retrieval.
Would PP block it?
Permission Protocol would not patch AgentCore's metadata exposure or stop the initial prompt injection. Where AWS and agent operations are integrated with an independent signer, the stolen workload credential alone would not authorize account-wide reads, invocations, memory changes, or secret retrieval without receipts bound to the exact target and action.
Incident analysis
Timeline and technical read
Timeline
2025-12-25
Zenity reports the AgentCore instance-metadata access issue to AWS.
2026-10-08
Zenity publishes AgentCorruption after AWS patches the disclosed issues.
2026-10-10
Dark Reading independently reports the demonstration and that no in-the-wild exploitation was known.
Technical breakdown
- A public-facing AgentCore agent could be prompted to request the link-local IMDS endpoint from inside its Firecracker MicroVM.
- IMDS returned temporary credentials for the workload's attached IAM role.
- The default role included broad regional permissions rather than authority scoped to the compromised agent.
- Researchers used log-group access to discover peer agent identifiers and demonstrated cross-agent invocation, private-session access, memory poisoning, image access, and secret retrieval.
- AWS patched the reported platform and permission issues before Zenity's publication.
Authorization boundary
Where the authorization boundary should have been
This incident is categorized as Credential exposure. The relevant Permission Protocol gate is Credential Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.
- If enforced at
- AWS credential broker and AgentCore control-plane boundaries before cross-agent, memory, image, and secret operations
- Still needs
- The initial prompt injection and IMDS credential disclosure remain cloud-platform and workload-isolation problems; enforcement requires the relevant AWS and AgentCore operations to honor the external authorization gate.
- Receipt required for
- Cross-agent invocation, private-session reads, memory mutation, container-image access, and Secrets Manager retrieval
External Credential and Tool-Call Gates could keep high-impact cloud authority outside the compromised agent role and require separately authenticated grants for cross-agent and secret operations.
Related incidents and controls
Start small
Put the relevant gate at this action boundary.
This incident maps to Credential Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.