Researchers at Zenity Labs have shown how one crafted chat message to a public-facing agent on Amazon Bedrock AgentCore could hand over cloud credentials good enough to commandeer every other agent sharing that AWS account and region. AWS has since tightened the default permissions but insists the behaviour was documented, which leaves the burden of getting it right firmly with the organisations building agents.
What happened
On 8 October 2026 Zenity Labs published research it calls AgentCorruption, alongside a SecTor 2026 talk in Toronto by Tamir Ishay Sharbat, who leads its security research. The work, by Sharbat and Lana Salameh, targets Amazon Bedrock AgentCore, the managed AWS service for deploying AI agents with their tools, memory and identity handling.
The headline claim is stark. Starting with nothing more than the ability to chat with a single exposed agent, the researchers say they obtained that agent’s temporary AWS credentials and used them to reach all the other AgentCore agents sharing that account and region. They report reading private conversations, copying agent container images, invoking internal agents they were never meant to touch, retrieving secrets and planting memories that changed how agents behaved in future sessions.
Zenity flagged the metadata issue on 25 December 2025, followed by the over-broad default role on 12 January 2026. AWS switched newly deployed agents to IMDSv2 only from 14 February and in April labelled the first report “informative” before closing it. Zenity says the role was still unchanged in June, and by its final check on 29 September the riskiest permissions were gone. There is no CVE.
AWS rejects the framing. Its statement calls the behaviour “documented and expected”, says agents can access their own role’s credentials through the metadata service, and places responsibility for scoping each role tightly on customers.
The technical picture
The chain combines three weaknesses, none of them new, which is exactly why it matters.
First, reachability. Each AgentCore agent runs inside a Firecracker microVM, and Zenity found that network isolation did not stop the agent’s own outbound requests reaching the instance metadata service on its link-local address. Any URL-fetching or shell tool therefore becomes a server-side request forgery primitive. A plain-language request to retrieve a particular address was enough. At the time, the service still answered the older IMDSv1 style of request, which needs no session token.
Second, privilege. The default execution role was not tied to one agent. Zenity says it covered AgentCore resources across the whole account and region, including permission to list log groups (which revealed every agent ID), pull container images from ECR, invoke any agent runtime, list memory events (which exposed users’ conversations), and call both the AgentCore API key retrieval function and Secrets Manager. That last pairing matters because those managed stores are where developers are told to keep tool credentials away from the agent.
Third, persistence. With write access to long-term memory, the researchers inserted a fake conversation event that the memory system treated as a standing user instruction. In their demonstration, it told the agent to consult an attacker-controlled web page before each answer, giving them a way to change the agent’s behaviour remotely while users carried on chatting normally.
Dark Reading reports Sharbat comparing the pattern to the 2019 Capital One breach, which also turned on metadata credentials and excessive privilege. That comparison is fair. It is an old cloud failure mode with a new front door: an obliging language model.
Why it matters for UK organisations
UK banks, insurers, retailers and public bodies are moving fast from chatbot pilots to agents wired into internal systems, often on AWS. Customer-facing support agents are exactly this kind of exposed entry point, and their conversations routinely contain personal data.
That has regulatory weight. Under UK GDPR, controllers must apply security appropriate to the risk, and an attacker silently reading every customer conversation across an organisation’s agents would be a reportable personal data breach. Blaming a generous default role is unlikely to impress the ICO when the provider’s documentation said to scope it down.
The UK’s own guidance already points in the right direction. The NCSC-led Guidelines for Secure AI System Development and DSIT’s AI Cyber Security Code of Practice both stress least privilege, secure defaults and treating model inputs as untrusted. AgentCorruption is a practical example of what happens when those principles are assumed rather than verified.
Expert view
When we test cloud environments, the metadata service and over-permissive roles remain among the most reliable routes from a single foothold to wider access. What changes with agents is the delivery mechanism. You no longer need a classic SSRF bug in someone’s code; you need an agent with a fetch tool and a model willing to follow instructions. Treat prompt injection as a given; the real design question is what an attacker can reach once the model complies.
I have some sympathy with AWS’s position that the behaviour is documented. But documentation does not set defaults, and defaults are what most teams ship. A managed service that attaches a region-wide role to every agent is making a security decision on the customer’s behalf. It is welcome that AWS has narrowed that role, although up to nine months between report and fix is long for an issue of this blast radius, and customers with agents deployed before the change should not assume they inherited the fix.
In my experience, organisations that weather findings like this already treat every non-human identity as an account with an owner, a defined scope and monitoring. Agents belong in that inventory.
What to do now
- Inventory your agents. List every AgentCore runtime, and any other agent platform, across all accounts and regions, noting which are internet-facing and which tools each can call.
- Review execution roles. Check whether agents created before the September change still use broad or legacy roles. Scope each role to a single agent and the specific resources it needs (Cyber Essentials: user access control).
- Enforce IMDSv2 and block metadata where possible. Confirm agents use token-based metadata access and restrict tool egress so fetch and shell tools cannot reach link-local or internal addresses (Cyber Essentials: secure configuration and firewalls).
- Separate public and internal agents. Run customer-facing agents in separate accounts from agents with access to sensitive systems, so one compromise cannot cross the boundary.
- Protect memory and secrets. Limit who can write to agent memory, review stored memories for unexpected instructions, and rotate any secrets an over-privileged agent role could read.
- Monitor agent identities. Alert in CloudTrail on agent role credentials used from outside AgentCore, and on unusual Secrets Manager, ECR or memory API calls.
- Test it. Include prompt injection leading to cloud credential access in AI and cloud penetration test scopes.
Bottom line
AgentCorruption is less a novel AI flaw than a reminder that agents inherit every weakness of the cloud they run in, and that a helpful model can turn a single chat window into a skeleton key. Whether or not AWS calls it a vulnerability, UK organisations deploying agents should assume prompt injection will succeed and make sure the credentials behind each agent are too narrow to matter when it does.
Sources
- Zenity Labs: AgentCorruption: How A Single Prompt Collapsed The Entire Cloud Security Model
- The Register: AWS AgentCore security undone by prompt requesting credentials
- Dark Reading: ‘AgentCorruption’ Puts AWS Environments At Risk With Single Prompt
- The Next Web: Zenity’s AgentCorruption research on AWS AgentCore
