AWS Says Its AI Agent Handing Over Passwords Is Working as Designed
Palo Alto Networks researchers found that Amazon's AI agent platform exposes plaintext credentials by default. AWS closed the report as 'informative'. Security teams carry the risk.
Key points
- Unit 42 researchers found that AWS AgentCore's built-in shell tool, which runs as root and is on by default, can be tricked into reading and exfiltrating plaintext passwords from the platform's own credential vault.
- A second Unit 42 finding, reported to AWS on 7 April 2026, showed that AgentCore's internal metadata service lacked session-token enforcement, letting attackers steal credentials through server-side request forgery (SSRF), a technique where a criminal tricks a server into fetching data it shouldn't share.
- AWS reviewed the September 2026 shell-tool report and closed it as 'informative', meaning the company considers the behaviour expected rather than a flaw it must fix.
- Zenity Labs found that the same platform would hand over credentials belonging to every agent in an AWS account, confirmed live and working outside AWS on 8 October 2026.
- AWS told CSO Online the behaviour is documented and expected; the shared-responsibility model places the burden of locking it down on the customer.
The most uncomfortable sentence in Unit 42's September 2026 advisory is also the shortest: "Nothing has to be misconfigured for this to happen. It is the out-of-the-box state."
That sentence describes AWS AgentCore, a platform Amazon built so companies can run AI agents: programs that make decisions and take actions automatically without a human approving each step. The platform includes a built-in shell tool that lets agents write files and run code. It's enabled by default. It also runs as root, meaning it carries the same unlimited system access an administrator would have.
How does the attack actually work?
An attacker tricks the AI agent with a prompt injection, a hidden instruction buried inside content the agent reads, the same way someone might hide a command inside a document the agent is asked to summarise. The agent obeys the hidden instruction, invokes the shell tool, and reads the memory space where the platform has already decrypted stored credentials to plaintext. Those credentials, the keys and tokens that let the agent talk to other services, then leave.
Unit 42 was direct about why the design creates the problem. The shell tool's reach into memory is what makes it useful, and also what makes it dangerous the moment an attacker issues a command through a poisoned prompt.
| Finding | Reported to AWS | AWS response | Status |
|---|---|---|---|
| AgentCore shell tool reads plaintext credentials from memory by default | September 2026 | Closed as 'informative' under shared responsibility model | Customer's responsibility to disable shell tool |
| AgentCore Runtime MMDS lacked session-token enforcement, enabling SSRF credential theft | 7 April 2026 | Fixed | Patched |
| AgentCore accessed IMDS using the less-secure v1 protocol, exposing credentials | Reported December 2025 | IMDSv2 enforced 14 February 2026 | Initial vector patched; permissions issue found unchanged as of 22 June 2026 |
| AgentCore default role held read, write and delete permissions across agents in a region | Reported December 2025 | Not addressed until between June and September 2026 | Confirmed fixed by 29 September 2026 |
The second Unit 42 advisory, covering the network isolation bypass in AgentCore's Code Interpreter sandbox, adds another layer. That sandbox is supposed to stop an agent from reaching the open internet. Unit 42 found they could smuggle data in and out using DNS tunnelling, a technique where information is encoded inside the routine lookup requests computers make to find websites. The sandbox blocks traffic. It doesn't block lookups. That distinction is the entire attack. We first covered DNS tunnelling as an exfiltration technique in our 21 July 2026 story.
Should customers be worried?
Yes, but the worry needs to be specific. The credential-in-memory issue isn't a bug AWS has committed to fixing. AWS's position, repeated to CSO Online, is that agents accessing resources requires explicit permission grants and that customers should follow least-privilege principles.
That's technically correct. It also lands the burden squarely on the teams deploying agents, not the platform vendor.
This failure mode is a familiar one from cloud history: a permissive default that makes onboarding easy, backed by a shared-responsibility model that means the vendor isn't obligated to change it. The platform engineer who spun up AgentCore to get a proof of concept running last quarter probably left the shell tool on. Odds are the security team doesn't know the shell tool exists.
Frank Dickson, principal analyst at Dickson Research, told CSO Online that the memory poisoning angle worried him most: a poisoned memory turns a helpful agent into something waiting for the right instruction to do serious damage. You can rotate a stolen key. Knowing which stored memories to trust is a much harder problem.
Zenity CTO Michael Bargury, writing to CSO Online, put the core tension plainly: strong isolation and useful autonomy are at odds with each other, and enterprises need to plan their security controls around that conflict rather than expecting the platform to resolve it.
If your organisation is running AWS AgentCore, check whether the built-in shell tool is enabled. It probably is. Disable tools your agents don't need, audit what permissions your agent execution roles actually hold, and don't assume a February patch closed the door completely. Zenity found in June 2026 that the permissions problem was still open months after AWS thought it had fixed the initial access path.
The shell tool is on by default. Turning it off costs nothing. The post-mortem will say you should've done it on day one.
