Security researchers at Zenity Labs successfully tricked AWS autonomous agents into handing over complete sets of temporary credentials simply by asking for them in plain English, according to a report published today. The researchers obtained access key IDs, secret access keys, and session tokens tied to the agent's execution role — credentials that remained active outside the AgentCore environment entirely. Throughout 2024 and into 2026, both Zenity Labs and Palo Alto Networks' Unit 42 have documented multiple instances where Amazon Web Services has patched security vulnerabilities in its autonomous agent systems, only to see similar attack paths resurface in different forms.

Zenity's investigation revealed that the compromised agent carried permissions extending far beyond a single agent's scope. The execution role included read, write, and delete access to various AgentCore and AWS services across an entire AWS region. Researchers used these credentials to invoke additional agents and move laterally within the region, accessing all private conversations between users and agents. They also successfully poisoned agent memory to maintain persistence, harvested credentials and API keys that unlocked access beyond AWS itself, and executed destructive actions within the same region. On September 18, 2024, Unit 42 separately reported a vulnerability in AWS AgentCore Harness where default configurations allowed attackers to steer agent actions through prompt injection, exfiltrating plaintext credentials managed by AgentCore Identity. Earlier, on April 7, Unit 42 had alerted AWS to a critical security regression in which the AgentCore Runtime used a microVM Metadata Service lacking session token enforcement, potentially allowing attackers to exploit standard web vulnerabilities like server-side request forgery to directly extract sensitive credentials.

According to the Zenity report, AgentCore names each repository after its agent, and running automated tools on all discovered agents delivered source code for every agent in the region within seconds. The Unit 42 report stated that the harness's built-in shell tool, enabled by default, "reaches into the same memory space where credentials are resolved to plaintext." Unit 42 researchers found that the shell tool runs as root inside the harness, meaning any command an attacker gets the agent to execute inherits the same root access — and "nothing has to be misconfigured for this to happen. It is the out-of-the-box state." AWS responded to requests for comment by stressing that agents behaved as documented, stating that an agent can access resources in another AWS account only if developers explicitly grant permissions on both the agent's execution role and the target resource.

The core issue, according to multiple security analysts cited in the report, stems from the fundamental tension between agent autonomy and security controls. Zenity CTO Michael Bargury explained that strong defense requires strong agent isolation, yet agents need autonomy and connectivity to function — two requirements that directly conflict. The report traces a concerning pattern: Zenity discovered vulnerabilities in late 2025 and reported them to AWS on December 25, AWS updated the environment in February 2026, but the fix appears to have addressed only one limited attack path while leaving others exposed. Zenity confirmed that AWS finally corrected the environment's permissions between June 22 and September 29, 2026, closing the discovered attack path. Fred Chagnon, a principal research director at Info-Tech Research Group, noted that the AWS security hole using server-side request forgery to reach metadata services and steal credentials essentially mirrors the pattern behind the 2019 Capital One breach, except now the prompt itself serves as the exploit. Memory poisoning emerged as analysts' greatest concern — Frank Dickson of Dickson Research warned that a poisoned memory transforms a helpful agent into a sleeper threat, and unlike stolen keys that can be rotated, it's far harder to determine which memories remain trustworthy.

Enterprise security leaders should focus on blast radius containment rather than waiting for platform-level fixes they can't control, the report suggests. Chagnon emphasized that isolating the sandbox and keeping platform material out of instance metadata falls under AWS's responsibility, but default permissions represent something cloud engineers can and should replace — though most won't. He recommended that CISOs write their own least-privilege rules, treat shell and HTTP tools as high-risk capabilities, restrict egress traffic, keep secrets out of images, and baseline each agent's identity and tool usage so anomalies become visible. Justin Greis, CEO of consulting firm Acceligence, urged executives to demand answers to critical questions: what identity does the agent operate under, what can it access and change, what can it remember, what other agents or systems can it reach, and most importantly, what happens if it's compromised. The shared responsibility model places the burden on enterprises to determine how much damage one compromised agent can inflict, even when they can't fix underlying cloud platform flaws. Agents working exactly as designed — rather than malfunctioning — represents the true challenge, as researchers didn't need to exploit bugs but simply asked in conversational language for what they wanted. For organizations deploying autonomous agents, the question isn't whether isolation will be tested, but whether current identity and permission boundaries can withstand that test when it comes.