Issue 13 5 min read

A vault is not enough if the shell can read its memory

A support ticket told an AWS agent to run a script, and the script pulled the vault's token out of process memory. The vault did its job. The shell running next to it undid that work.

On May 19, researchers at Palo Alto Networks’ Unit 42 reported a problem in AWS AgentCore Harness to AWS. On September 18 they published it. The setup was ordinary. A fictional company, SupportCo, ran a support agent on AgentCore Harness. AgentCore Identity held the credentials for a downstream MCP server that looked up customers and filed tickets. Unit 42 says of the setup that “nothing is misconfigured.”

The attack started in a ticket. When the researchers asked the model directly, it refused twice. So they picked a more permissive model, which the harness lets a caller choose on each invocation. Then they hid the instruction in data. A hidden HTML comment in a ticket told the agent to curl a recon script and pipe it into python3. The agent read the ticket and fired its shell tool. The script ran inside the harness.

The shell ran as root. So did every process in the chain, including PID 1, the harness server itself. That made /proc/1/mem readable. The script read the memory map, then the memory. It found a 1,034-byte JWT for a service account named mcp-service. It posted the token and the MCP server’s URL to an outside webhook in one request.

Then the researchers replayed the token from a laptop with no AWS credentials. They listed the tools and called lookup_customer. It returned names, phone numbers, and the last four digits of Social Security numbers. They filed a ticket too. The token worked from anywhere on the internet.

Issue 12 argued that a session that can run a shell must not hold the secrets. This case shows the gap in that advice. The secret never sat in a file or an environment variable. The vault handed it to the harness at runtime, which is how vaults are meant to work. Unit 42 puts it plainly: “Vaults protect at rest and in transit, not in use.” A credential has to become plaintext before anything can use it. If the shell runs as the same user, in the same process tree, as the code holding that plaintext, the vault stops protecting it once it reaches the harness’s memory.

Two more details matter for operators.

The first is the default. AWS’s harness docs say the shell and file_operations tools “are available in every session unless you restrict them with allowedTools.” If you leave the list out, every tool is allowed. The shell is not a power tool you opt into. It is on from the start.

The second is whose token leaked. It was not the end user’s session token. It was mcp-service, the operator’s own service account. Unit 42’s heading says it well: “Authorized to invoke is not authorized to reach.” Anyone who could put text in front of the agent borrowed the operator’s access. Each session runs in its own microVM, but that did not limit the damage. The stolen token works outside any VM.

AWS closed the report as informative under the AgentCore shared responsibility model. It named allowedTools scoping and egress filtering as controls the customer owns. No CVE was assigned. That fits AWS’s own docs. The runtime security page says commands have “full access to the container filesystem and any configured credentials or secrets within the microVM.” It also lists preventing prompt injection as the customer’s job. So the fix is yours. Treat the default tool list as install policy, the same way you now treat skills, extensions, and registries.

Here is what to change.

  • Pin allowedTools on every InvokeHarness call. It scopes each request, not the harness you created with CreateHarness. Drop the shell and file_operations for any role that doesn’t need them. An agent that answers tickets rarely does.
  • Limit each vault service account to one downstream job. A leaked token can do only what its account is allowed to do. Shorten token lifetimes and rotate tokens on a schedule.
  • Allowlist and log outbound traffic from harness containers. Unit 42’s rule of thumb is that any endpoint missing from your integration list is evidence of an active injection. AWS recommends outbound rules that allow only the minimum traffic, plus VPC Flow Logs.
  • If a role truly needs a shell, give it a separate container with minimal privileges. Don’t run it as root beside the process that resolves credentials. CSA’s research note makes this the operator’s move until the platform does it for you.
  • Audit who holds bedrock-agentcore:InvokeAgentRuntimeCommand. To prevent direct command execution, AWS says not to grant it. Being able to invoke an agent should not mean being able to run commands inside it.
  • Decide who gets to choose the model. This attack landed after a switch to a more permissive one. If any caller can pick the model on each call, they can pick the weakest.

Sources

Next issue in two days. See you then.

Subscribe