AIDEFEND in Action AIA-0096 Validated Research Published: Oct 1, 2026

AgentCore Harness Identity Credential Exfiltration and Replay

In Unit 42's controlled SupportCo test, instructions hidden in a support ticket made an agent run a script through AgentCore Harness's default shell. The script read PID 1 memory, sent the operator's MCP service-account JWT and server URL in one HTTP POST to a simulated attacker webhook, and the researchers replayed the JWT from a laptop to retrieve sample customer PII. The credential was not an end-user token. AWS treated this as shared-responsibility configuration guidance, not a patched service vulnerability.

Indirect Prompt InjectionCredential ExposureTool AuthorizationAI Infrastructure
6 applicable AIDEFEND defenses
Source: A Vault with a Heap-View: The Uncomfortable Space Between AgentCore Harness and Identity 
Author: Niv Rabin
Original article: Sep 18, 2026

Threat Analysis

AgentCore Identity protected the service credential at rest, but the Harness had to resolve it into plaintext at runtime. The default shell tool ran with the same root UID as the main process; an injected ticket therefore turned the shell into a reader of the process that held the credential.

  1. A hidden HTML comment in an inbound ticket told the agent to fetch and run an attacker-controlled script.
  2. The permissive test model used the built-in shell, enabled unless allowedTools was scoped at InvokeHarness.
  3. The shell read /proc/1/maps and readable regions of /proc/1/mem.
  4. The scan recovered the operator's MCP service-account JWT and downstream server URL, not the end user's token.
  5. The injected script sent both to a simulated attacker webhook in one HTTP POST.
  6. From a separate laptop, the researchers replayed the JWT, listed MCP tools and called lookup_customer to retrieve sample customer PII.

SupportCo was fictional and the test was controlled. AWS closed the disclosure as informational under shared responsibility and pointed to allowedTools and egress controls; this is not evidence of a real customer intrusion.

Applicable AIDEFEND Defenses (6)

AID-H-018.002
Policy-Based Access Control
Very High
Derive allowedTools from a verified task in the customer invocation path and configure a synchronous before_tool_call Lambda hook on CreateHarness/UpdateHarness with failureMode set to deny. Before execution, resolve task/session identity from trusted records and reject shell/file_operations for support-answer work. A model-generated toolInput or truncated hook context cannot establish authorization. Test deny, timeout, malformed response and dependency failure. SNS/EventBridge notifications are asynchronous observation, not blocking hooks.
AID-I-002.002
Secure External AI Service Connectivity
High
Only where the Harness runs in a customer-controlled VPC network path, force its outbound requests through an independently enforced default-deny firewall or proxy. Allow only the exact model and MCP destinations required for the task, so an unapproved diagnostic-script host is unreachable. Verify the actual network route and proxy bypass paths; a policy document cannot constrain a non-VPC managed runtime.
AID-I-001.003
Ephemeral Single-Use Sandboxes for Tools
Medium
If command execution is required, use a customer-owned tool and broker that validate a signed invocation manifest and execute it in a separately isolated single-use sandbox. Disable the in-process shell. The sandbox must contain no resolved Harness credentials, shared credential-bearing memory or accessible vault material; independently test process, filesystem, network and teardown boundaries. A Code Interpreter session is only a candidate deployment surface, not proof of this architecture. The research did not validate this integration, so retain medium effectiveness until those prerequisites are verified.
AID-H-034.002
MCP Server OAuth Resource Boundary & Delegation Safety
Medium
Issue the operator service-account token only the scopes needed by the support tools and enforce the signed per-tool scope policy at the downstream MCP server. Independently validate token issuer, audience/resource, expiry and revocation on each request; scope narrowing limits damage but does not make a stolen still-valid bearer token unusable. Proof of possession needs a supported issuer/resource verifier and a private key inaccessible to the compromised shell; it is not established by G002 or by this source.
AID-E-001.002
Issued Token, Authentication Session & Lease Revocation
Medium
Treat the exposed MCP bearer token as compromised. Have every downstream verifier consult an independently protected revocation store on every request, deny the exact token generation and prove denial before replacing credentials. If the Cognito client-credentials issuer cannot revoke the access token, a verifier-side denylist is one pre-expiry option; independently enforced service-access fencing is another. Rotation alone leaves old tokens valid. Keep unsupported verifier paths unresolved until rejected live probes or expiry are verified.
AID-D-003.003
Agentic Tool Use & Action Policy Monitoring
Medium
Export actual Harness tool-call events and effective allowedTools decisions to a protected event store; alert when a support-answer session attempts `shell`, `file_operations`, a script-fetch command or `/proc` access. AWS trace availability does not by itself produce the signed, tamper-evident decision receipt in this howTo; the operator must implement that binding and verify event completeness before claiming high-confidence detection.

What Defenders Should Do Now

  • Derive allowedTools from each verified InvokeHarness task and configure a synchronous before_tool_call Lambda hook to deny shell and file_operations for support-answer work. Test denial on hook failure.
  • Limit MCP token scopes and verify issuer, resource, audience, expiry and scope at the resource server. After exposure, enforce per-request revocation or independent service-access fencing and probe with the old token. Vault credential rotation alone does not invalidate an existing JWT.
  • Run required commands in a separate environment containing no Harness credentials. Where customer-controlled routing exists, also enforce outbound destination restrictions and verify both boundaries independently.

1 additional consideration

Evidence and deployment boundary

Removing shell from a session is the practical customer gate. Strong same-UID process-memory separation is an architectural property of the runtime and cannot be inferred from a generic sandbox label.
Recommendation: At every InvokeHarness call, set allowedTools from the exact task; support-answer sessions that do not need shell or file operations must not receive those defaults.

Conclusion

AIDEFEND  points to Harness tool authorization, downstream MCP token verification and isolation of command execution from credential-bearing memory. The available before_tool_call hook can enforce the first boundary; a vault alone does not enforce the others.

Last updated: