Researchers reported multiple cases where AWS autonomous agents could be manipulated with prompt injection to reveal or extract cloud credentials. In demonstrations, the agent returned live temporary AWS credentials, enabling access to code, other agents, and sensitive data, showing how a single manipulated “conversation” can expand into broad cloud access if roles are over-permissioned.
Key findings
- Unit 42 reported that default AWS AgentCore Harness configurations could allow prompt injection to exfiltrate plaintext credentials.
- The built-in shell tool was described as enabled by default and capable of running as root, making credential access higher impact once the agent is steered.
- Unit 42 also described a path where SSRF could extract sensitive credentials due to missing session token enforcement in metadata access (prior to fixes).
- Zenity Labs reported obtaining live temporary AWS STS credentials from an agent, exporting them outside AgentCore, and using them to access container images and inspect source as root.
- Zenity reported that one compromised agent identity could be used to discover other agents and pull their code across a region, plus read private conversations, poison memory, and harvest additional secrets.
- Zenity indicated initial fixes addressed one entry path (IMDSv2-only) but permissions remained overly broad for months, increasing potential blast radius.
Who’s being targeted
- Commonly targeted roles: CIO/CISO leadership, Cloud Engineering, DevOps / Platform Engineering, AI/ML Engineering, Security Engineering / SecOps, Application Owners using AI agents.
- Affected industries: Cloud service providers, Enterprises using AWS Bedrock/AgentCore, Software/DevOps teams operating AI agents.
- Attack channels: website.
- Impersonated: Legitimate user/customer requesting diagnostics (no explicit impersonation stated), Legitimate user instructing the agent to run a command (no explicit brand impersonation stated), Legitimate user requesting inventory/automation across agents (no explicit impersonation stated).
Awareness takeaways
- Treat AI agents like privileged users: never allow agents to reveal secrets (keys/tokens) in responses, even for “debugging.”
- Disable or tightly control high-risk tools (shell/HTTP) by default; if they must exist, enforce strict boundaries and monitoring.
- Reduce blast radius with least-privilege execution roles per agent; avoid wildcard/default roles that can reach other agents or regional resources.
- Plan for long-lived manipulation risks (e.g., memory poisoning) and add controls for what agents can store/recall and how it’s validated.
Red flags to watch for
- Any request to share access keys/secret keys/session tokens is inappropriate
- “Debugging” requests that ask the agent to run shell commands or fetch unusual internal URLs/metadata
- Agent outputs that include credential-like strings (access key IDs, tokens)
- Agent has powerful tools enabled by default (shell/HTTP) without strict boundaries
- Requests to “print/show” secrets or environment variables
- Commands executed with elevated privileges (root)
- Requests that expand scope from one agent to “all agents in the region”
- Predictable resource naming that enables bulk discovery
- Overly broad permissions (READ/WRITE/DELETE) on default roles
Read the video transcript
Imagine our AWS AI agent casually pasting its own cloud keys into a chat window… to a stranger. Researchers did exactly this: they asked an AWS AgentCore Harness agent, in plain English, to dump its AWS STS credentials, access key, secret, session token, and they were live. Another test told the agent to run a shell command; the built-in shell, running as root, reached into the same memory where plaintext credentials were stored. Once they had those keys, they exported them off the platform, pulled container images, browsed source code as root, even discovered other agents in the region and read their private conversations. One poisoned agent memory basically turned into a Manchurian Candidate sitting inside the cloud. Here’s the move: if you own or build AWS agents, hard-block any prompt or tool call that exposes keys or tokens. Treat the agent like a root user, if it can see a secret, it must never be allowed to print it.