Security1 publisher2 min readPublished
Unit 42 finds AWS AgentCore's default root shell can reach credentials the vault resolves in memory
AgentCore Harness enables a root bash tool in every session unless allowedTools says otherwise. AWS closed Unit 42's report as informative, so the scoping falls to whoever declares the agent.
The Watch · Security desk
What happened
- Unit 42 says default configurations in AWS AgentCore Harness let an attacker use prompt injection to steer an agent into exfiltrating plaintext credentials managed by AgentCore Identity.
- The harness's built-in shell tool, enabled by default, reaches into the same memory space where credentials from the identity vault are resolved to plaintext for use.
- That shell tool runs as root inside the harness, so a command the agent is talked into running inherits root access.
- AWS reviewed the disclosure and closed it as informative under the AgentCore shared responsibility model, naming allowedTools scoping and egress filtering as customer-side controls.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- exposure The harness operates under the operator's credentials, not the invoking user's, so one command puts every tool and downstream service the harness can reach in scope.
- constraint The vault's encryption at rest, encryption in transit, KMS keys and IAM gating hold up to the moment of use, and none of them limits what a root process in the same memory can read.
- decision AgentCore's premise is that the operator declares the agent and the platform runs it; that declaration now has to include a list restricting tools the operator never enabled.
- precedent With every control on the operator's side, default tool reach in a managed agent runtime becomes a customer configuration duty, and the next harness can ship the same defaults and cite the same model.
The credential Unit 42 followed is the one the harness uses to authenticate against a downstream Model Context Protocol server, and AWS's recommended place to keep it is AgentCore Identity, the platform's identity vault [2][3]. The researchers examined those two integrations and asked what happens at runtime, when the credential has to leave the vault to be used [3].
AWS's documentation described the default this way 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." [8] The restriction is per session. Leave allowedTools unset and the session can run arbitrary shell commands and read or write files whether the operator asked for those tools or not [9]. Unit 42 says nothing has to be misconfigured for that condition to exist [7].
The remediation list has three items: scope allowedTools to what the harness needs, scope the Identity vault service accounts to least privilege for the downstream integration, and watch outbound traffic from harness containers [11]. Two of the three are configuration scoping. The third is egress monitoring, which tells you a credential left [14]. Unit 42 did not publish dates for the disclosure or for AWS's reply [15].
Unit 42 says the built-in tools are a big part of what makes the harness autonomous and productive, because the agent can write files and run code to get real work done [16]. Scoping allowedTools takes that away from the sessions that do not need it [11].
What to watch
- Whether AWS changes the AgentCore Harness default so shell and file_operations are off until declared.
- Whether AWS documents a runtime boundary between resolved vault credentials and the shell tool's memory space.
- A published prompt-injection chain against a live AgentCore deployment would move this from reachable to observed.