The Vault Had a Heap-View: Prompt Injection Pulled Plaintext Credentials Out of AgentCore
AWS tells AgentCore operators to store credentials the right way: in the AgentCore Identity vault, encrypted at rest and in transit, sealed behind KMS keys and IAM policy, referenced only by ARN. Palo Alto's Unit 42 team, led by researcher Niv Rabin, asked what happens at the one moment the design cannot avoid — the instant a credential must leave the vault to be used. Their answer, published September 18, is that the plaintext resolves inside the harness process's own memory, and the harness ships a root shell that can read that memory — on by default. A poisoned support ticket was all it took to walk the whole chain from hidden HTML comment to replayable credential.
This is not the AgentCore package-install injection from July or the CLI triple-quote issue from June. Those were bugs in specific inputs. This is the runtime architecture working as documented, with the documented defaults.
The setup: a vault, a shell, and one shared address space
Three facts combine. First, AgentCore Harness ships two built-in tools — shell and file_operations — available in every session unless the operator restricts them with allowedTools. AWS's own late-August documentation states this plainly. Second, the shell tool runs as root inside the harness container, at the same UID as the harness runtime process (PID 1). Third, when the harness authenticates to a downstream MCP server with a vaulted credential, it resolves the ARN into the real secret at runtime — inside PID 1's memory.
Unit 42's test rig made this concrete: an MCP server requiring an Amazon Cognito Bearer token and holding customer PII, with the token stored in the Identity vault and referenced as ${arn:...} in the Authorization header, exactly as AWS documents. The question was whether injected instructions could reach the resolved secret. The answer required only standard Linux introspection: read /proc/1/maps for the memory layout, walk the readable regions of /proc/1/mem, and search for JWT-shaped strings.
The attack: a support ticket with a hidden comment
The injection vector was a support ticket containing a hidden HTML comment — the kind of content an agent legitimately reads in the course of doing its job. In an earlier stage of the research the same ticket trick had already yielded code execution through the shell tool. For the credential theft, the payload was a small script that scans the harness heap for two patterns: the JWT itself and the MCP server URL to replay it against.
Moments after the agent summarised the poisoned ticket, a single HTTP POST arrived at the researchers' simulated attacker webhook carrying both: one 1,034-byte Bearer JWT and the replay target. From a laptop with no AWS credentials at all, Unit 42 listed the MCP server's tools, called lookup_customer to retrieve customer PII, and created a ticket. Decoding the token showed it belonged to the operator's mcp-service service account — the vaulted identity, fully replayable from anywhere on the internet, extracted without ever touching AWS APIs.
Note the compounding detail the researchers surfaced about the supposed control: allowedTools only scopes tool selection at InvokeHarness time, not at CreateHarness. An operator who finds the parameter still has to understand exactly when in the lifecycle it binds. Defaults-on plus late-binding scoping is how a control exists in the documentation and misses in production.
AWS called it informative
Unit 42 disclosed to AWS. AWS reviewed and closed the report as informative under the AgentCore shared responsibility model, pointing to allowedTools scoping and egress filtering as customer-side controls. That determination is worth sitting with, because both cited controls are things the customer must discover, configure correctly, and monitor — against a default state where every session has a root shell with a view of the vault's plaintext.
There is a legitimate reading on each side. AWS's position is coherent if the harness is understood as general-purpose compute the operator must harden, like an EC2 instance: nobody expects an EC2 box to be safe with all ports open. The researchers' position is that nobody perceives the harness that way — it is sold as "declare what your agent does and we handle the rest," and operators reaching for the documented Identity vault reasonably believe the vault is where the credential's exposure ends. When the mental model is "vault" and the reality is "vault plus a heap-view," the shared-responsibility line is drawn through the customer's misunderstanding.
What operators should do now
- Scope
allowedToolsto the minimum each session needs — and do it at creation time, verifying it binds where you think it does. If a session never needs a shell, it should never have one; the shell is the primitive this entire chain runs on. - Give vault service accounts least privilege for the downstream integration only. The exfiltrated token was an
mcp-serviceaccount whose authority transferred wholesale to the attacker. A token that can only call one read-only tool is a contained spill; a broad service account is a breach. - Watch outbound traffic from harness containers. The exfiltration left as an ordinary HTTP POST to an external webhook. Egress filtering and alerting on unexpected destinations is the control AWS itself named — implement it rather than assuming the harness network is trusted.
- Treat all ingested content as injection surface. Tickets, emails, documents, web pages — anything the agent reads can carry the hidden comment. This is the same conclusion as the Manus obfuscated-email chain and the allowlisting research: enforcement must sit outside the model, because the model cannot reliably distinguish instruction from data.
- Ask what "encrypted at rest" covers in your agent stack. Every vault resolves to plaintext at use time. Map where that plaintext lives, which UIDs can read it, and which tools execute at those UIDs — for AgentCore and for every other harness you run.
The through-line of this month's agent security coverage keeps converging on one sentence: the model is not the trust boundary, the harness is. A vault that resolves secrets into a process whose default shell runs as root has moved the boundary without moving the marketing. Until defaults ship closed — no shell unless requested, no plaintext in a readable heap — the Identity vault is a safe with a window in it.
Sources: