Written by Jeremy Souffir Founder, JTS Tech Services
The short version, and the direct answer if you read nothing else. On 8 October, Zenity Labs published research it calls AgentCorruption, on Amazon Bedrock AgentCore, AWS's managed service for running AI agents. The researchers sent a prompt to a public-facing support agent asking it to fetch a particular internal web address. The agent had a tool for making web requests, so it did, and what came back were the temporary cloud credentials the agent runs under. The credentials themselves were not the disaster. What they were attached to was: according to Zenity, the default role covered AgentCore resources across the whole account and region, not just that one agent. With it, the researchers could find the other agents, invoke them, read their users' conversations, plant instructions in their memory and reach secrets. AWS says this is "expected and documented behavior" rather than a vulnerability. We think AWS is technically right, and that is the reason this is worth your time. Nothing had to break. The agents were simply all wearing the same badge.
What did the researchers actually do?
- The way in was the front door. A support agent anyone could talk to, with a tool that fetches web pages. A prompt asked it to fetch the cloud's internal metadata address, which hands out the credentials of whatever is running. Security people call this server-side request forgery; in plain English, the agent was talked into asking its own building for its keys.
- The keys opened more than one door. Zenity reports the default role behind AgentCore agents was scoped to the account's whole region. From one agent they could list the others, download their container images and source code, call internal agents that were never meant to be public, and read users' private conversations.
- The memory could be rewritten. The researchers wrote a fake conversation event that the platform's memory stored as a standing user instruction. It told the agent to visit a web page the researchers controlled before every answer and follow what it said, which meant they could change the agent's behaviour later just by editing that page.
- Secrets were in reach. The same role could read secrets, including API keys stored for the agents to use.
- No exploitation has been reported. Zenity's researcher told Dark Reading they have seen no evidence of this being used in the wild before the fix, partly because an outsider has a hard time knowing which agents a company runs.
Whose findings these are, and what AWS says
These are Zenity's findings, reported to AWS in December 2025 and January 2026 and presented at SecTor in Toronto this month. AWS disputes the framing: an agent using its own credentials is how the service is documented to work, and reaching another account needs permissions granted on both sides. AWS says new agents have used the stricter version of the metadata service since 14 February, and Zenity says that by 29 September AWS had removed the broad permissions from the default role. Both of those things can be true at once. The service did what it said. The defaults made one agent's mistake everyone's problem.
Why does "documented behaviour" matter more than a bug would?
Because a bug gets patched and then you are done. A default gets copied. Every team that built agents quickly on a shared role did nothing wrong by the documentation, and every one of them still has that shape running today unless somebody went back and changed it. Zenity's researcher also said he expects the metadata trick is not unique to AWS. Whatever platform your agents run on, the question is the same: if the most exposed agent you have is talked into doing something it should not, what else can it touch?
In most growing companies the honest answer is "everything the other agents can", because they were built the same afternoon by the same person with the same credentials. The support bot on the website, the agent that drafts quotes from the CRM, the one that reconciles invoices. Three jobs, one identity. The support bot is the one strangers talk to all day, and it is the one that sets the ceiling for the other two.
The two conclusions that both get this wrong
We are not on AWS AgentCore, so this is someone else's news
The platform is the example, not the lesson. Agents built in workflow tools, on other clouds or in your own code very often share one service account, one API key or one connection to the CRM, because that is the quickest way to get the second agent working once the first one does. Zenity is already looking at other cloud platforms. The question below applies wherever your agents live.
AWS fixed the default, so we are covered
AWS changed the default for the future. A role you already created, or copied into your own setup, keeps whatever permissions it had on the day you made it. And the narrower default does nothing about the pattern of several agents sharing one role that a developer chose on purpose. If your agents were deployed before mid-February, it is also worth checking which version of the metadata service they use, rather than assuming.
What is worth checking this week?
- List your agents and what each one runs as. One line per agent: what it does, who can talk to it, and which role, account, key or connection it uses. If two agents share a line in the last column, that is the finding.
- Give every agent its own identity. One role or service account per agent, holding only what that agent's job needs. It is a little more setup on day one and it is the single change that turns "one prompt, every agent" into "one prompt, one agent".
- Treat public agents as untrusted by default. Anything a stranger can talk to gets the smallest set of tools you can manage, no tool that fetches arbitrary web addresses unless it truly needs one, and if possible a separate account or project from your internal agents.
- Keep secrets out of the agent's reach. An agent should be able to use a connection without being able to read the key behind it. If your agents can read your secrets store, narrow that first.
- Look at what your agents remember. If a platform gives agents long-term memory, someone should be able to see what has been stored and clear it. An instruction planted in memory outlives the conversation that planted it.
- On AWS specifically, check your AgentCore execution roles against AWS's own least-privilege guidance and confirm your agents are on IMDSv2. Ten minutes for whoever runs your AWS account.
The genuinely encouraging part
Nothing in this research needs a new product to fix. Separate identities, narrow permissions and keeping public-facing systems apart from internal ones are the same habits that already protect your web servers and databases; agents just arrived fast enough that many teams skipped them. And the work is cheapest now, while most companies have three or four agents rather than thirty. Splitting one shared role into four takes an afternoon. Splitting it after the twentieth agent depends on it is a project.
Where we fit
This is a build problem, and the fix is in how agents are wired: who each one runs as, which tools it gets, and what sits between the public ones and everything else. That is what our AI Ops Automation Sprint is for. In a short fixed-scope engagement we inventory the agents and automations you already run, give each one its own narrowly scoped identity, separate anything customer-facing from your internal agents and data, move secrets out of reach, and leave you with a one-page register of what runs as what. If you are about to build your first agents, we build them that way from the start, so the support bot on your website can only ever be a support bot.
Sources
- Zenity Labs: AgentCorruption: How a single prompt collapsed the entire cloud security model (8 October 2026, the primary research write-up and disclosure timeline)
- Dark Reading: 'AgentCorruption' Puts AWS Environments At Risk With Single Prompt (8 October 2026, updated 9 October with AWS's statement; no exploitation seen in the wild)
- The Next Web: One prompt let researchers take over every AWS AgentCore agent in a region (8 October 2026, memory poisoning detail and the 14 February IMDSv2 date)
- AWS documentation: Credentials management in Amazon Bedrock AgentCore (AWS's own guidance on execution-role credentials and least privilege)
- JTS Tech Services: Your AI agents are anonymous traffic inside your own SaaS stack (26 August, static keys and agent identity)
- JTS Tech Services: Half of every AI vulnerability disclosed this year is in the layer that connects your tools (2 October, the connector and workflow layer)
- JTS Tech Services: Your AI agent is a brilliant employee who believes everything it reads (prompt injection explained)
