Zenity says one AgentCore prompt reached every agent in an AWS account. AWS calls it documented

What did Zenity publish on 8 October?

Zenity’s press release, datelined Toronto, 8 October 2026, says Labs researchers identified a chain of flaws in Amazon Bedrock AgentCore and named it AgentCorruption. The firm says a single prompt to one public-facing agent let them take over all AgentCore agents in the same AWS account and region, read private conversations, pull source from container images, retrieve credentials stored in AWS Secrets Manager, and plant memories that changed later behaviour. It says the findings were presented at SecTor 2026.

A same-day overview by Tamir Ishay Sharbat and Lana Salameh on Zenity’s Labs site repeats the account-and-region scope and points to four technical follow-ups. The Next Web’s 8 October story, timestamped 2:14 p.m. and later corrected, first used a region-wide headline that omitted the account limit. The correction, on the page we opened, says the research covered agents within a single AWS account and region.

This is a cloud-isolation story about agent tooling, not a new model card. For the general pattern of hidden instructions in text an agent is asked to fetch, see prompt injection. For why a tool boundary is not the same as a host boundary, see agent sandboxing.

What do the researchers say the chain was?

Zenity’s overview describes AgentCore agents as running in Firecracker microVMs. It says those VMs did not block traffic to the instance metadata service, so any agent tool that could make an HTTP request could be steered to that local endpoint and return temporary credentials for the agent’s execution role. The writers call that an SSRF primitive. The follow-up “Initial IMDS Access,” by Lana Salameh and Dmitry Lozovoy, says they used AWS’s open-source Strands SDK with a built-in request tool, then saw the same class of result through other outbound tools, including a shell tool.

The overview’s second claim is about the role those credentials unlocked. Zenity says the default AgentCore execution role was not scoped to one agent. It says the role could list agents, invoke other runtimes in the region, read session events, create memory events, pull Elastic Container Registry images, and read secrets. The press release adds that planted memories could send later conversations to an attacker-controlled destination while a user kept chatting.

We are reporting those as Zenity’s claims from pages we opened. We are not reprinting the prompts, listener addresses, or command sequences from the technical posts. Those posts are a researcher write-up of a method, not a checklist we verified.

What did AWS say?

The Next Web published a statement it says AWS sent after the first version of its article. An AWS spokesperson said the company “is aware of the research published about Amazon Bedrock AgentCore, which inaccurately paints expected and documented behavior as a vulnerability.” The statement says an agent can reach resources in another AWS account only if a developer grants permissions on both the execution role and the target. It recommends granting execution roles only the permissions an agent needs, and it points to AWS pages on IAM permissions, Runtime security best practices, IAM security best practices, and credentials management.

That is AWS’s position as carried by The Next Web on 8 October. We did not receive a separate statement. AWS’s wording is about cross-account access and least privilege. Zenity’s claimed blast radius is inside one account and region. Those are different boundaries. The vendor statement does not, on the text we have, concede or deny the in-account role width Zenity describes for the period it tested.

Vendor language that calls a write-up “documented behaviour” is a claim about the threat model, not a lab result. For how to keep a company sentence in its column, see how to read an AI company announcement. AgentCore also appears as a planned hosted runtime in AWS’s Physical AI Toolchain note; that is a robotics packaging story, not this disclosure.

What is on AWS’s AgentCore docs today?

The AgentCore Runtime security-best-practices page we opened on 9 October is explicit about metadata. Under session isolation it says any code or actor running inside the microVM can access execution-role credentials by calling the metadata endpoint, which it names MMDS, and that builders should scope the execution role. The same page says AgentCore CLI-generated IAM policies “grant broad access” and “are not suitable for production,” and it tells readers to write custom policies and avoid wildcard resources.

The IAM-permissions page we opened the same day still prints an example AgentCore Runtime execution-role policy whose ECR statement uses a repository resource of every repository in the chosen account and region, and whose logs:DescribeLogGroups statement uses every log group in that account and region. Those lines are on AWS’s documentation, not on Zenity’s blog. They are an example policy on a page that also says CLI policies are for development and testing. They are not a reproduction of Zenity’s demo.

The Runtime troubleshooting page we opened says that from 30 June 2026, invocations fail with a ValidationException unless the runtime has MMDSv2 enabled through UpdateAgentRuntime. That is a platform requirement on the page, not a claim that every older runtime has already been updated.

What does Zenity say changed after disclosure?

The overview’s disclosure table, which matches the press release on the first report, says Zenity sent the metadata finding on 25 December 2025. It says AWS replied on 12 April 2026, closed that report as “informative,” and noted that from 14 February 2026 new AgentCore agents launch with IMDSv2 only. A second report on the default role’s blast radius is dated 12 January 2026. Zenity says AWS wrote on 25 February that it was working on the issue while the default role stayed the same, that a 22 June review still saw the old permissions, and that a 29 September review before publication found the role had dropped permissions used to invoke other agents, read private conversations, and read Secrets Manager.

There is no CVE on the pages we opened. The Next Web repeats that. IMDSv2, in AWS’s own description to Zenity as restated on the Labs timeline, requires a session token for each metadata request. Zenity’s overview does not say the later role change was announced as a security bulletin. It says the researchers observed it on a final check.

What should operators take from the disagreement?

If you run AgentCore, the practical split is simple. Zenity says a chat-accessible agent with an outbound tool was enough, under the defaults it tested, to take the role and then the rest of the account’s AgentCore fleet in that region. AWS says that kind of access is what the execution role is for, that cross-account reach needs an explicit grant, and that customers should not ship broad roles. Both sides agree, in different words, that the role is the control that matters.

The docs we opened already tell you not to use CLI-wide policies in production, to require MMDSv2, and to assume in-VM code can see the metadata endpoint. That last sentence is why AWS can call the write-up documented and why Zenity can still call the default role a master key. Those are not the same judgement.

• Read the 8 October Zenity overview for the claimed chain and the dated AWS replies.
• Read AWS’s Runtime security and IAM pages for the current vendor rules, including the MMDS sentence and the CLI-policy warning.
• Check whether each runtime has MMDSv2 on, and whether its execution role is limited to that agent’s images, logs, and tools.
• Do not treat “no CVE” or “documented behaviour” as evidence that a broad role is safe.

What did we not see?

This is an evidence review of Zenity’s 8 October press release and two Labs posts, The Next Web’s corrected story with the AWS quote, and three AWS documentation pages opened on 9 October. We did not attend SecTor, did not receive a letter from AWS, did not deploy AgentCore, and did not run any prompt against a metadata endpoint. Treat the takeover narrative as Zenity’s, the vulnerability denial as AWS’s via TNW, and the MMDS and least-privilege language as what AWS’s docs say today.