AWS Agents Tricked Into Leaking Cloud Credentials

CSO Online · High sophistication
Last updated October 8, 2026

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
Try Mirage

Mirage safely runs attacks like this one against your own team, so you find out what happens before a real adversary does.

Get a demo
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.

Categories

Similar attacks

Voicemail Phish Steals Microsoft 365 Sessions

Voicemail Phish Steals Microsoft 365 Sessions

Researchers describe an active, widespread email campaign that tricks employees with voicemail-themed messages and steals Microsoft 365 login sessions (including MFA codes). After taking over accounts, attackers quietly search and collect payroll/HR/finance emails and identify people involved in…

August 7, 2026
Single Prompt Stole AWS AgentCore Credentials

Single Prompt Stole AWS AgentCore Credentials

Researchers described how an external user with only chat access to an Amazon Bedrock AgentCore agent could prompt it to fetch a cloud credential endpoint and inadvertently reveal temporary AWS credentials. Those credentials could then be used to enumerate other agents, access container images,…

October 9, 2026
Vishing Wave Hits Healthcare With MFA Reset Traps

Vishing Wave Hits Healthcare With MFA Reset Traps

Threat groups are actively targeting healthcare and pharma staff using phone-based social engineering (“vishing”) and look‑alike medical domains to steal employee login credentials. Researchers say attackers pressure employees to click password-reset or MFA-reset links, and multiple…

September 28, 2026
Teams Helpdesk Vishing Pushes Remote Control Tools

Teams Helpdesk Vishing Pushes Remote Control Tools

Researchers observed a coordinated social-engineering operation (“Spring Ring”) where attackers used external Microsoft Teams accounts to pose as internal IT help desk staff and start voice calls. Victims were pressured to install remote-control tools (like Quick Assist or other RMM software) or…

August 31, 2026
Attackers Phish via Teams & Slack, Not Email

Attackers Phish via Teams & Slack, Not Email

Research and incident examples show attackers increasingly using trusted collaboration tools (like Microsoft Teams and Slack) to impersonate IT/support or known community members, then push victims to phishing sites, approve MFA prompts, or run malicious files. Because messages come through…

August 20, 2026
Fake AWS & Apple ID Pages Push iOS Spyware

Fake AWS & Apple ID Pages Push iOS Spyware

Researchers found an active campaign using fake AWS sign-in pages and an Apple ID decoy page to pull victims onto attacker-controlled websites. Visiting these pages can trigger an iOS exploit chain that installs GHOSTBLADE and steals sensitive data like iCloud, Keychain, and Wi‑Fi credentials.

August 3, 2026