AWS's agent runtime can be talked into handing over its own secrets

Unit 42 has published research showing that the default configuration of AWS's AgentCore Harness — the managed runtime that runs agents on Amazon Bedrock — can be steered into leaking the very credentials its identity system is built to protect. The finding, published on 18 September by researcher Niv Rabin, is not a break in the vault. It is a complaint about the door standing next to it.

The research examined two parts of the harness's integrations: AgentCore Identity, AWS's recommended way to manage agent identities and store credentials, and a downstream Model Context Protocol server that the harness authenticates against using a credential taken from that vault. AgentCore Identity does what an identity vault should do — encryption at rest and in transit, KMS-managed keys, IAM-gated access — so Unit 42 went looking at run time, at the moment a credential has to leave the vault to be used.

What it found is that the harness's own built-in shell tool, which is enabled by default, reaches into the same memory space where those credentials are resolved into plaintext. An attacker who can land a prompt injection on the agent can therefore use the agent's ordinary tooling to reach the secrets the agent was given, and exfiltrate them with the permissions the agent already holds.

AWS called it informative

Unit 42 disclosed the issue to AWS. AWS reviewed the report and closed it as informative under the AgentCore shared responsibility model, pointing to scoping of allowedTools and egress filtering as controls that sit with the customer. No CVE has been assigned and AWS has published no advisory of its own, so the practical guidance is the researchers' list: narrow the allowedTools the harness may use, apply least privilege to the identity vault service account the downstream integration relies on, and watch outbound traffic from harness containers.

That places the fix in the hands of the teams building on AgentCore rather than in a patch. The AWS documentation is explicit that the shell and file-operation tools are available out of the box, which means the default path into a deployment includes the tool that caused the problem.

Our opinion

The interesting part of this disclosure is not the mechanism, it is the reply. Calling a credential-exposure finding “informative” and pointing at customer-side scoping is defensible under a shared responsibility model, and it is also how a whole class of agent platform risk gets quietly transferred to whoever shipped the agent. Every team running an agent now has to treat its tool allow-list as part of its credential perimeter, because the agent that holds the key is by design the same thing an attacker can talk to. Unit 42's own suggested pairing — publish it alongside the Plugin4Shell work as a “your agent is the attack surface” set — is the honest framing for 2026: the new privileged identity in your infrastructure is the helpful assistant with the shell.