A prompt sent to a public-facing artificial-intelligence agent could once have become a route into other Amazon Bedrock AgentCore resources in the same AWS account and region, according to research from Zenity Labs. The attack chain, called AgentCorruption, illustrates how ordinary agent capabilities can combine into a serious cloud-security failure even when the chat interface itself contains no traditional software vulnerability.

The researchers said the chain exposed private conversations, source code, persistent memory, API keys, OAuth tokens, and values stored in AWS Secrets Manager. AWS has since changed relevant defaults and removed broad permissions identified during disclosure. The episode nevertheless offers an important design lesson: an AI agent is both an application that interprets untrusted language and a cloud workload that may hold powerful credentials.

From an untrusted prompt to workload credentials

AgentCore provides managed infrastructure for creating and operating AI agents. Zenity found that an agent equipped with a web-request or shell tool could be instructed to contact the link-local metadata address at 169.254.169.254. Because the request originated inside the agent’s Firecracker microVM, the metadata service returned temporary credentials associated with the runtime’s execution role.

This amounted to a prompt-driven server-side request forgery path. The model followed an instruction using a capability developers had intentionally provided; the danger came from the destination it could reach and the authority attached to the resulting credentials. Untrusted input, unrestricted network access, and an overpowered role turned a useful tool into a cloud-control channel.

Zenity reported the metadata behavior in December 2025 and raised the wider role-permission issue in January 2026. AWS moved new deployments to the more defensive IMDSv2 flow in February and subsequently required it. By late September, the researchers confirmed that AWS had removed permissions enabling broad agent invocation, conversation access, and Secrets Manager access.

Shared permissions widened the blast radius

The stolen role was especially consequential because, according to the researchers, its default permissions were not confined to a single agent. They used log-discovery capabilities to identify agent IDs, retrieved container images from Amazon Elastic Container Registry, invoked internal agents, and inspected session events.

Permissions related to AgentCore runtimes and events could expose chats or allow fabricated memories to be inserted. Persistent memory creates a particularly subtle risk: malicious instructions stored today may influence an agent during later conversations, after the original prompt and attacker are no longer visible. Access to resource API keys and Secrets Manager could also turn one compromised agent into a bridge toward connected business services.

AWS disputed describing the behavior as a vulnerability. The company noted that software running within a microVM can access the execution role credentials by design and that cross-account access still requires permissions on both the role and the target. That distinction matters, but it does not remove the customer-side risk created by excessive privilege or by tools that let untrusted prompts reach sensitive network locations.

Controls for production AI agents

• Create a custom IAM role for every production agent and restrict actions to named resources instead of using wildcards.
• Block unnecessary outbound destinations, especially metadata and internal management endpoints.
• Separate internet-facing agents from internal agents that can reach sensitive data or actions.
• Validate tool inputs and route access through controlled gateways that callers cannot bypass.
• Monitor CloudTrail and CloudWatch for unusual runtime invocations, secret retrieval, event creation, and image access.

Prompt filtering alone is not a sufficient boundary because models can be manipulated in ways that are difficult to predict exhaustively. The stronger approach assumes that an agent will eventually receive a hostile instruction and limits what its identity, tools, and network position can do when that happens.

Treat agents as privileged workloads

Organizations should inventory each agent’s tools, credentials, data stores, network routes, and persistent memory. Reviews should occur before deployment and whenever a tool or integration is added, because a seemingly modest capability may compose with existing permissions in unexpected ways.

AgentCorruption demonstrates a recurring pattern in AI security: the model need not “break out” through a novel exploit if developers already gave it access to the pieces needed for an attack chain. Least privilege, isolation, observable tool use, and explicit trust boundaries remain the most dependable defenses.