AWS AgentCore Harness: When Prompt Injection Reaches Credentials

AI agents are increasingly being given the ability to execute code, access files and call downstream services. That combination can make an agent useful, but it also changes the consequences of prompt injection. A malicious instruction no longer needs to influence only an answer or a narrowly defined tool call. If the agent can operate a shell, the instruction may reach the runtime’s operating system, process space and network.

Research from Palo Alto Unit 42 illustrates that risk in Amazon Web Services (AWS) AgentCore Harness. In a test environment, Unit 42 chained an indirect prompt injection with the harness’s built-in shell tool and a downstream Model Context Protocol (MCP) integration. The researchers reported that this allowed a credential stored through AgentCore Identity to be recovered from the harness process and sent to an external endpoint.

The finding does not describe a compromise of AWS customers or a named victim. Unit 42 used a fictional support operation and a simulated MCP service. AWS reviewed the report and closed it as informative under the AgentCore shared responsibility model, according to Unit 42, pointing to customer-side controls including tool scoping and outbound-traffic filtering.

The security boundary is the agent runtime

AgentCore Harness is a managed runtime around an AI agent. Operators define the model, instructions, tools and integrations, while the service provides the surrounding environment, compute, memory, identity, networking and observability. That design allows an agent to plan and act across multiple steps rather than simply generate text.

Unit 42 focused on two relevant components: AgentCore Identity, which AWS recommends for managing agent credentials, and an authenticated downstream MCP server. The vault protects stored credentials with encryption at rest and in transit, AWS Key Management Service keys and IAM-controlled access. However, a credential cannot authenticate to a downstream service while remaining encrypted. At runtime, it must be resolved into plaintext somewhere in the process that uses it.

That distinction—protection at rest versus exposure in use—is central to the research. Unit 42 found that the harness’s built-in shell tool operated in the same memory space as the process handling the resolved credential. In the tested environment, the shell subprocess ran as root, and the researchers reported that the harness process memory was readable from that context.

The important issue is not simply that a shell exists. It is that a general-purpose shell can potentially reach whatever the runtime can reach: files, processes, network destinations and credentials temporarily held in memory. Prompt injection becomes an entry point into those capabilities.

How the tested attack chain worked

Unit 42 modeled a customer-support agent that read inbound tickets, queried account information through an MCP server and returned an answer to the person who submitted the ticket. The deployment used the harness, an authenticated downstream integration and the default built-in tools.

The researchers placed an indirect instruction in a support ticket using a hidden HTML comment. The instruction persuaded the agent to use the shell tool to retrieve and execute a remote reconnaissance script. Unit 42 said the test used a more permissive tool-calling model for this stage; the research does not establish that every model would respond in the same way.

Once code execution was achieved inside the harness, the researchers examined the runtime environment. They reported that the shell ran as root, that the relevant processes used the same user identity and that the harness process’s memory could be read. They then inspected the runtime’s process and file layout to identify the Python process associated with the harness and the installed AgentCore packages.

The next stage involved the credential used by the downstream MCP service. The harness was configured to reference a bearer token through an AgentCore Identity vault ARN in its authorization configuration. Unit 42 reported that the token and the downstream MCP server URL could be found in the harness process memory after the credential had been resolved for use.

In the simulated test, the researchers caused a script to search the process heap for those values. The script then sent the recovered token and service URL in an HTTP POST request to a simulated external endpoint. The report displays that infrastructure as webhook[.]site; this is a research artifact and should not be treated as evidence of a real victim or a broader campaign.

Unit 42 subsequently replayed the token from a separate laptop against the simulated MCP service. The researchers reported that the credential allowed them to list tools, invoke a customer-lookup function that returned simulated personal information and create a ticket. The test therefore demonstrated more than local secret exposure: a downstream service credential could be extracted and used outside the AWS environment, subject to the permissions granted to that account.

Why the credential’s identity matters

The recovered token was not an end user’s session credential. Unit 42 identified it as belonging to an operator-managed service account named mcp-service. That distinction affects impact assessment.

A caller may be authorized to invoke a harness without being authorized to access every service wired into it. The harness’s execution role and its configured downstream credentials can possess a different and potentially broader set of privileges. If a prompt injection causes the runtime to expose one of those credentials, the attacker may obtain the authority assigned to the service account rather than the narrower authority of the person who submitted the request.

The research does not claim that every AgentCore deployment exposes the same data or grants the same permissions. The consequences depend on the integrations configured, the identity-vault service account’s scope, the process isolation model and the network paths available from the harness.

Defaults and configuration scope

According to Unit 42, AgentCore Harness provides the built-in shell and file_operations tools in each session unless the operator restricts them with allowedTools. The shell executes Bash commands, while the file tool supports reading, creating and editing files.

The researchers emphasized that these tools are available by default and that allowedTools is applied at invocation time rather than when the harness is created. That makes configuration review especially important: a deployment may appear to define only a narrow business function while still giving sessions access to general-purpose runtime capabilities unless the invocation policy removes them.

Unit 42 assessed that the default configuration creates a reachable credential-theft path when prompt injection, shell access, readable process memory and outbound connectivity occur together. This is a researcher assessment based on the tested setup, not a statement that all AgentCore environments are compromised or vulnerable in identical ways.

Detection and threat hunting

Security teams should begin with configuration and identity inventory rather than assuming that an agent’s natural-language instructions provide a security boundary.

• Review every harness invocation policy and explicitly limit allowedTools to the capabilities required for that session. Remove shell and file access from workflows that do not need them.
• Identify credentials resolved through AgentCore Identity and map each one to its downstream integration, service account and permitted operations.
• Look for outbound connections from harness containers or agent runtimes to destinations outside the approved downstream-service list. Unit 42 recommends treating unexpected egress as a possible sign of active prompt injection rather than automatically dismissing it as configuration drift.
• Correlate agent invocation records with shell-tool use, file operations, process inspection and unusual outbound HTTP activity. The source research does not provide a specific detection rule, so organizations should adapt these signals to their own telemetry.
• Review downstream-service logs for use of the harness service account from unexpected network locations, at unusual times or in patterns inconsistent with normal agent workflows.
• Use synthetic, non-production testing to determine whether untrusted content can cause the agent to invoke tools or reach destinations outside its intended task.

What organizations should do now

1. Disable unnecessary built-in tools. Apply allowedTools at invocation time and provide shell or file capabilities only where there is a documented business need.
2. Reduce service-account authority. Give each Identity vault credential only the permissions needed for its specific downstream integration. A leaked credential’s practical impact is constrained by the authority attached to it.
3. Constrain egress. Permit harness network traffic only to approved services and monitor denied and successful connections. This does not prevent every form of misuse, but it can limit exfiltration and provide a useful detection signal.
4. Separate sensitive processes and credentials. Where architecture allows, isolate the tool-execution environment from the process that resolves credentials. Unit 42’s broader design recommendation is that credentials should either be unavailable to the shell or be handled in an environment the shell cannot inspect.
5. Review untrusted inputs. Treat support tickets, documents, web content and other agent-readable material as potential prompt-injection carriers. Agent instructions should not be treated as a reliable substitute for authorization controls.
6. Prepare a response process. If a credential may have been exposed, identify the affected service account, revoke or rotate it according to the organization’s procedures, review downstream access logs and preserve relevant harness and network telemetry.

Conclusion

Unit 42’s testing highlights a specific weakness in the way agentic systems combine autonomy and access. AgentCore Identity can protect secrets while stored and transmitted, but the credential must become usable plaintext during authentication. If a shell tool can inspect the same runtime memory, a prompt injection that reaches that shell may turn a vault-protected secret into a replayable downstream credential.

The practical lesson is to treat every agent capability as part of the security boundary. Tool minimization, least-privilege service accounts, process isolation and strict egress controls are complementary safeguards. The source research does not establish a CVE, named threat actor or confirmed victim set, and none is identified here.

Sources

• Palo Alto Unit 42: A Vault with a Heap-View: The Uncomfortable Space Between AgentCore Harness and Identity