At the SecTor 2026 conference in Toronto on Wednesday, Tamir Ishay Sharbat, director of security research at the AI security vendor Zenity Labs, walked through a flaw chain in AWS Bedrock AgentCore that his team calls AgentCorruption. AgentCore, launched last year, is AWS's managed platform for deploying and operating AI agents. The finding, now patched, allowed a single natural-language prompt sent to one public-facing agent to escalate into control of every agent in the same AWS account and region.
The entry point was the instance metadata service. Agents deployed through AgentCore run inside a Firecracker MicroVM that, per Zenity, lacked the network isolation needed to block access to IMDS — the internal endpoint at 169.254.169.254 that hands out temporary credentials, instance IDs and configuration data. Any agent able to make an HTTP request could ask IMDS for credentials, and the agent complied. "That was so freakin' easy," Sharbat told the audience.
With those temporary credentials, the blast radius was far larger than one agent. Zenity found that AgentCore's default execution role carried broad permissions across all AgentCore resources in the region, not just the agent it was attached to. From a single public chatbot, the researchers said, they could invoke other agents, read private conversations between agents and users, download container images and source code, and pull API keys and OAuth tokens from AWS Secrets Manager. They could also write instructions into an agent's long-term memory — a memory-poisoning step that makes the compromise persistent and can exfiltrate future conversations.
Sharbat framed it as a rerun of an older story. The 2019 Capital One breach, he noted, began with a server-side request forgery that let an attacker reach an EC2 metadata service and retrieve credentials — "all because they didn't implement least privilege," he said. AgentCorruption has the same shape, except the attacker manipulates an AI agent into doing the work.
Zenity says it first reported the IMDS access issue on December 25, 2025, and followed up on January 12, 2026 about the overprivileged default role. AWS responded: since February 14 it has switched newly deployed AgentCore agents to IMDSv2, which requires an authenticated token. By Zenity's pre-publication review on September 29, AWS had also removed the permissions that allowed cross-agent invocation, reading of private sessions and access to Secrets Manager, and had significantly tightened the default execution role.
AWS disputed the framing. "AWS is aware of the research published about Amazon Bedrock AgentCore, which inaccurately paints expected and documented behavior as a vulnerability," a spokesperson said. An agent can reach resources in another AWS account only if a developer explicitly grants permissions on both the agent's execution role and the target resource, the company said, adding that customers should grant execution roles only the permissions their agents need. Zenity said it found no evidence the flaw was exploited before the fix.
AgentCore's security surface has drawn other researchers as well. In July, Amazon's own security bulletin CVE-2026-12530 — credited to BeyondTrust's Phantom Labs — described an argument-injection flaw (CWE-88) in the install_packages() method of the Bedrock AgentCore Python SDK from version 1.1.3 up to but not including 1.6.1, which could let a remote authenticated user run arbitrary commands inside the Code Interpreter sandbox. AWS fixed it in SDK 1.6.1.
The broader point is structural. Cloud environments are built on isolation and least privilege; agentic AI is built on broad access and wide permissions, and the agent is the one deciding what to fetch. "Cloud and AI are kind of like fire and ice," Sharbat said. "And we're going to see how mixing them might go terribly." The lesson for anyone deploying agents is that privilege boundaries have to be enforced at the platform layer — the execution role, the network path to the metadata service — rather than trusted to the agent's own restraint. Zenity said it is now examining other cloud platforms for similar patterns.
Comments (0)
Log in to join the discussion
Log InNo comments yet