One Prompt Could Hijack AWS AI Agents and Steal Cloud Credentials

A single prompt sent to a public-facing AI agent could have exposed every Amazon Bedrock AgentCore agent in the same AWS account and region, according to new research from Zenity Labs.

The attack chain, named AgentCorruption, gave the researchers access to private chats, source code, long-term memories, API keys, OAuth tokens, and secrets held in AWS Secrets Manager.

Amazon Bedrock AgentCore is a managed service for building and running AI agents. Zenity found that an agent with a tool able to make web requests could be told to contact the local metadata endpoint at 169.254.169.254.

This service provides temporary AWS credentials to cloud workloads. Because the request came from inside the agent’s Firecracker microVM, the metadata service returned credentials linked to its execution role.

This created a server-side request forgery path driven by prompt injection. The exposed agent did not need a software bug in its chat page. It only needed to follow the user’s request and use an allowed web or shell tool.

The case shows how normal agent features can become dangerous when untrusted prompts, network access, and cloud permissions meet. Similar risks have appeared in OpenClaw data leaks and the Amazon Q coding-agent incident.

The stolen credentials had a wide reach because Zenity said the default IAM role was not limited to one agent. Researchers used DescribeLogGroups to find agent IDs, pulled container images from Amazon ECR, invoked internal agents, and read session events. Permissions including bedrock-agentcore:InvokeAgentRuntime, bedrock-agentcore:ListEvents, and bedrock-agentcore:CreateEvent also enabled access to chats and the creation of false memories.

Memory access made the risk last beyond one session. An attacker could add hidden instructions that changed an agent’s goals during later conversations.

Zenity also found access to bedrock-agentcore:GetResourceApiKey and secretsmanager:GetSecretValue, which could reveal credentials meant for connected services. One exposed agent could therefore become a path into other business tools and sensitive cloud data.

Zenity reported metadata access to AWS on December 25, 2025, and the broad role permissions on January 12, 2026. AWS moved new deployments to IMDSv2 in February and later made it required.

By September 29, Zenity confirmed that AWS had removed permissions that allowed broad agent calls, chat access, and Secrets Manager access. The researchers say the reported issues are now fixed.

AWS disputes the finding’s description as a vulnerability. The company says access to an agent’s own execution-role credentials through the metadata service is expected and documented. AWS also says cross-account access requires clear permission on both the execution role and target resource. Its credential guidance warns that any code or actor inside the microVM can call the metadata endpoint.

Security teams should not rely only on the platform changes. AWS recommends custom production roles with only the actions and resource names each agent needs.

Teams should block broad wildcard permissions, validate prompt input, limit outbound network access, separate public and internal agents, and monitor CloudTrail and CloudWatch for unusual calls. AWS also advises using AgentCore Gateway controls and making sure callers cannot bypass them by reaching a runtime directly.

The key lesson is that an AI agent must be treated as a cloud workload, not only as a chatbot. Every tool, secret, network route, and role expands what a bad prompt may reach, so access reviews should happen before deployment and after every change.