Prompt injection in AWS AgentCore: when a vaulted credential becomes readable

A credential can be encrypted in a vault and still become readable when an AI agent uses it. Research published by Niv Rabin at Palo Alto Networks Unit 42 on 18 September 2026 demonstrates that gap in a controlled AWS AgentCore support deployment.

A poisoned support ticket steered the agent into shell execution. The researchers then extracted a downstream service credential from runtime memory and replayed it against their test Model Context Protocol (MCP) server. The report describes a fictional company and researcher-operated infrastructure. It establishes no customer breach, cross-tenant compromise or failure of vault encryption.

The AWS AgentCore prompt injection case connects three boundaries security teams need to examine together: who supplies the content, what the agent can execute and where credentials become accessible during use.

How a support ticket reached a service credential

Unit 42 built a fictional support operator called SupportCo. Its agent read incoming tickets and retrieved account information through an authenticated downstream MCP server. AgentCore Identity stored the service credential, and the integration referred to that credential by its vault resource identifier.

The researchers first asked the model to perform shell-based reconnaissance. It refused repeatedly. They then selected a more permissive model using the per-invocation model configuration. That choice is a material condition of the demonstration: the report does not establish that every model or deployment follows the same path.

The successful indirect prompt injection placed instructions in a hidden HTML comment inside a support ticket. At a structural level, the chain was:

1. The agent read attacker-controlled ticket content while carrying out a support task.
2. Embedded instructions induced it to use its available shell tool to retrieve and execute a researcher-controlled script.
3. That execution reached the runtime process’s memory, where the downstream credential had been resolved into plaintext.
4. The script transmitted the credential and the MCP service address to a simulated attacker endpoint.
5. The researchers replayed the credential from their laptop, listing tools, retrieving test account data and creating a ticket.

This is a prompt injection attack because lower-trust task content influenced the agent’s operational instructions. The ticket’s author gained influence over capabilities belonging to the operator. Our prompt injection examples explain related transitions from retrieved content to agent actions.

Encryption and runtime isolation protect different stages

AgentCore Identity provides encryption at rest and in transit, key management and access controls. Those protections remained compatible with the observed exposure: the runtime needed the usable credential to authenticate to the downstream service.

Unit 42 reports that the built-in shell ran as root inside the tested environment and could read the runtime process’s memory. The security-relevant connection was between agent-directed execution and the process holding the resolved credential. Isolation between those components determines whether shell access can reach authentication material already in use.

The extracted credential belonged to the operator’s downstream service account. Its authority was separate from the end user’s permission to invoke the agent. Replay demonstrated that the credential retained useful access outside the original agent session in the researchers’ setup. Its downstream permissions therefore shaped the potential consequences of disclosure.

The Amazon Kiro repository-content case and SiYuan MCP file-upload case involve different products and mechanisms. They share a useful review question: can untrusted content direct an available tool towards sensitive data and a destination the task never required?

What AWS’s tool controls actually cover

The AWS tools documentation confirms that built-in shell and file-operation tools are available in every session unless restricted with allowedTools. When that parameter is omitted, all tools are allowed.

AWS also defines a specific scope for the control. allowedTools governs LLM tool selection during InvokeHarness. The separate InvokeAgentRuntimeCommand API executes commands directly and has its own IAM permission. AWS instructs operators to withhold that permission when direct command execution must be prevented. A tool-selection restriction consequently needs a separate review of command-API access.

According to Unit 42’s disclosure timeline, the researchers reported the finding on 19 May 2026. AWS closed it as informative on 10 June under the shared responsibility model, citing tool scoping and egress filtering as customer-side controls. The report states no CVE or vendor patch. That closure records AWS’s reported disposition; it provides no evidence of a particular deployment’s present security state.

Review the complete credential-use path

For teams operating agents with authenticated downstream integrations, the demonstration suggests five concrete checks:

• Scope tools per task. Explicitly select the tools each invocation needs. Remove shell and file access from support workflows that can complete their work through narrower operations.
• Separate execution from credentials. Assess whether agent-directed code can read processes holding service secrets. Require an isolation boundary appropriate to the credential’s authority.
• Minimise downstream permissions. Give service accounts only the operations and records the workflow needs. Document revocation and rotation procedures for suspected exposure.
• Constrain outbound destinations. Limit runtime network access to required services and investigate unexpected traffic. Treat destination monitoring as evidence to investigate, with context about the invoked task.
• Test the deployed configuration. Use controlled data to examine model refusals, allowed tools, command-API permissions and credential reachability together. Repeat those checks when models or integrations change.

Promptective has not independently reproduced Unit 42’s demonstration. Its practical lesson is to evaluate credential storage, runtime access and proposed agent actions as distinct controls. Each boundary needs evidence that the intended restriction holds in the deployed workflow.

Sources

• Niv Rabin, Unit 42: AgentCore credential research, published 18 September 2026.
• AWS: Amazon Bedrock AgentCore tools documentation, accessed 20 September 2026.