AWS Agent Flaws Expose Control Gap

Security researchers at Palo Alto Networks' Unit 42 and Zenity Labs have spent much of this year disclosing flaws in AWS's autonomous agent controls, only to see the same class of weakness resurface in a slightly different form. The pattern matters less for what it says about AWS's patching speed than for what it reveals about the difficulty of locking down AI agents that need broad access to be useful.

AgentCore's default shell problem

On September 18, 2026, Unit 42 researchers reported that default configurations in AWS AgentCore Harness could let attackers steer an agent's actions through prompt injection to exfiltrate plaintext credentials managed by AgentCore Identity.

The report described the flaw as a fundamental agentic trade-off — the access that makes an agent functional is the same access that creates risk.

"The harness's own built-in shell tool, which is enabled by default, reaches into the same memory space where credentials are resolved to plaintext," the report explained. "The built-in tools are a big part of what makes the harness so autonomous and productive. The agent can write files and run code to get real work done. But the same reach that makes the built-in tools useful makes them dangerous when people leave them on unintentionally."

The report added that the shell tool runs as root inside the harness, so any command an attacker convinces the agent to run inherits that same root access — with no misconfiguration required. AWS reviewed the finding and closed it as informative under the AgentCore shared responsibility model, according to Unit 42, leaving it ambiguous whether the hole was actually plugged.

An earlier credential exfiltration path

Months before, on April 7, Unit 42 had alerted AWS to a different path to credential exfiltration. That issue involved a critical security regression in which AgentCore Runtime used a microVM Metadata Service (MMDS) that lacked session token enforcement.

Prior to disclosure and AWS's fixes, Unit 42 wrote that the configuration could have allowed an attacker to exploit standard web vulnerabilities such as SSRF to directly extract sensitive credentials and put the entire environment at risk.

Zenity's live credentials test

Zenity Labs published its own report detailing findings that AWS agents surrendered credentials to an attacker who simply asked for them. Zenity said it obtained a full set of temporary STS credentials — an access key ID, a secret access key, and a session token belonging to the agent's execution role.

"These credentials aren't scoped to the sandbox. We exported them onto our own machine, outside AgentCore entirely, and confirmed they were live," the report said. The credentials included ECR read permissions, letting Zenity authenticate to the registry and pull the image, exposing the agent's source code and dependencies as root.

Zenity noted that the isolation failure was at the platform level, not the tool level, and that it reproduced the same result through several tools, including Strands' built-in shell tool. It also found that AgentCore names each repository after its agent (bedrock-agentcore-<agent_name>), so running an automated tool across discovered agents returned all source code of all agents in the region within seconds.

According to Zenity, the role held READ, WRITE and DELETE access to various AgentCore and AWS services across the region, enabling lateral movement, reading private conversations for all users and agents, poisoning memory, harvesting credentials and API keys, and running destructive actions.

A patch timeline that kept moving

Zenity's timeline shows researchers discovering much of this in late 2025 and reporting details to AWS on December 25. AWS responded with an update in February 2026, but Zenity said that fix may have closed only one limited path. Zenity confirmed that as of Oct. 8 the AWS environment's permissions had been fixed.

Tamir Ishay Sharbat, director of security research at Zenity, wrote in an Oct. 8 email that after the disclosures AWS updated AgentCore to use IMDSv2 only on Feb. 14, 2026, patching the initial entrance vector, but that on June 22 Zenity found the default role's permissions remained unchanged. Subsequent checks confirmed AWS fixed the permissions issue between June 22 and Sept. 29.

What defenders should weigh

Zenity CTO Michael Bargury said in an email that the challenge is that strong defense means strong agent isolation, yet agents require autonomy and connectivity to be useful. "The two are at odds with each other, as this research shows. Enterprises should be mindful of that inherent conflict, and plan their security controls accordingly," he said.

AWS declined an interview request but emailed a statement stressing that agents did what they were supposed to do and that the research inaccurately portrays expected behavior as a vulnerability. A spokesperson said, "AWS is aware of the research published about Amazon Bedrock AgentCore, which inaccurately paints expected and documented behavior as a vulnerability. An agent can access resources in another AWS account only if the developer explicitly grants permissions on both the agent's execution role and the target resource. As a best practice, we recommend that customers grant their execution roles only the permissions their agents need."

Analysts single out memory poisoning

Frank Dickson, principal analyst at Dickson Research, said the memory poisoning worried him most. "A poisoned memory turns a helpful agent into a Manchurian Candidate, waiting for the right conversation to send it somewhere it should not go. You can rotate a stolen key. It is much harder to know which memories to trust," he said.

Nik Kale, a member of the Coalition for Secure AI (CoSAI) and part of ACM's AI Security (AISec) program committee, agreed. "A stolen credential expires in hours, and a poisoned memory doesn't. It keeps steering conversations long after every key has been rotated," Kale said.

Old mistakes, new platforms

Fred Chagnon, a principal research director at Info-Tech Research Group, called the AWS agentic problems a lesson in how old platform configuration mistakes reappear in new ways. He said the SSRF path to the metadata service was essentially the pattern behind the 2019 Capital One breach, but with a different trigger: an agent with a shell or HTTP tool will fetch a URL when asked, so the prompt itself is the exploit.

Chagnon added that isolating the sandbox and keeping platform material out of instance metadata is AWS's job, while default permissions are something the cloud engineer can and should replace. He said CISOs should write their own least-privilege rules, treat shell and HTTP tools as high-risk, restrict egress, keep secrets out of images, and baseline each agent's identity and tool usage.

Designed behavior as the core issue

Dickson said the agents did not malfunction — they performed exactly as designed. He described a chain of familiar mistakes: an agent that can reach the network, a metadata service that answered with the agent's own cloud credentials, and a default execution role with excessive permission.

Kale said pulling credentials from a metadata service is cloud hacking 101, and what's new is that researchers did not need to find a bug. "They just asked the agent in plain English," he said. "Once that's possible, the strength of the sandbox walls stops being the interesting question. The real boundary is whatever identity the agent carries, and if that identity reaches across other agents, one conversation can impact an entire environment."

Justin Greis, CEO of consulting firm Acceligence, stressed the importance of controlling secondary data access, noting the amplification effect when one agent can be manipulated to reach far beyond itself.

Why this matters beyond AWS

The disclosures suggest that the shared responsibility model is being tested by workloads that behave more like delegated identities than static applications. If default permissions and platform-level isolation remain the weak links, enterprises may need to assume that any agent with network reach can become a pivot point — and design their controls around limiting how far that pivot can go.