On October 8, 2026, Zenity Labs published AWS AgentCore security research it calls AgentCorruption. The claim is blunt. One prompt to a public Bedrock AgentCore agent could reach instance metadata. It could steal temporary credentials and open other AgentCore agents in the same AWS account and region.

That is not a niche lab toy. Agencies in India and the USA are shipping support bots, internal ops agents, and client copilots on managed cloud runtimes. If one chat widget can see the same role as a finance agent, your trust model is already wrong.

I am Nitin from Debugged Pro. We help product and agency teams build agent systems with clear boundaries. Below is a plain briefing on what Zenity proved and what AWS changed. Use it before your next Bedrock AgentCore release.

Zenity press visual tied to the AgentCorruption disclosure on Amazon Bedrock AgentCore. Image via Zenity.

What Zenity Found on AWS AgentCore Security

Amazon Bedrock AgentCore is AWS's managed platform for deploying and operating AI agents. Developers use it to host agents, attach tools, manage identity, and run production sessions.

Zenity Labs disclosed a chain of flaws, not a single bug. The research was presented with SecTor 2026 in Toronto. Zenity's press note and overview post spell out the path from one public agent to wider control.

Start with the Zenity Labs AgentCorruption technical overview for the attack path, IMDS access, role blast radius, and disclosure timeline. Zenity also issued a matching press disclosure the same day.

Michael Bargury, co-founder and CTO of Zenity, framed the core tension clearly. Cloud security wants segmentation and least privilege. Agents need room to act. Mixing those goals without tight defaults creates conflict.

How One Prompt Broke AWS AgentCore Security Boundaries

The attack began with a public AgentCore agent. That agent had a common tool for outbound HTTP requests. Researchers prompted that agent to call the AWS Instance Metadata Service, known as IMDS.

IMDS lives at the link-local address 169.254.169.254. From inside many AWS workloads, it can return temporary credentials for the IAM role attached to the machine.

AgentCore agents run inside Firecracker MicroVMs. Zenity says those MicroVMs did not provide enough network isolation. Requests from the agent tool left the guest as if they came from the instance itself. That created an SSRF-style primitive.

Illustration of AgentCorruption lateral movement across AWS AgentCore agents — Zenity Labs visual of AgentCorruption: one compromised agent spreading across other AgentCore agents. Image via Zenity Labs.

Because the request came from inside the instance, IMDS returned the temporary credentials for the AgentCore execution role. Chat access became cloud access.

The overprivileged default role widened the blast radius

Credentials alone are not the whole story. Zenity found the default AgentCore role was not scoped to one agent. It carried broad rights across AgentCore resources in the region.

With those rights, researchers could move far beyond the first support bot. Zenity reports they could:

Discover and invoke other AgentCore agents in the same account and region, including internal ones
Read private conversations and long-term memories across agents, users, and sessions
Pull agent container images from ECR and inspect source code
Retrieve API keys, OAuth tokens, and other secrets from AWS Secrets Manager and environment paths
Create malicious memories that steered later agent behavior toward attacker goals

In Zenity's example, an attacker who entered through an internet-facing customer service agent could then reach an internal finance agent in the same region, invoke it, and touch its data, tools, and chats.

AWS AgentCore Security and Agent Discovery Details

After stealing credentials, researchers still needed agent IDs. Zenity says the role included DescribeLogGroups. CloudWatch log group names helped enumerate agents across the region.

ECR repository names for AgentCore resources matched those agent IDs, which made image pulls straightforward. The role also included region-scoped bedrock-agentcore:InvokeAgentRuntime. That let researchers call other agents they were never meant to reach.

ListEvents and related session rights broke privacy boundaries. Whatever users told agents in that account and region became readable to the holder of the stolen role.

Demo chat prompt targeting AWS IMDS credentials through a support agent — Zenity demonstration of a support-agent prompt aiming at the IMDS credentials path. Image via Zenity Labs.

Memory Poisoning Turned Access Into Persistent Hijacking

Read access was bad enough. Write access to AgentCore Memory made the compromise stick.

Zenity's memory write-up explains how CreateEvent on BedrockAgentCoreMemory covered memory/* in the target account and region. Researchers could submit new short-term conversation events. Configured long-term strategies then extracted lasting records.

AgentCore Memory strategies include SEMANTIC, USER_PREFERENCE, SUMMARIZATION, and EPISODIC. Each stores a different kind of lasting signal: facts, preferences, summaries, or past episodes.

Researchers framed injected text to match those strategies. One pattern planted a standing request that forced the agent to fetch an attacker-controlled page before answering. That page became a command channel. Changing the page changed later agent goals without a new memory write.

The same channel could order the agent to send user messages and agent replies to a collection endpoint. Users could keep chatting with a trusted brand agent while content left the tenant.

Key point: persistence did not need malware on a laptop. It lived inside the agent's remembered context.

What AWS Changed After Disclosure

Zenity responsibly disclosed the findings to AWS. The timeline matters for agencies that still run older agents.

December 25, 2025: Zenity reported IMDS access on Bedrock AgentCore.
January 12, 2026: Zenity filed a second report on the overprivileged default role and blast radius.
February 14, 2026: AWS had updated AgentCore so newly deployed agents launch with IMDSv2 only. Zenity notes AWS closed the first report as informative after those IMDS improvements.
September 29, 2026: Before publication, Zenity rechecked the default execution role and saw substantial hardening. Permissions that allowed cross-agent invocation, reading private conversations, and Secrets Manager access were removed or tightly reduced.

Zenity thanks AWS for collaboration through the process. Dark Reading coverage of the SecTor talk notes Zenity saw no clear in-the-wild abuse before the fix. AgentCore deployments are also hard for outsiders to enumerate.

AWS documentation now stresses least privilege for AgentCore Runtime. It warns that code inside the microVM can reach metadata credentials, and it tells builders to scope execution roles carefully. AWS also documents a move toward required MMDSv2 behavior for agent runtimes. Treat current AWS docs as the live checklist, not a blog summary.

For the official hardening guidance, use AWS Bedrock AgentCore Runtime security best practices.

Why This Matters for India and USA Agency Teams

Many agency builds place a public support agent and an internal ops agent in one cloud account. That pattern failed the Zenity test when defaults were too wide.

India-facing teams often ship WhatsApp or web support bots for banks, travel, and retail clients. USA teams ship the same pattern for SaaS onboarding and IT helpdesks. Both need the same rule: public chat is an untrusted boundary.

If your statement of work promises agent memory, tool use, and Secrets Manager connectors, you also own the failure modes. Clients will ask who can invoke which agent, who can read transcripts, and who can write long-term memory.

Map the risk with a shared language. The NIST AI Risk Management Framework helps product, security, and delivery leads talk about govern, map, measure, and manage without marketing fluff.

Also keep runtime monitoring in the plan. Our guide on AI agent monitoring with Goodfire probes covers live checks before risky tool calls. For dependency hygiene on open packages, see our note on the Anthropic open-source scanner for vulnerability scans.

Practical AWS AgentCore Security Checklist for Agencies

Use this as a delivery checklist before you mark an AgentCore project done.

Inventory exposure. List every public AgentCore endpoint, gateway, and JWT or IAM auth path.
Confirm metadata version. Prefer IMDSv2 or MMDSv2. Do not assume old agents inherited the new default.
Rewrite the execution role. Drop region-wide wildcards. Scope invoke, memory, secrets, and ECR rights to named resources.
Split trust zones. Keep customer-facing and high-sensitivity internal agents in separate accounts or at least separate roles and VPCs.
Gate outbound tools. Limit HTTP tools with allowlists. Block link-local and metadata ranges in tool policy where you can.
Lock memory writes. Restrict CreateEvent. Audit who can plant long-term preferences or semantic facts.
Front with a gateway. AWS recommends AgentCore Gateway controls so callers cannot skip policies and guardrails.
Log and alarm. Watch CloudTrail for InvokeAgentRuntime spikes, unusual GetSecretValue calls, and memory create events outside your app.
Retest with prompts. Include metadata and lateral-move prompts in red-team scripts before go-live.
Write client language. State role scope, memory ownership, and incident contact paths in the SOW.

Need a review of an AWS agent build? Our software development consulting team can walk IAM and tool boundaries with your engineers.

Key Takeaways

AgentCorruption showed that AWS AgentCore security depends on both metadata isolation and least-privilege roles.
One public agent with an HTTP tool was enough for Zenity to reach IMDS and steal temporary credentials.
Default role scope turned one compromise into region-wide agent invoke, chat read, image pull, secrets access, and memory write.
Memory poisoning created persistence and a command channel without rewriting the agent container.
AWS remediations include IMDSv2 defaults for new AgentCore agents and a tighter default execution role.
Agencies should inventory public agents, split trust zones, and treat memory write rights as high risk.

FAQ

Nitin Kumar is Lead Project Coordinator at Debugged Pro. He works with India and USA agency teams on cloud agent delivery, security reviews, and practical launch checklists.