A protected credential vault did not stop a test support agent from giving away its service-account token. In research published September 18, Unit 42 used a support ticket to steer AWS AgentCore Harness into reading runtime memory, then reused the extracted credential from a laptop. This was a laboratory demonstration, not a reported customer breach.
A ticket became an instruction
The researchers built a fictional support service connected to an MCP server—a service that exposes tools an agent can call. Their first model refused the command requests; they selected a more permissive model. A hidden HTML comment in a ticket then directed the agent to fetch and execute a script.
The shell ran as root inside the harness environment and could read the main process’s memory. A vault credential had become plaintext there so the harness could authenticate to its downstream service.
The test extracted a 1,034-byte token and the destination server URL. Replaying them retrieved test customer records and created a ticket. The token belonged to the operator’s service account, not the person asking for help.
The vault and the session protect different things
That distinction matters to anyone connecting an assistant to customer records, billing systems or internal tools. Permission to ask an assistant a question and permission to use its service account are different grants of authority. If processing a question can expose the second, the assistant becomes a bridge between them.
AWS documents each harness session as an isolated microVM. That is a boundary around the session, not a promise that every tool within it is isolated from every credential. Its current security guide assigns caller authorization, input validation and model-configuration validation to the customer. It also says request structure is checked, while the meaning of prompts is not screened by the harness.
The research does not establish a cross-customer escape or broken vault encryption. It illustrates why encrypting a stored secret and controlling access to a working session answer different security questions. A separate AI-access investigation in which an agent disclosed its own context illustrates a different exposure: ordinary requests sent sensitive context to an untrusted endpoint, without a demonstrated prompt injection.
Restrict the tools—and check the other command path
AWS’s tools documentation says shell and file_operations are available by default. Omitting allowedTools permits all tools. For a support assistant that only needs a defined customer-lookup tool, explicitly allowing that tool gives the model a smaller action set than a general-purpose shell.
There is a separate control to check: allowedTools applies to model tool selection during InvokeHarness. AWS states that it does not govern InvokeAgentRuntimeCommand, a direct command API with its own IAM permission. Teams that do not need that command path should exclude the permission as well; changing the model’s tool list alone does not close it.
Identity configuration also needs an explicit choice. AWS currently documents per-user downstream credential scoping through inbound OAuth; SigV4 callers do not propagate that per-user identity. Verify which account a downstream request actually uses before assuming it inherits the questioner’s restrictions.
According to Unit 42, AWS closed the finding as informative on June 10 under shared responsibility. For operators, the useful check is concrete: identify the account your agent uses, the commands it can execute and the destinations it can reach. A vault is one part of that design.
References
- Niv Rabin, Unit 42. A Vault with a Heap-View: The Uncomfortable Space Between AgentCore Harness and Identity. September 18, 2026.
- Amazon Web Services. AgentCore Harness: Tools. Accessed September 20, 2026.
- Amazon Web Services. AgentCore Harness: Security and access controls. Accessed September 20, 2026.
