Critical AWS Bug Exposes AI Agents to Credential Theft

Key Takeaways

• A critical prompt injection vulnerability, dubbed “AgentCorruption,” in Amazon Bedrock AgentCore allowed attackers to steal credentials and access sensitive data.
• The flaw exploited the interaction between untrusted user prompts, an agent’s web request capabilities, and overly permissive default AWS IAM roles.
• Attackers could gain access to private chats, source code, long-term memories, API keys, OAuth tokens, and secrets stored in AWS Secrets Manager across an entire AWS account and region.
• AWS has implemented fixes, including requiring IMDSv2 and refining default IAM permissions, but stresses the importance of least privilege for agent roles.

Unpacking “AgentCorruption”: Critical Flaw in AWS Bedrock AgentCore Exposed AI Agents to Widespread Credential Theft

New findings from cybersecurity firm Zenity Labs have revealed a significant vulnerability, dubbed “AgentCorruption,” in Amazon Bedrock AgentCore that could have allowed a single malicious prompt to compromise all AI agents within an AWS account and region. This critical flaw potentially exposed a wealth of sensitive information, including private conversations, proprietary source code, long-term AI memories, API keys, OAuth tokens, and secrets managed by AWS Secrets Manager.

How the Attack Unfolded

Amazon Bedrock AgentCore is a managed service designed to facilitate the creation and operation of AI agents. Zenity’s research demonstrated that an agent configured with the ability to perform web requests could be manipulated via prompt injection to contact the local metadata endpoint at 169.254.169.254. This endpoint, typically used by cloud workloads, provides temporary AWS credentials.

Because the request originated from within the agent’s Firecracker microVM, the metadata service returned credentials associated with the agent’s execution role. This effectively created a server-side request forgery (SSRF) path, entirely driven by a user-supplied prompt. Crucially, the vulnerable agent did not require a software bug in its chat interface; it only needed to possess a permitted web or shell tool and execute the user’s request.

This incident underscores how the combination of untrusted prompt input, network access capabilities, and broad cloud permissions can transform standard agent functionalities into significant security risks. Similar vulnerabilities have been observed in other contexts, such as OpenClaw data leaks and the Amazon Q coding-agent incident.

The Pervasive Impact of Overly Permissive Roles

Zenity reported that the stolen credentials granted extensive access due to the default IAM role not being restricted to a single agent. Researchers exploited this by using DescribeLogGroups to identify agent IDs, subsequently pulling container images from Amazon ECR, invoking internal agents, and reading session events. Permissions such as bedrock-agentcore:InvokeAgentRuntime, bedrock-agentcore:ListEvents, and bedrock-agentcore:CreateEvent further enabled access to chat logs and the creation of fabricated agent memories.

The ability to access and manipulate agent memory presented a persistent threat, allowing attackers to embed hidden instructions that could alter an agent’s behavior in future interactions. Furthermore, Zenity discovered access to bedrock-agentcore:GetResourceApiKey and secretsmanager:GetSecretValue, which could expose credentials for integrated services. This meant a single compromised agent could serve as a gateway to other business applications and sensitive cloud data.

AWS Response and Mitigation

Zenity notified AWS of the metadata access issue on December 25, 2025, and the broad role permissions on January 12, 2026. In response, AWS transitioned new deployments to IMDSv2 in February and later enforced its use. By September 29, Zenity confirmed that AWS had addressed the reported issues by removing overly broad permissions for agent calls, chat access, and Secrets Manager access, indicating that the reported vulnerabilities are now patched.

However, AWS has clarified that it does not categorize this finding as a vulnerability. The company asserts that accessing an agent’s own execution-role credentials via the metadata service is an expected and documented behavior. AWS also maintains that cross-account access necessitates explicit permissions on both the execution role and the target resource. Its credential guidance explicitly warns that any code or actor within the microVM can invoke the metadata endpoint.

What You Should Do

• Implement Least Privilege: Do not solely rely on platform-level changes. AWS strongly recommends configuring custom production roles with the absolute minimum actions and resource names required for each agent.
• Avoid Wildcard Permissions: Actively block broad wildcard permissions in IAM policies to prevent excessive access.
• Validate Prompt Input: Implement robust validation and sanitization for all user-supplied prompts to prevent injection attacks.
• Limit Network Access: Restrict outbound network access for agents to only essential endpoints.
• Isolate Agents: Separate public-facing agents from internal-facing agents to contain potential breaches.
• Monitor Activity: Continuously monitor CloudTrail and CloudWatch logs for any unusual or unauthorized API calls.
• Utilize Gateway Controls: Employ AgentCore Gateway controls and ensure callers cannot bypass them to directly access a runtime.
• Treat Agents as Workloads: Understand that AI agents are cloud workloads, not just chatbots. Conduct thorough access reviews for every tool, secret, network route, and role before deployment and after any changes.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.