That line, lifted from AWS documentation and cited by Unit 42 researchers at Palo Alto Networks, sets the scene for a simple but consequential chain: a default-enabled shell running inside the AgentCore Harness, prompt injection that convinces an agent to execute commands, and plaintext credentials that appear in the harness process memory. The result, Unit 42 shows, is credential exfiltration from AgentCore Identity — not because the vault failed at rest or in transit, but because of what happens when a credential is "in use."
How AgentCore Harness is configured by default
Unit 42 examined a managed runtime for AI agents called AWS AgentCore Harness. The harness is designed to manage environment, compute, memory, identity, networking and observability for an agent. Among its features are built‑in tools that ship enabled unless an operator scopes them with the allowedTools parameter. Two of those tools, enabled by default, are shell (executes bash commands) and file_operations (viewing, creating and editing files).
Root-level shell, readable process memory, and the Identity vault
AgentCore Identity, the recommended vault, provides encryption at rest and in transit, KMS keys, and IAM-gated access. Unit 42's probe focused on runtime behavior: when the harness resolves a vault ARN into a usable credential, that plaintext secret must exist somewhere in the process memory to be used. The researchers found the harness subprocess that runs shell commands executes as root, and that PID 1 — identified as python3.10 -m loopy.server — exposes readable memory through /proc/1/mem. With root privileges and readable heap memory, the shell tool can access whatever the runtime resolves into PID 1's address space.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleFrom prompt injection to a replayable service account token
Unit 42 walked a full attack chain in a default-configuration example. They first used an indirect prompt-injection primitive — a hidden HTML comment instructing the agent to curl a recon script and pipe it into python3 — which the agent executed after the researchers selected a permissive model that supports tool calling. The recon script ran inside the harness, discovered its runtime environment (whoami, id), and then read loopy's memory by using /proc/1/maps to enumerate readable regions and /proc/1/mem to extract contents.
The researchers' heap-scan script searched for two patterns: a JSON Web Token (JWT) and the downstream Model Context Protocol (MCP) server URL. The script found a 1,034‑byte JWT and the MCP server endpoint, and immediately POSTed both to an external webhook. The token decoded to an account with username mcp-service. Using the exfiltrated JWT and URL, Unit 42 replayed the credential against the MCP server from an external machine, listed the MCP tools and invoked a lookup_customer tool that returned personally identifiable information (PII).
AWS response, disclosure timeline, and the shared‑responsibility outcome
Unit 42 reported the finding to the AWS Security team via HackerOne on May 19, 2026 (report #3747844). AWS requested reproduction details and clarifications on June 8, 2026; the finding was merged with an earlier report on June 10 and closed the same day as "informative" under the AgentCore shared responsibility model. AWS's closure cited allowedTools scoping and egress filtering as customer-side controls.
Recommendations and what to watch for
- Scope allowedTools at InvokeHarness time, not only at CreateHarness: sessions that do not require shell or file_operations should not receive them by default.
- Scope Identity vault service accounts to least privilege for each downstream integration: a leaked credential is only as powerful as its permissions.
- Monitor outbound traffic from harness containers: any endpoint outside the expected downstream integration list is evidence of an active injection.
Unit 42 also advises builders of managed runtimes to treat capabilities as attack-surface primitives: either keep runtime credentials inaccessible from the shell tool or run the shell in a sandbox isolated from the process that resolves secrets.
What this means for operators, Palo Alto Networks customers, and runtime builders
- Operators building on AgentCore Harness should audit their allowedTools settings, verify which service accounts are stored in AgentCore Identity, and implement egress controls for harness containers.
- Palo Alto Networks customers can use offerings mentioned by Unit 42 — such as Cortex Cloud and Unit 42 Cloud Security Assessment — to add behavioral context, enforce identity baselines, and review cloud posture against identity-driven threats.
- Builders of managed agent runtimes must decide whether to isolate credential resolution from the runtime that exposes a general-purpose shell, or to dramatically narrow what that shell can touch, because vault protections at rest and in transit do not prevent exposure when a secret is materialized in process memory.
Unit 42's research underscores a practical truth: vaults keep secrets safe until the moment they must be used. In default AgentCore Harness configurations, that "moment" sits in the same memory space the shell can read. The mitigation is straightforward in design — narrow the shell's reach, narrow the vault's scope, and watch for unexpected egress — but it requires operators and runtime designers to treat convenience as a security decision.
Read the original Unit 42 report: https://unit42.paloaltonetworks.com/securing-aws-agentcore-harness-credentials/
