AgentCorruption: Zenity saw the AgentCore default role narrowed 260 days after its report; no AWS notice found

260 days from report to a role change that only the researchers report

Zenity Labs says it told AWS on 12 January 2026 that the default execution role for Amazon Bedrock AgentCore agents reached far beyond the agent holding it. It says it saw that role substantially narrowed on 29 September 2026, in a final review before publishing. The gap is 260 days (derived: 12 January to 29 September 2026). Zenity published five posts on 8 October 2026, and Dark Reading reported the SecTor 2026 talk the same day as a "now-patched" flaw that could let an attacker "take over an organization's entire fleet".

What that fact does not establish matters more. The change is Zenity's observation of one role, not an AWS announcement. In the places AWS publishes security notices, nothing names the flaw. A search of AWS's bulletin directory on 9 October 2026 returned seven bulletins that mention AgentCore out of 306 in the archive: six concern the starter toolkit, the CLI or the Python SDK and one concerns the managed harness. None concerns the runtime's metadata service or its default role. The AgentCore release notes carry no entry on either. The National Vulnerability Database returns no record for the name. Dark Reading's article carries no AWS statement.

So "patched" here covers three different changes with three different kinds of evidence, set out below, and none of them tells a customer whether the roles already attached to its own agents changed. The reach is also smaller than "fleet" sounds. Zenity's wording is "all AgentCore agents in the same AWS account and region". Its posts describe a test agent Zenity deployed itself, give no count of agents, tools or customers, and do not say that any customer's agent was reached.

What is stated, by whom, and what is not

AWS describes AgentCore as an agentic platform built from modular services. The ones in play are Runtime, where each session runs in an isolated microVM, Memory, which holds short-term and long-term context, and Identity, which holds the credentials agents use for outside tools. Zenity's route starts at Runtime, through the microVM's metadata service, and reaches Memory and the stored credentials through the permissions of the agent's execution role.

The table separates Zenity's five posts, AWS's own pages and Dark Reading's report. Where only the news piece says something, the cell says so. Zenity is the firm behind the research and the only source for the demonstrations; no AWS page found addresses them.

Claims about AgentCorruption, with the source that makes them, read on 9 October 2026. Day counts are derived from the dates shown.

Question	Stated, and by whom	Not stated
Dates	Zenity: first report 25 December 2025 (one post also says 17 December), second report 12 January 2026, AWS reply 12 April 2026 closing the first as "informative", posts 8 October 2026.	Why the first report has two dates. Any AWS date for changing the role.
Components	Zenity: the per-session microVM, its metadata service and the default execution role, then Memory and stored credentials through that role's permissions.	A root cause beyond the researchers' words. Which tool or console path made the role Zenity checked.
What one prompt means	Zenity: one plain-language request to an exposed agent with a web-request or shell tool returned its role credentials. Later steps used those credentials with AWS's normal APIs from Zenity's own machine.	A demonstration on any customer's agent. Any path where one agent's output instructs another agent.
Reach	Zenity: all AgentCore agents in the same AWS account and region.	A count of agents, tools or tenants. Any reach into another account.
Customer action	Zenity, relaying AWS: new agents launch with the stricter metadata version as of 14 February 2026. AWS docs: every runtime must enable it from 30 June 2026 or invocations fail.	Whether AWS switched existing agents. Whether roles already in customer accounts were changed.
CVE	None named by Zenity or AWS. NVD on 9 October: 0 records for "AgentCorruption"; 8 for "AgentCore", none about this.	Whether AWS treats it as a vulnerability. Zenity says AWS closed report one as "informative".
Exploitation and impact	Dark Reading only: the researcher said Zenity has seen no evidence of exploitation before the fix, and cited "security through obscurity".	Any AWS statement. Anything in Zenity's posts. Any customer count, notification or detection.
Regions	AWS release notes, May 2026: AgentCore Runtime is available in 15 AWS Regions. Zenity's examples show one region.	Whether the fixes cover every region.

One prompt, then stolen credentials: where a prompt is and is not involved

Zenity's overview says an external attacker with "nothing more than chat access to a single exposed agent" could extract the agent's credentials and use them against the other agents in the account and region. The diagram sorts what the posts describe from what AWS's pages state. Only the second step is a prompt.

Three details change how the story reads.

The prompt is the smallest part. Zenity says that after the first step "no further interaction with the agent" was needed: the rest was stolen credentials used on AWS's normal APIs. The posts show the researchers calling a second agent as an ordinary client, not one agent steering another. This is not the multi-agent trust abuse pattern, where one agent's output reaches another as an apparent instruction, because no post shows that. It is the confused deputy escalation pattern at the first hop: the agent acts with a service identity broader than any visitor, and the visitor inherits it. The NCSC's 8 December 2025 post calls a language model an "inherently confusable deputy".

The memory demonstration is hedged by the researchers themselves. Zenity says it could write events into other agents' memory and that the memory's strategies could turn them into long-term records. It also says success "depended on the content surviving extraction and being retrieved by the agent". That is the site's memory poisoning pattern, shown by the researchers. The posts describe no customer's memory being altered.

Some of what the metadata service returned was AWS's, not the customer's. Zenity says the service returned mutual-TLS credentials issued for an AWS internal service, which it says it could verify, and a pre-signed link to storage outside its own account. The posts do not say what, if anything, those allowed, and AWS has not said whether they were rotated. Zenity also reports that a runtime's environment variables, which can hold model-provider API keys, were readable the same way. Its example names OpenAI, and the same paragraph names Anthropic as another provider. The point is only that a key held in an agent's environment is a key the agent can be talked into handing over.

What AWS's own pages say, and the word "isolated"

None of AWS's pages is a statement about AgentCorruption. Read together, they show where AWS puts the line.

AWS pages read on 9 October 2026: the AgentCore developer guide, release notes and security bulletins. Quotations are short extracts.

Page	What it says	What it leaves open
Credentials management	Role credentials reach code in the microVM through a metadata service, and "any code or actor running inside the VM can access these credentials". Scope the role with care.	Names LLM-generated code as the reason to limit permissions. Does not mention an agent prompted into making a web request.
Security best practices: MMDSv2	From 30 June 2026 every runtime must have the stricter metadata version enabled or invocations are rejected. The fix is an update to the runtime. Existing sessions are not affected.	When the page was written. Whether AWS enabled it on existing runtimes.
IAM permissions and best practices	Policies the CLI creates are for development and testing and are "not suitable for production". Use custom least-privilege policies.	How many deployments use the generated policies.
Shared responsibility	AWS: microVM isolation at the hardware level, kernel patching, network infrastructure. Customer: IAM access controls, input validation and prompt injection prevention, network configuration.	Neither list names the metadata service or the default role.
Release notes, July 2025 to October 2026	No entry on the metadata version or the default role.	Silence is not proof that nothing changed.
Security bulletins	None on this issue. Bulletin 2026-072-AWS, on a different flaw in the open source shell tool Zenity used, advises running agents that use it in an isolated, least-privilege environment.	That bulletin does not concern AgentCorruption.

The comforting words are "isolated", "session isolation" and "sandbox". AWS says each session runs in a dedicated microVM with its own CPU, memory and filesystem, and nothing Zenity published disputes that. What the microVM is handed is a separate matter. Compute isolation says nothing about what the attached role can reach, and Zenity's complaint is narrower: the microVM did not stop requests to the metadata service, and the default role was wide. A label that is true of the compute is not a control on the identity.

The same shape appeared in brief 148. AgentCore's Code Interpreter Sandbox mode was described as having no external network access while DNS queries still left it, and AWS's answer was to change the wording to "limited external network access". For a customer who configured the mode on the strength of the old label, the behaviour was what counted.

"Patched" covers three changes, and the third is yours to check

On 25 February 2026 AWS told Zenity that its team was working on the underlying issue, and the default role stayed the same. Zenity re-checked the role on 22 June 2026 and found it unchanged, 161 days after its report (derived). Each change behind the word "patched" has its own evidence.

The three changes behind the word "patched", with the evidence for each. Day counts are derived from the dates shown.

Change	Evidence	What it leaves open
Metadata version, new agents	Zenity relays AWS's reply of 12 April 2026: as of 14 February 2026 new agents launch with the stricter version. That is 51 days after the 25 December report.	Existing agents. Whether Zenity re-ran the first step afterwards: its posts do not say it did.
Metadata version, all runtimes	AWS docs: required from 30 June 2026, 136 days after 14 February.	Whether AWS or the customer made the change on older runtimes. When the page was written.
Default execution role	Zenity saw permissions for running other agents, reading private conversations and reading secrets removed on 29 September 2026, 260 days after its second report and 9 days before publication.	Which creation path made the role it checked. Whether roles already created were changed.

The stricter metadata version is a hurdle for forwarded requests, not a policy. AWS's EC2 documentation describes the equivalent service as session based: a first request obtains a token that later requests must present. A tool that lets the model choose how a request is made is a different case from a simple forwarded one. That is this briefing's inference, and neither Zenity nor AWS tests it for AgentCore. It is the reason to scope the role and not to rely on the version.

A role is an object in the customer's own account, so a change to a default is not a change to roles that already exist. AWS's open source starter toolkit, which generates roles of this kind, shows how a default moves. In a pull request merged on 27 July 2026 and listed in release 0.3.11, the generator stopped granting invocation of every runtime and access to every memory in the account and region, and scoped both to the agent's own name. The template in release 0.3.10 of 30 June and the one in release 0.3.14 of 6 October differ in those two places, among others. That changes what the tool writes next time. Nothing in the pull request says it edits roles already written.

The same 6 October template still holds a statement allowing reads of every identity-provider secret under the default token vault in the account and region, and a statement allowing the listing of all log groups. Zenity prints statement labels that match the toolkit's, which suggests, as an inference, that its role came from this tool. Yet it says secret reads were removed from the default role it saw on 29 September. The posts do not say which creation path it re-checked, so the two cannot be reconciled from the record. According to AWS's bulletin of 6 October the toolkit has been deprecated since 27 March 2026, yet it is still shipping releases.

A second team reported the same class in November, and AWS answered with a warning

Palo Alto Networks' Unit 42 reported to AWS on 17 November 2025, 56 days before Zenity's second report (derived), that roles the starter toolkit creates automatically grant privileges across the account rather than to one agent. It published on 8 April 2026. It starts from an agent that is already compromised, so it is not the metadata path, but it is the same class: the role decides the blast radius. Unit 42 quotes AWS's security team saying the roles generated by the auto-create feature "should never be used in a production system", and says AWS added a warning to its documentation.

AWS's public position on the role is therefore 183 days older than Zenity's posts (derived: 8 April to 8 October). Part of the news is a vendor tightening a default it had already told customers not to rely on. The advice that follows was available all along: write the role yourself.

Both firms sell in this space. Zenity announced security and governance for AgentCore on 2 December 2025, 23 days before its first report to AWS (derived), and Unit 42's article lists Palo Alto Networks products. That does not weaken demonstrations that are specific and, in part, checkable against AWS's own template and pages. It is why this briefing leans on AWS's pages for what AWS states.

UK reading: a cloud agent runtime is a boundary you cannot test, so test the role

A customer cannot inspect or test the microVM or the metadata service behind it. AWS's pages put microVM isolation on AWS's side of the line, and the role, the agent's code and tools, the network settings and prompt injection prevention on the customer's. So the testable surface is the part Zenity's route ends on: what an agent can be talked into doing, and what its role lets it touch.

UK-relevant sources, with their dates. The NCSC posts are interim advice, not a standard. Cyber Essentials was read from the NCSC's requirements document.

Source and date	What it says	What it leaves open here
NCSC, Managing the cyber risk of agentic AI, 20 August 2026	Every agent should have its own unique identity, with only the permissions the task needs and the shortest credential lifetime. Deny network traffic by default and allow by exception. Treat agent activity as user activity in monitoring. Evaluate built-in sandboxing for your use case. The NCSC says formal guidance will supersede the post.	Names no cloud platform and not this research. Does not say what a managed runtime must provide.
NCSC, Prompt injection is not SQL injection, 8 December 2025	Prompt injection is a residual risk to be reduced, not removed. Treat the model as an inherently confusable deputy and rely on deterministic safeguards that constrain what the system can do. Log tool use and API calls.	Does not say how to apply this to a managed agent platform.
Cyber Essentials, requirements for IT infrastructure v3.3, April 2026	Cloud services must be in scope, and the applicant organisation is "always responsible for ensuring all controls are implemented", whoever implements them. User accounts should reach only what the role needs, and third party accounts are included.	The wording is about user accounts. It does not mention AI agents or machine roles, so whether an agent's execution role counts is not stated.
ISO/IEC 42001 (paywalled)	This briefing makes no claim about clause text. The site's [readiness tool](https://www.pk-sharma.com/tools/iso-42001-readiness) lists a third-party and customer relationships item, described as allocating responsibilities across the AI supply chain and assessing suppliers.	That is the tool's description, not the standard's wording.

That leaves five things inside the customer's control, each backed by a source above: a separate identity and role for each agent; the tools each agent may call, with web-request and shell tools the first to remove from anything public; limits on outbound network traffic; logs that record which role called which agent or memory; and a register of which agents exist, who owns them and what each can touch. Zenity says its role could list every agent in the region, so an attacker would have a complete list. An owner without a register may not.

Two earlier briefings connect where the facts do. Brief 175 covers a report in which an injected instruction itself travels between agents; AgentCorruption is the opposite case, because nothing travels between agents but credentials. Brief 206 covers a vendor that said it had notified over 100 organisations and published no list. Here the position is one step earlier: neither AWS nor Zenity says whether any customer was notified or affected.

What to do, in the order worth doing

Ordered by how quickly each step answers the question that matters: what could one talked-into agent touch.

What could not be verified

The question that exposes the gap

If one public-facing agent on your cloud platform were talked into handing over its own credentials tomorrow morning, which of your other agents, memories and secrets would that role let it reach, and would you learn of it from your own logs or from a researcher's conference talk?

Key facts