AWS AgentCore: the vault held. The process did not.

A credential vault for AI agents has one job: keep the secret out of reach until the agent needs it. Unit 42 has now published what happens in the moment it is needed. In AWS AgentCore the secret is resolved to plaintext inside the same process that runs the agent's tools, and one of those tools is a shell that is on by default. The vault held. The process gave the credential away anyway.

#What Unit 42 found

Amazon Bedrock AgentCore gives agent builders two pieces meant to work together. AgentCore Identity is the vault: bearer tokens, OAuth2 tokens and API keys, encrypted at rest and in transit, backed by KMS and gated by IAM. The harness is the runtime holding the model loop and the tools. Code never handles the secret, only an ARN that points at it.

The gap sits between the two. As the report puts it, for the harness to authenticate with a vaulted credential, the ARN first has to be resolved into the real plaintext secret, at runtime, inside its process. In AgentCore that process is PID 1 of the container, and the plaintext lands in its heap.

That would be unremarkable if nothing else could read that heap. But Unit 42 found the harness shell tool running as root in the same container, with /proc/1/mem readable and the harness address space open to it. Credential and attacker-reachable code were neighbours in one process.

#The access path, step by step

# as published by Unit 42, 18 September 2026
support ticket     # instructions hidden in HTML comments
  → agent          # accepts the tool call, runs a command
  → shell tool     # on by default, root in the harness
  → process heap   # /proc/1/mem, scanned for JWT patterns
  → service jwt    # vaulted credential, plus the MCP URL
  → customer data  # replayed from outside AWS

The recon script found not only the token but the address of the downstream MCP server in the same memory. A credential without its endpoint is an unfinished path. Unit 42 got both, in one HTTP POST to a webhook.

And the replay needed nothing from AWS. With the JWT and the URL in hand, the researchers authenticated to the MCP service from any internet location. At that point the agent, the harness and the vault are out of the loop.

#Why the vault was not the weak part

The easy reading of this research is wrong. Unit 42 did not break AgentCore Identity. Encryption, key management and IAM gating worked as documented, and there was no microVM escape. The chain ran inside a session the agent was authorized to have.

Every line in that table is a control doing its job. The finding only becomes visible when the steps are joined up: untrusted text goes in at the top, a working credential for another system comes out at the bottom. That is an access path, not a vulnerability, and no scanner that grades each component on its own will flag it.

#The credential was a service account

The most useful line in the report is about whose token it was. Per Unit 42 the JWT belonged to the operator's service account for the MCP integration, not to the user who started the conversation. The blast radius is not what one customer may see. It is everything that integration was built to reach: here, records with names, phone numbers and the last four digits of Social Security numbers.

This is the familiar shape of non-human identity risk, with the agent layer making it easier to trigger. A service account is provisioned once, scoped to the integration rather than to any single request, then left alone. What is new is that untrusted input can now reach the process where its token lives. The Codex sandbox research showed a close relative.

#Where the path breaks

Unit 42 filed the report through HackerOne on 19 May 2026. AWS closed it as informative on 10 June 2026 under the AgentCore shared responsibility model, pointing to allowedTools scoping and egress filtering as customer-side controls. That puts the breakpoints on your side of the line. Three matter.

The default tool set. Unit 42 notes that shell and file_operations are available in every session unless restricted, and that allowedTools has to be scoped at InvokeHarness time, not at CreateHarness time. An agent that reads tickets and writes summaries has no reason to hold a root shell.

The scope of the vaulted identity. A leaked credential is worth what its scope buys, as the report puts it. Scope each vault entry to its downstream integration, not to the team that owns it.

The way out. The token was useless until it reached a webhook. Outbound traffic from a harness container should have a short, known list of destinations, and the first address outside it is evidence.

#What to check this week

1. List every agent runtime that resolves a stored credential in-process. This is not specific to AWS: any harness that vends a secret into the process running model-chosen tools has the same shape.
2. Check which built-in tools your agents actually get. If shell or file access is on by default, turn it off per session and see what breaks.
3. Name an owner for every service account behind an agent integration, and ask what each one can read at full scope, not what the current use case needs.
4. Trace one integration end to end, from the untrusted input the agent reads to the last system its credential can open. Most teams stop counting at the agent.
5. Allowlist outbound traffic from agent containers and alert on anything else.
6. Separate the data the agent is given from the data its identity can fetch. Where those are the same, the identity is the real boundary, and it is not scoped for that job.

#FAQ

A vault tells you where a secret is stored. It does not tell you what that secret can reach once an agent holds it. Elmoz maps AI agents and non-human identities across cloud and SaaS and shows which access paths end at customer data.