The fix shipped without a version number

The most-quoted number from Zenity Labs' 8 October 2026 disclosure is that one prompt reached every Amazon Bedrock AgentCore agent in an AWS account and region. The number that should worry you more is 278 — the days between the report and the day researchers observed the permissions narrowed. The transport-level hardening took 51. A software defect gets a patch, a version and an advisory; an over-broad IAM grant gets none of those, which means your blast radius on a managed agent runtime changed twice without appearing in any channel you could subscribe to.

At a glance

Four stages, each a documented feature rather than a bug. Zenity's four-part write-up and the accompanying press release are the primary sources; the disclosure carries no statement from AWS and no CVE identifier.

Stage	What it used	What it yielded
Metadata access	A prompt instructing a public-facing agent’s web-request tool to query the instance metadata service	Temporary credentials for the agent’s execution role
The default execution role	Nothing — the permissions were already attached	Discovery and invocation of other agents, reads of private conversations, container-image pulls, across the account and region
Secrets Manager	The same credentials, used as intended	Secrets for whatever else those agents were wired into
Memory poisoning	Write access to another agent’s memory	Planted instructions sending future conversations to an attacker-controlled destination

The isolation boundary held at every step. The boundary that mattered was drawn around the credential, and it was drawn around the account.

The isolation was real, and it was not the control

AWS's own security documentation for AgentCore Runtime states that every session runs in its own Firecracker microVM, with no shared state and no shared filesystem. That is a strong claim and, as far as this research goes, an accurate one. Nothing in the chain is a hypervisor escape, a container breakout, or a shared-kernel side channel. The agent stayed exactly where it was put.

It did not matter, because the question "can agent code get out of the box?" and the question "what can agent code already do from inside the box?" are different questions with different answers, and only the first one gets asked when a platform is chosen. A microVM is an answer to containment. Containment and privilege are orthogonal, and vendors are not obliged to correct you when you hear the second in a datasheet that only promises the first.

The useful counterfactual for any managed runtime you are evaluating: assume the isolation is perfect and the breakout is impossible, then ask what a successful prompt injection achieves. If the answer is still "reads every conversation in the account", you have learned that the isolation tier was never the control you were relying on — and that upgrading it would have bought you nothing.

A grant has no patch, and the timeline proves it

Two fixes for one chain, with the cheap half shipping five times faster than the half that set the blast radius.

Zenity reported from 25 December 2025. AWS made IMDSv2-only the default for newly deployed agents from 14 February 2026, which closes the credential-read path for anything that cannot issue a token request first. Fifty-one days for a transport change is a respectable turnaround.

The permissions are the other story. Zenity reports the default role still largely unchanged as of June, and on 29 September 2026 — doing a final check days before publication — found that invoking other agents, reading private conversations and reaching Secrets Manager had been removed from it, with other permissions narrowed. The rollout date is not confirmed, so 278 days is when the change was observed, not necessarily when it happened. That uncertainty is itself the finding.

This asymmetry is structural rather than negligent. A code defect has a patch: ship it, and customers who update are fixed. An over-broad grant cannot be patched, only revoked — and revocation breaks every customer whose agent was quietly depending on it. Somewhere inside AWS, someone had to work out how many production deployments were invoking other agents or reading Secrets Manager through the default role on purpose, and that question is what turns seven weeks into nine months. Any vendor in that position faces the same arithmetic, which is why this is not a story about one cloud.

Nothing would have told you

Two of the three channels most organisations actually monitor had nothing to say on either date.

Put yourself on the customer side of this and ask what you could have known. No CVE was issued, so nothing in your vulnerability management reached it — and that is correct behaviour, not an oversight, because a permission attached to a role is not a software version with a defect. An entire class of exposure is therefore invisible to the scanning, SBOM and advisory machinery you already fund.

Release notes are no better. A default role is not a versioned artefact. It has no changelog you can diff, no semver to pin, and no deprecation window, so both the February change and the September change arrived as silent improvements to something you never recorded in the first place. Your exposure got worse than you thought and then better than you thought, and in neither direction did you have a baseline to notice against.

Which leaves one channel: the role itself. It was readable on any day of those nine months by anyone who went and enumerated what their own agent could do. That is an unsatisfying answer because it is a polling answer — nobody gets paged for it, and it will never appear in a dashboard by default. It is also the only one that works.

The memory stage is the part that outlives the fix

Three of the four stages end when the credential expires. The fourth does not. Zenity describes using the cross-agent access to plant instructions in another agent's memory, directing it to send future conversations to a destination the attacker controlled. Once that write has landed, revoking the permission that enabled it changes nothing: the instruction is now ordinary content in a store the agent is designed to trust and read on every session.

This matters for how you read the remediation. The permissions being narrowed in September fixes the reachability going forward. It does not inspect what was written during the window, and nobody can inspect it for you, because a poisoned memory is not malformed — it is a well-formed fact that happens to be a directive. Any organisation that ran an AgentCore agent with a memory store and a web-request tool during 2026 has a question to answer that the vendor's fix does not touch, and the only place to answer it is their own memory contents.

That is the general shape of agent-memory incidents: the credential is the entry, the memory is the persistence, and the two have different clocks. Treat a memory store as part of your incident scope and not as a cache, because an attacker who reaches it once does not need to reach it again.

What to change this week

Two of these are afternoons and two are quarters. Do the afternoons now, because the quarters are much easier to fund once you have the output of the first one on a page.

Measure the grant you already hold. In a non-production environment, give an agent a shell or fetch tool and ask it to print every credential identity reachable from inside its sandbox. Then enumerate what that identity can do using the cloud's own policy evaluator, not the documentation. Write down one sentence: an injected prompt in this sandbox authorises N actions across M resources. Run it twice — once against the platform default, once against your own role — because the gap between them is the only honest measure of whether anyone on your team has done any scoping.
Deny the metadata endpoint at the network layer. Not by hop limit, which the common container networking shapes need raised anyway, but as an explicit deny on the link-local address from the agent's network namespace. One rule, no cost if your workloads use file- or broker-delivered identity, and it closes the one channel reachable by an agent that has no shell and no filesystem access.
Diary the measurement, because the grant moves without you. Quarterly, and after every runtime upgrade. Grants change in both directions and silently; a number you took once is a number about last year.
Move the authority out of the sandbox. The destination is that the sandbox holds a proof of which run this is, and the entitlement lives in a credential broker outside it that mints per-tool, per-destination tokens against a policy. This is a quarter of work and it is the only change that makes the first bullet's number small rather than merely known.

The one thing not worth doing is treating this as an AWS story and checking whether your vendor is on the list. Every managed agent runtime delivers an identity into the workload so that the SDK calls work without configuration, every one of them ships a default role sized for the quickstart rather than for you, and none of them has a channel that will tell you when that default changes.

FAQ

Was this a prompt-injection vulnerability?

Prompt injection was the trigger, not the vulnerability. The prompt did nothing a web-request tool is not supposed to do; what made it a chain was the scope of the credential the request returned. Treating it as an injection problem leads to prompt-level mitigations that cannot help, because the next tool call will reach the same credential.

Is it fixed now?

The reachable permissions were narrowed, per Zenity's observation on 29 September 2026, and IMDSv2-only has been the default for newly deployed agents since 14 February 2026. Coverage of whether Zenity considers the overall remediation complete has been inconsistent, the disclosure includes no AWS statement, and no CVE was issued — so "fixed" is a claim you should verify against your own account rather than accept from any write-up, including this one.

Does a stronger sandbox help?

No. The microVM boundary held throughout. Upgrading from a container to a microVM addresses escape, and nothing in this chain was an escape. The axis that mattered was what the isolated workload was authorised to do.

We use a different managed runtime. Are we affected?

Not by this chain, but the structure generalises: if your runtime delivers a credential into the agent's environment and that credential's scope is set by a default you did not write, you have the same exposure with different names. The measurement in the previous section takes an afternoon and answers it for your own stack.

If no CVE is issued, how are we supposed to track this class of risk?

You cannot track it as a vulnerability, because it is a configuration. Treat the runtime's granted authority the way you treat any other setting a vendor controls on your behalf: record the resolved value, assert the permissions you depend on, and re-check on a schedule rather than on notification.

What about the agents we ran during the window?

The permission fix is forward-looking and does not examine what was written while the window was open. If you ran an AgentCore agent with both a memory store and a tool capable of HTTP requests during 2026, the memory contents are in scope for review, and a planted instruction will look like an ordinary remembered fact rather than like malware.