AWS AgentCore Credential Leak: Why the Vault Wasn't Enough

What Unit 42 actually did

AgentCore Harness is AWS's managed runtime for AI agents — part of Amazon Bedrock AgentCore. You give it a model, a set of tools, and instructions, and the Harness supplies the surrounding infrastructure: compute, memory, identity, networking, and the plumbing to call external services. AgentCore Identity is the piece meant to keep secrets out of an agent's own code: instead of hardcoding an API key, the agent references a credential by its Amazon Resource Name, and Identity is supposed to resolve it only when needed.

Unit 42 wanted to know what happens at the exact moment a credential leaves that vault. They set up a simulated customer-support agent wired to a downstream Model Context Protocol (MCP) server, then buried a hidden instruction inside an ordinary support ticket — a classic case of indirect prompt injection, where the malicious payload arrives as data the agent is asked to process, not as a command from its operator. When the agent read the ticket, the embedded instruction told it to download and run a reconnaissance script using AgentCore Harness's built-in shell tool, which is enabled by default alongside a file-operations tool.

That shell didn't run in some sandboxed corner. It ran as root, inside the same container and the same process (PID 1) that AgentCore Identity uses to resolve vault credentials into a usable form. The script read /proc/1/mem, pulled a live JSON Web Token and the address of the MCP server out of the heap, and POSTed both to a server the researchers controlled. From a second machine, with no AWS credentials of its own, Unit 42 replayed that token and reached a customer-lookup function on the simulated MCP server. Nobody needed to guess a password or exploit a memory-corruption bug. The agent did all of it, because a ticket asked it to.

It's worth being precise about scope: this was a controlled research environment with a fictional support operation and a simulated MCP service, not a confirmed breach of real AgentCore customers. Unit 42 also noted that more restrictive models initially refused when the injection was attempted directly, and that the successful path required the indirect route plus a more permissive, tool-capable model. Prompt injection resistance varies by model, but it isn't a security boundary you can rely on.

Why the encrypted vault didn't help

AgentCore Identity did exactly what an encrypted secrets vault is supposed to do: it kept the credential encrypted at rest, encrypted in transit, and gated behind IAM and KMS while it sat unused. None of that was broken. The gap Unit 42 found sits one step later, at the moment a stored secret becomes a usable one. An MCP server doesn't accept an encrypted blob or an ARN — it needs an actual bearer token in the authentication header. Something in the request path has to turn the vaulted reference into plaintext, and that resolution happened inside the same process, and the same memory, that the agent's own shell tool could read.

This is the pattern security teams keep running into as agent platforms mature: the vault is a static-storage problem, and vendors solve it well. The dynamic-use problem — what the secret looks like for the split second the agent actually needs it — is a different, harder problem, and it's the one attackers go after. A credential that's encrypted for 23 hours and 59 minutes a day but sits as cleartext in a root-owned heap for the one second an API call needs it is still a credential an attacker can steal, because that's the only second that matters.

Why AWS calls this "informative," not a vulnerability

AWS's position, as Unit 42 describes it, is that AgentCore's shared-responsibility model puts tool scoping and network egress control on the customer's side of the line. The allowedTools setting lets an operator restrict which tools a model can invoke when the Harness is invoked, and AWS's own documentation confirms the shell and file-operations tools are available by default unless that setting is explicitly narrowed. Filter outbound traffic, scope the tools, and the argument goes, the attack path closes.

That argument isn't wrong on its own terms, but it understates two things. First, allowedTools only controls which tools the model can choose to call at invocation time — it doesn't govern a separate command-execution API that carries its own IAM permission, so narrowing what the model can see is not the same as controlling what the runtime can do. Second, and more fundamentally, a default configuration that ships root shell access sharing memory with a credential-resolution process is a decision AWS made, not one the customer made. Calling the resulting exposure purely a configuration problem is a defensible reading of the shared-responsibility contract, and also a convenient one. Whether "secure by default" should mean the out-of-the-box settings are safe, or just that safety is achievable if you read enough documentation, is exactly the debate this disclosure reopened.

The architectural fork: encrypt-and-hope vs. credential-at-the-wire

Strip away the AWS specifics and this incident is really a case study in two competing philosophies for handling secrets an AI agent needs to use.

The first philosophy — the one AgentCore Identity implements — is to encrypt the secret everywhere it can, gate access with IAM, and resolve it into a real, usable credential inside the agent's own execution environment at the moment of use. The bet is that the agent's process boundary, its tool permissions, and its prompt-injection defenses will hold. When they don't, the payoff for an attacker is total: a live, replayable token with whatever scope the service account carries.

The second philosophy is to never resolve the secret inside the agent's process at all. The agent, its shell, its memory, and anything a prompt-injected instruction can reach hold only a reference or a placeholder — something meaningless if copied out of context. The actual credential swap happens at the network egress point, outside the agent's execution environment, on infrastructure the agent never touches directly. If an attacker convinces the agent to run arbitrary code and dump its own memory, there's still nothing there worth stealing, because the agent was never handed the real thing.

This is the fork KnoxCall's architecture is built around for third-party API traffic: injecting the actual key at the egress wire so the calling process — whether that's an app server, a CI runner, or an AI agent — never holds a credential that's valid outside that specific proxied request. It's worth being honest about the boundary here: KnoxCall doesn't sit inside AWS's AgentCore Identity-to-MCP handshake, and this article isn't claiming it would have intercepted this exact exploit chain. What Unit 42's research demonstrates, in a different but architecturally adjacent system, is the general failure mode that at-the-wire injection is designed to remove: the moment a secret becomes plaintext inside a process an attacker can reach is the moment it's gone, no matter how well it was encrypted beforehand.

What to actually do if you're running AgentCore today

Unit 42's own recommendations for AgentCore operators are the reasonable, immediate steps, and they're worth taking regardless of how the "vulnerability vs. informative" argument shakes out:

• Explicitly set allowedTools to the minimum the agent needs, rather than leaving shell and file-operations enabled by default.
• Scope AgentCore Identity service accounts to least privilege for each downstream integration, so a stolen token reaches less.
• Monitor and filter outbound traffic from Harness containers, since exfiltration in this case was a single, unremarkable-looking HTTP POST.
• Treat every AI agent's shell access, its stored credentials, and its network egress as one connected security boundary, not three separate settings to configure independently.

None of that is unique to AWS. Any agent runtime that gives a model shell access, tool integrations, and a path to a secret in the same breath needs the same layered thinking. For a broader look at where AI agent access controls are heading, see our AI gateway overview and our piece on API security fundamentals.

The bigger pattern: AI agents are the newest place secrets leak from

This isn't the first research this year to point out that giving an AI agent a usable credential is functionally the same risk as putting that credential in an environment variable a compromised dependency can read — the attacker doesn't need new tradecraft, just a new way to get code running in a context that already has access. The specifics differ (a poisoned npm package versus a poisoned support ticket) but the underlying lesson is identical: any process that can be tricked into running attacker-supplied instructions, and that also holds a real secret, will eventually leak that secret. The fix isn't a smarter model or a better-encrypted vault. It's making sure the process never holds the secret to begin with.