Executive Summary
Unit 42 researchers have identified an issue where using default configurations in Amazon Web Services (AWS) AgentCore Harness could allow attackers to steer an agent's actions through prompt injection to exfiltrate plaintext credentials managed by AgentCore Identity.
To reach that finding, we examined two of the harness's many integrations:
- AWS AgentCore Identity, the platform's recommended way to manage agent identities and store credentials (i.e. an identity vault)
- A downstream Model Context Protocol (MCP) server, which the harness authenticates against using a credential from that identity vault
AWS AgentCore Identity provides encryption at rest, encryption in transit, key management service (KMS) keys and identity and access management (IAM)-gated access. We wanted to know what happens at runtime, when a credential has to leave the vault to be used. What we found was that the harness's own built-in shell tool, which is enabled by default, reaches into the same memory space where credentials are resolved to plaintext.
We disclosed this finding to AWS. AWS reviewed and closed the report as informative under the AgentCore shared responsibility model, citing allowedTools scoping and egress filtering as customer-side controls.
For operators building on AgentCore today, defense takes a layered approach:
- Scope the allowedTools the harness can use to what it needs
- Scope Identity vault service accounts to least privilege for the downstream integration
- Watch outbound traffic from your harness containers
Palo Alto Networks customers are better protected from the threats discussed in this article through the following products and services:
Unit 42 Cloud Security Assessment is an evaluation service that reviews cloud infrastructure to identify misconfigurations and security gaps.
If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.
| Related Unit 42 Topics | AgentCore, AWS, Identity, AI Agents |
Background on AgentCore Harness
The research that follows is built entirely on AWS AgentCore Harness, a managed runtime for AI agents. As AWS describes it, you declare what your agent does (model, tools, skills, instructions) and AgentCore handles the rest. This includes the environment, compute, memory, identity, networking and observability that turn the configuration into a running agent.
What you declare is only part of the picture. On top of it, the harness ships two built-in tools turned on by default. As AWS's documentation put it in late August 2026:
"Default tools shell and file_operations are available in every session unless you restrict them with allowedTools. shell executes bash commands; file_operations supports viewing, creating, and editing files."
The built-in tools are a big part of what makes the harness so autonomous and productive. The agent can write files and run code to get real work done. But the same reach that makes the built-in tools useful makes them dangerous when people leave them on unintentionally.
We've found that the shell tool runs as root inside the harness, so the moment an attacker gets the agent to run a command, that command inherits the same root access. Nothing has to be misconfigured for this to happen. It is the out-of-the-box state.
Unless you scope the allowedTools parameter to what each session actually needs, every session can run arbitrary shell commands and read or write files, whether you asked for those tools or not.
The Agent Harness Bridges the Gap Between Reasoning and Action
Not long ago, an AI model could answer a question but not act on it. Now, AI agents are reasoning across boundaries that used to be out of reach, taking on tasks that are more complex, longer-running and more autonomous.
But reasoning alone does not get an agent very far. To be useful, an agent needs infrastructure that turns decisions into actions.
That is the gap an agent harness fills. It is the managed runtime around the model, built to keep the agent on track and give it what it needs to operate on its own. A harness provides a variety of different capabilities, including the following:
- Tools to call
- A sandboxed shell to execute code
- Memory that survives across sessions
- MCP integrations for external services
- An identity to act under
The harness orchestrates these capabilities in a resilient loop that lets the agent plan, act, observe and continue.
Figure 1 below shows the anatomy of an agent harness.
As Figure 1 illustrates, the user's reach stops at “invoke.” The harness's reach extends to every tool and downstream service under the operator's credentials.
Among all the capabilities a harness can give an agent, the shell tool can be both a significant productivity enhancement and a primary attack surface.
But to understand how the shell tool came to be, we first need a quick recap of how an LLM works in the context of this sort of tool.
The Shell Tool: Benefits and Risks
On its own, a language model can only produce text. To make it more useful, its ability to use tools relies on a mechanism called function calling.
The Benefit: Programmatic Tool Use Increases Functionality and Efficiency
This section outlines how function calling grew into programmatic tool use, a leap in efficiency that eventually put a shell tool in the agent’s hands.
Given a user request and a set of available functions, the model can determine that a function should be called and return a structured tool_call response:
- The chosen function name
- The arguments to pass and their values
- All the information the runtime needs to execute it
The runtime then invokes the function, captures the result and sends that result back into the model's context, where the model can decide whether to call another function or produce the final answer. If you run that runtime in a loop and rename “functions” to “tools,” it is now a fully autonomous agent.
As agents matured, tool catalogs became part of agent frameworks. MCP pushed the idea further by standardizing how agents discover and connect to external tools, services, resources and prompts.
However, the core pattern stayed the same. The model still needed to have the tool definitions in its context before it could use them, and each tool's response before it could reason about what to do next. Both required context.
People saw how capable agents could be and began loading them with more tools. Very quickly, the bottleneck shifted from whether agents could use tools to how many tools the agent’s context can handle.