‘AgentCorruption’ Puts AWS Environments At Risk With Single Prompt
A now-patched vulnerability in AWS Bedrock AgentCore could allow an attacker to use one AI chatbot to take over an organization’s entire fleet.
A now-patched vulnerability in AWS Bedrock AgentCore could allow an attacker to use one AI chatbot to take over an organization’s entire fleet.
SecTor 2026 – Toronto – If one thing has become apparent over the past year, it’s that AI and cloud computing don’t mix well.
That’s according to Tamir Ishay Sharbat, director of security research at AI security vendor Zenity Labs, who detailed a now-patched flaw in AWS Bedrock AgentCore during a session at SecTor 2026 on Wednesday. Bedrock AgentCore, which launched last year, is AWS’s managed platform for deploying and operating agents.
But Sharbat and Zenity’s research team tested the platform and found that agents deployed through Bedrock AgentCore could access the organization’s Instance Metadata Services (IMDS), which contains sensitive data such as temporary credentials, instance IDs, and configurations. With a single prompt to a public facing chatbot, Sharbat discovered he could not only gain control over that specific agent but take over all agents on in the same AWS account and region.
“Cloud and AI are kind of like fire and ice,” Sharbat said. “And we’re going to see how mixing them might go terribly.”
‘AgentCorruption’ Jeopardizes AWS Instances
The core issue for Bedrock AgentCore involves a flaw with IMDS, which Zenity calls “AgentCorruption.” Sharbat told the audience that IMDS has been a weakness for cloud environments “since the beginning,” and highlighted the 2019 Capital One data breach. In that incident, the attacker used an SSRF flaw to access the company’s EC2 instance then then send requests to the IMDS to retrieve credentials and other sensitive data.
The Capital One breach, Sharbat said, is “all because they didn’t implement least privilege” for the metadata service. The same approach applies with an AgentCorruption attack, except the threat actor is manipulating a public-facing agent to do the work.
Zenity researchers discovered they could send a request to the IMDS via a support agent for temporary credentials, and the agent complied. This is because, according to Zenity, an agent deployed through the AgentCore platform runs inside a Firecracker MicroVM, which doesn’t have the necessary network isolation in place. Therefore, an attacker can use any agent with the ability to make HTTP requests to issue such a request to the IMDS’ endpoint within the instance.
“That was so freakin’ easy,” Sharbat said.
With the temporary credentials in hand, Sharbat and his team began exploring how far their access could go, and how much of a blast radius there would be in an AgentCorruption attack. They discovered that the default AgentCore role included broad permissions across all AgentCore resources in the entire region, not just for this specific type of agent. As a result, the researchers could invoke additional agents, read sessions, and even access an organization’s secrets from AWS’s secrets manager.
In addition the moving laterally across an AWS environment and obtaining privileged accounts, Sharbat said they could also engage in memory poisoning attacks against the agents. In short, a single prompt to an over-privileged public-facing agent could lead to a full compromise of an entire AgentCore region.
Mitigating AgentCorruption Attacks
Sharbat said AgentCorruption illustrates the inherent conflict between cloud environments — which should implement isolation, the principle of least privilege (POLP), and strict access controls — and agentic AI, which typically have wide access and broad permissions across a network.
Zenity initially reported the IMDS flaw to AWS in December, and later followed up with an additional report about AgentCore’s overprivileged default role and the wide blast radius. In response, AWS updated AgentCore in February so that all new agents deployed on the platform use IMDSv2, which requires authentication.
Additionally, Zenity said AWS altered AgentCore’s default role, removing the permissions that allowed agents to invoke other agents, read private conversations, and access secrets stored in AWS Secrets Manager, among other restrictions.
Sharbat said Zenity hasn’t seen any evidence of the flaw being exploited in the wild prior to AWS’s fix because there’s “security through obscurity” at work with AgentCore — it’s difficult to tell what agents are deployed via the platform, which benefits AWS customers.
However, Sharbat tells Dark Reading that while he’s not aware of a way to look up who’s running their agents on AWS BedRock, “I’m 100% sure there are ways to do it.”
Sharbat says Zenity’s team currently is examining other cloud platforms to see if similar AgentCorruption issues exist. While the company isn’t disclosing what those platforms are just yet, Sharbat says the IMDS weakness likely isn’t limited to AgentCore.
“It’s something that agent builders need to be aware of,” he says. “It’s not specific to AWS.”
The best approach, Sharbat says, is to make sure the privileges are limited for the agent’s specific role. “Even if someone gets to the IMDS, the blast radius will be a lot smaller.”
SecTor
Oct 6, 2026 TO Oct 8, 2026
|
Metro Toronto Convention Centre | Toronto
Now in its 20th year, SecTor has built a reputation of bringing together experts from around the world to share their latest research and techniques involving underground threats and corporate defences. The conference provides an unmatched opportunity for IT Security Professionals, Managers & Executives to connect with their peers and learn from their mentors.
Read more about:
