AWS AgentCore Flaw Let One Prompt Hijack All Agents

A browsing session on a site called TechHub turned into a full account takeover, according to research from Zenity Labs. The user asked an AI agent, served by Amazon Bedrock AgentCore, to fetch the contents of a URL. What came back was raw JSON from the cloud instance metadata service — and inside it, temporary AWS credentials. That was enough to reach every other agent in the same AWS account and region.

The researchers, Tamir Ishay Sharbat and Lana Salameh, described a chain of misconfigurations and defaults that together broke the isolation assumed to separate one customer's agent from the next. The account is fictional — Bob, Alice, and Eve on a site called TechHub — but the mechanics are drawn from a real disclosure to AWS in December 2025 and months of follow-up. AWS closed the report in April 2026 as "informative," and the excessive permissions remained at least until June 22, 2026. A final check on September 29, 2026, found the problems addressed.

What makes the episode notable is not a single bug but the combination of weak network isolation, credential exposure, and a default IAM role scoped far too broadly. Each piece is familiar on its own. Together they turned a chat interface into a path to the instance metadata service, and from there to the rest of the account.

How a prompt became a credential leak

The agent in the scenario ran on Amazon Bedrock AgentCore, and when Bob asked it to fetch a URL, the agent returned raw JSON from the Instance Metadata Service (IMDS). IMDS exists at cloud providers including AWS, Azure, and Google Cloud Platform to give instances and VMs details about themselves: region and availability zone, subnets, system images, security groups, public keys injected at spawn time, and in some cases user data and security tokens.

IMDSv2 is the hardened version, designed to blunt exactly this kind of abuse. But at the time of the browsing session late last year, AgentCore still used IMDSv1, according to the researchers. The metadata response included the agent's temporary credentials. Bob loaded them onto a local machine, enumerated the company's other agents in that AWS region, logged into the Amazon Elastic Container Registry (ECR), pulled the agent container images, and ran each as root to inspect the source code.

The same stolen credentials also exposed memory resources in the region, including those used by agents. From there the researchers describe extracting users and their agent sessions — the conversations themselves. The Zenity Labs team disclosed the findings to AWS in December 2025.

"We discovered that agents deployed through AgentCore could access their instance's IMDS endpoints," said Tamir Ishay Sharbat and Lana Salameh in a blog post. "This meant that an external attacker with nothing more than chat access to a single exposed agent could send a single prompt, extract its IMDS credentials, and use them to take over all AgentCore agents in the same AWS account and region."

— Tamir Ishay Sharbat and Lana Salameh, Zenity Labs researchers

Firecracker isolation fell short

The root problem, as the researchers explain it, is that the Firecracker MicroVM used by AgentCore did not provide sufficient network isolation. That gap let an attacker direct the agent to perform a server-side request forgery (SSRF) attack and fetch temporary AWS credentials for the IAM role assigned to the workload.

SSRF is not new, and agent platforms are not the first systems to be tripped up by it. But the architecture of agent runtimes changes the blast radius. An agent is designed to fetch things, follow instructions, and act on the user's behalf. When it can reach the metadata endpoint, the line between "the agent did what it was asked" and "the agent was tricked into leaking credentials" gets very thin.

The researchers note that the MicroVM was intended to keep workloads separated. The failure was not a missing feature but an isolation boundary that did not hold under a crafted prompt. That matters because the attack required no exploit binary, no memory corruption, and no privileged access — just chat access to a single exposed agent.

Overpermissioned by default

The second half of the problem was permissions. The default AgentCore role was scoped to all AgentCore resources in the region rather than to a single agent, according to Zenity. That means anyone holding the temporary IAM credentials could launch other agents, read sessions, write agent memories, and fetch secrets from AWS Secrets Manager.

The researchers followed up with AWS in January 2026 with details about AgentCore being overprivileged. On April 12, 2026, AWS responded that the report was "informative" and closed it, noting that as of February 14, 2026, AgentCore had been updated to use IMDSv2 exclusively. That change removes the IMDSv1 path, but it does not shrink the IAM role.

Zenity checked in on June 22, 2026, and found the excessive permissions still in place. A final review on September 29, 2026, found that AWS had addressed the remaining problems, clearing the way for the research to be published.

Persistent memory, persistent risk

The most consequential capability in the chain is not reading sessions but writing them. Agent memory is designed to persist across conversations, so a compromised agent can alter how future sessions behave. Zenity describes using IMDS credentials to send API requests that create new memories across different agents and users, persistently altering agent behavior and hijacking goals in later sessions.

"By leveraging the IMDS credentials we could send direct API requests to create new memories across different agents and users," said Sharbat and Salameh. "These in turn would persistently alter agent behaviour and hijack the agents’ goals across future sessions."

— Tamir Ishay Sharbat and Lana Salameh, Zenity Labs researchers

That turns a credential leak into a durable compromise. An attacker who only reads data leaves a trail that ends when the credentials expire. An attacker who writes memories changes what the agent does next time — potentially after the original access is gone. For teams that treat agent memory as a convenience feature rather than a security boundary, that is the uncomfortable part.

AWS disputes the framing

Amazon pushed back after publication. The company wrote in to say that Zenity's research misrepresents documented behavior as a vulnerability, suggesting that developer error would be required to enable the attack. The Register said it asked for clarification because that is not the scenario Zenity described.

That disagreement matters for anyone trying to decide how much weight to give the findings. AWS's position is essentially that the behavior is expected if a developer configures things a certain way. Zenity's position is that the defaults and isolation boundaries themselves were the problem, and that no special developer mistake was needed beyond deploying an agent and giving it chat access.

The timeline offers some context. IMDSv2 became the only option for AgentCore on February 14, 2026. The permission scoping issue was still open in June. AWS closed the initial report as "informative" in April. The final review in September found the issues resolved. Both the remediation and the dispute are real, and they point in slightly different directions.

The numbers behind the disclosure

The timeline and the scope of the findings can be read as a sequence of dates and checks:

• December 2025 — Zenity Labs disclosed the IMDS credential exposure findings to AWS.
• January 2026 — Zenity followed up with details about AgentCore being overprivileged.
• February 14, 2026 — AgentCore updated to use IMDSv2 exclusively, per AWS.
• April 12, 2026 — AWS responded that the report was "informative" and closed it.
• June 22, 2026 — Zenity checked in and found excessive permissions not remediated.
• September 29, 2026 — Final review found AWS had addressed the remaining problems.

Those dates are the spine of the story. They show a disclosure, a partial fix, a disputed close, months of unresolved permissions, and a final cleanup. They also show why the researchers waited before publishing: the permission issue was live well after the initial report was closed.

What agent deployers should check

For teams running agents on AgentCore or similar platforms, the practical lesson is to treat the agent runtime as part of the attack surface, not as a managed black box. The specific items Zenity highlights are worth auditing directly:

• Whether the agent can reach the instance metadata service, and whether IMDSv2 is enforced.
• Whether the IAM role attached to the agent is scoped to a single agent or to the whole region.
• What the agent can do with credentials it obtains — launch agents, read sessions, write memories, or fetch secrets.
• Who has chat access to the agent, since that was the only access the attacker needed.

None of these checks require a security team to reverse-engineer the platform. They map to configuration and access questions that owners of the deployment can answer. The harder part is treating memory and session data as sensitive stores, because that is where the persistent damage lives.

Why this matters beyond one account

Agent platforms are being sold on the promise of autonomy, and autonomy means the agent can act. The Zenity findings suggest that when an agent can act on a user's behalf, it can also be asked to act against the user's interests — and a single prompt may be enough. That is a different risk profile from a traditional web app, where the attack surface is usually narrower and the request path more predictable.

For businesses, this could mean that deploying an agent is not just a product decision but an identity and permissions decision. The credentials an agent carries and the role it runs under determine what a successful prompt injection can reach. The scoping question — one agent versus all agents in a region — is the difference between a contained incident and an account-wide one.

For the industry, the dispute between AWS and Zenity is a reminder that "documented behavior" and "safe default" are not the same thing. If a platform ships with broad permissions and weak isolation, the burden falls on every customer to tighten it. That is a familiar pattern, and it does not resolve itself as agent adoption grows.

For now, the immediate advice is unglamorous: verify that IMDSv2 is in use, narrow the agent's IAM role, limit chat access to agents that need it, and treat agent memory as data worth protecting. The research shows what is possible when those steps are skipped. The remediation shows that they can be fixed. The remaining question, for anyone running agents today, is whether the same assumptions that held last year are still holding in their own account.