1. Executive summary
Unit 42 has disclosed a design weakness in AWS AgentCore Harness: with default configuration, the harness's built-in shell tool runs as root in the same memory space where credentials from AgentCore Identity are resolved to plaintext, so a successful prompt injection can steer the agent to exfiltrate those credentials. AWS reviewed the report and closed it as informative under the AgentCore shared responsibility model, treating allowedTools scoping and egress filtering as customer-side controls. There is no CVE, no CVSS score, and no evidence of in-the-wild exploitation; this is a configuration-dependent exposure, not a patched vulnerability. Financial services clients building agentic workloads on AgentCore should treat any deployment that leaves the default shell and file_operations tools enabled as exposing vault-managed credentials to exfiltration via injected content.
2. Regulatory framing
No specific DORA/NIS2 article is directly engaged by this item. The finding is a configuration weakness in a cloud service with no confirmed incident, no exploitation, and no third-party breach; the general duty to manage ICT risk would apply to any deployment, but no fact in this item triggers a distinctive obligation under the articles in scope.
3. Technical analysis & attack chain
The exposure arises from the interaction of two AgentCore components. AWS AgentCore Identity is the platform's recommended credential store: an identity vault with encryption at rest, encryption in transit, KMS keys, and IAM-gated access. A downstream MCP server authenticates the harness using a credential drawn from that vault. The weakness sits at runtime, when a credential must leave the vault to be used: the harness's built-in shell tool, enabled by default, reaches into the same memory space where credentials are resolved to plaintext.
The out-of-the-box state of the harness makes this worse. Two built-in tools, shell and file_operations, are available in every session unless restricted via the allowedTools parameter. The shell tool executes bash commands and runs as root inside the harness, so any command the agent is induced to run inherits that root access. Nothing has to be misconfigured for this to hold; it is the default.
The attack chain as demonstrated by Unit 42:
- An attacker plants injected content that the agent will process, for example in data the agent retrieves or in instructions from a downstream source.
- The injected prompt steers the agent to invoke the built-in shell tool.
- The shell tool runs as root in the same memory space where the AgentCore Identity credential is resolved to plaintext.
- The agent reads the plaintext credential from memory.
- The agent exfiltrates the credential to an attacker-controlled destination over outbound network access from the harness container.
Two properties of this chain matter to defenders. First, the vault's protections (encryption at rest, KMS, IAM gating) do not help once the credential is resolved to plaintext in a memory space the shell tool shares. Second, the chain requires no vulnerability in AgentCore itself; it requires only the default tool configuration and an egress path from the harness container.
AWS's position, per Unit 42's disclosure account, is that this falls under the AgentCore shared responsibility model: allowedTools scoping and egress filtering are customer-side controls, and the report was closed as informative. This is a single-sourced finding from one vendor research team; the technical mechanism is plausible and internally consistent, but no second-party reproduction or independent analysis is available at time of writing. Verify the behaviour in your own AgentCore deployments before treating the memory-access claim as established for enforcement purposes.
4. Mitigation & containment
P1 (within 24h):
- Inventory all AgentCore Harness deployments and record which sessions run with default tools enabled. If you cannot enumerate them, treat all sessions as exposed.
- Restrict the allowedTools parameter in every session to only the tools that session needs. Any session that does not require shell or file_operations must have both removed. This is the control AWS itself cites as the customer-side fix.
- Block unnecessary outbound traffic from harness containers at the network layer. The exfiltration step in the demonstrated chain depends on egress; an agent whose container can reach only its intended MCP server and model endpoint cannot send a stolen credential anywhere.
P2 (within 72h):
- Scope each Identity vault service account to least privilege for its downstream integration. A credential exfiltrated from a vault scoped to one MCP server is worth less than one scoped broadly.
- Review the instructions and data sources each agent processes. The initial step of the chain is injected content reaching the agent; identify which upstream content the agent trusts and whether that trust is warranted.
- Confirm whether your sessions run the shell tool as root, and document which sessions genuinely require that privilege level.
P3 (within 7 days):
- Add AgentCore configuration review to your cloud security assessment cycle, covering allowedTools settings, vault scoping, and container egress rules as standing checks rather than one-off fixes.
- Establish monitoring on harness container outbound traffic so anomalous destinations are visible, not just blocked.
5. Indicators of compromise
No indicators of compromise available in the source material.
Behavioural indicators
| Behaviour | Where to observe | Confidence |
|---|---|---|
| Harness agent invoking the built-in shell tool to read process memory or credential material | AgentCore session logs, harness observability output | Single-sourced; derived from Unit 42's demonstrated chain |
| Outbound connections from harness containers to destinations other than the intended MCP server or model endpoint | Container network flow logs, egress firewall logs | Single-sourced; derived from the exfiltration step of the demonstrated chain |
6. Detection
Insufficient indicators to author detection rules.
The source describes the mechanism but provides no command strings, file paths, mutexes, registry keys, or other artefacts from the demonstrated attack that could anchor a YARA or Sigma rule. The behavioural indicators in §5 are the usable detection material; implement them as log review and egress alerting rather than signature matching.
7. Sources
- Unit 42 (Palo Alto Networks), "A Vault with a Heap-View: The Uncomfortable Space Between AgentCore Harness and Identity", https://unit42.paloaltonetworks.com/securing-aws-agentcore-harness-credentials/, 2026-09-18
8. Adverse Trace position
We assess this as a medium-severity configuration exposure rather than a vulnerability: no CVE exists, AWS has declined to treat it as a product defect, and exploitation requires both default tool configuration and a successful prompt injection. The impact for EMEA financial services is nonetheless real, because AgentCore Identity is positioned as the platform's recommended credential vault and the default configuration undermines the protection it advertises at the exact moment a credential is used. The finding is single-sourced from Unit 42 and AWS's closure as informative means no vendor fix is coming; the remediation burden sits entirely with customers, which makes the P1 actions above the operative controls. We will monitor for independent reproduction of the memory-access claim, for any AWS documentation change to the default tool set, and for reports of prompt injection against AgentCore deployments in production, and we will update this advisory if any of those materialise.
Published via PulseTrace — Adverse Trace threat intelligence.