Unit 42 researchers hid one line of text inside a customer support ticket. An AI agent running on Amazon's AgentCore Harness read the ticket, carried out the instruction, and moments later a live access token belonging to the operator's service account arrived at a webhook the researchers controlled. Nothing in the deployment was misconfigured. That was the point.
The finding, published by Unit 42's Niv Rabin, concerns AgentCore Harness, the managed runtime AWS offers for hosting AI agents. Rabin built a fictional company called SupportCo whose agent reads inbound tickets and looks up customer records through a downstream Model Context Protocol (MCP) server, the standard way agents connect to outside services. The credential for that server sat in AWS AgentCore Identity, the platform's own encrypted vault, and was referenced in the configuration only by its resource name.
Root, straight out of the box
Every harness session ships with two tools switched on unless the operator restricts them: shell, which runs bash commands, and file_operations, which reads and writes files. Rabin found that shell runs as root inside the harness, in the same process tree as the runtime itself. Reading the /proc filesystem showed the runtime sitting at process 1, under the same user, with its memory readable by the shell tool.
Asking the model directly to run reconnaissance commands did not work. It refused. What worked was indirect prompt injection, an instruction planted in content the agent was asked to process rather than typed at it: a hidden HTML comment inside the support ticket told the agent to fetch a script and pipe it into python3. The agent obliged.
A vault has to open to be used
Encryption at rest does nothing at the moment a secret is actually used. To authenticate against the MCP server, the harness had to resolve the vault reference into the real plaintext token inside its own process, and that process was the one the shell tool could read. Rabin's script scanned the runtime's heap for two patterns, the token in JSON Web Token form and the MCP server URL, then posted both to a webhook[.]site endpoint in a single request. Decoding the token showed it belonged to the operator's mcp-service account rather than to any end user.
From a laptop, holding no AWS credentials at all, the researchers replayed that token against the MCP server, listed its tools and called its customer lookup. The test rig's server held names, phone numbers and the last four digits of Social Security numbers.
AWS calls this the customer's job
Unit 42 disclosed the finding to AWS, which reviewed it and closed the report as informative under the AgentCore shared responsibility model, pointing to allowedTools scoping and egress filtering as controls the customer owns. Rabin flags a wrinkle that makes the first of those easy to miss: the allowedTools parameter scopes tool selection at InvokeHarness time, not at CreateHarness.
Switch off the shell the agent never needed
Unit 42 recommends three layers for anyone running agents on AgentCore today. Scope allowedTools to what each session genuinely requires. Give Identity vault service accounts only the privileges their downstream integration needs, not a general-purpose token. Watch outbound traffic from harness containers, because exfiltration is the step that has to leave the building. The original report carries the full walkthrough.
None of this is unique to Amazon. A poisoned repository recently persuaded Amazon's Kiro IDE to mail out API keys, and a single-character authentication bypass opened hundreds of LiteLLM gateways. The lesson is the same each time. Hand an agent a shell and the damage a single planted sentence can do stops being measured in text. It is measured in whatever that shell can reach.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.