An encrypted credential vault is not a runtime boundary. Agent tools can still see plaintext.

Unit 42 found that AgentCore Harness can resolve vaulted credentials into the same runtime environment as an agent's built-in shell. The production control is to separate credential use from general-purpose execution, not merely encrypt secrets at rest.
On 18 September, Unit 42 reported that Amazon Bedrock AgentCore Harness can place credentials from AgentCore Identity into the same runtime environment as its built-in shell tool. The vault still encrypts secrets at rest and in transit. The problem begins after a credential is legitimately resolved to plaintext for use.
That distinction matters because prompt injection is an execution problem, not a storage problem. A model steered by untrusted content does not need to break KMS or defeat the vault if an authorised runtime can already obtain the secret and a general-purpose tool can inspect the environment around it.
Vault security ends where credential use begins
AWS documents AgentCore Identity as a token vault with workload identity, user context and IAM controls. It also documents Harness sessions as isolated Firecracker microVMs. Those controls protect important boundaries, but they do not make every capability inside one authorised session mutually isolated.
Unit 42's finding is therefore more useful as an architecture test than as a verdict on secret storage. Ask what happens after the vault approves retrieval: which process receives the credential, which tools share that execution context, whether arbitrary shell or code execution is present, and whether the credential can be exchanged for a narrower token instead of exposed directly.
A secret can be perfectly protected in storage and still be overexposed at the moment an agent is allowed to use it.
Tool policy must constrain the blast radius
AWS's own Harness security guidance provides the complementary control. AgentCore Gateway can apply Cedar policies to decide who may call which tool, under which conditions and with which arguments. AWS also recommends scoping execution roles, credential-provider access and network paths rather than relying on a shared service identity.
That means the credential boundary should follow the operation. A calendar tool should receive the minimum user-scoped token needed for that call. A shell should not inherit unrelated SaaS credentials merely because both capabilities belong to the same agent session. High-value credentials should sit behind mediated tools or brokers that perform the action without returning reusable secret material to the model-controlled runtime.
Add runtime exposure to the agent threat model
Security reviews already inventory model access, MCP tools and IAM permissions. Add one more artefact: a credential-exposure map showing where every secret becomes plaintext, how long it remains usable, which tools can observe it and what policy is re-evaluated before use.
Then test prompt-injection scenarios against that map. The acceptance criterion is not that the vault resisted extraction while idle. It is that compromised model reasoning cannot turn an authorised credential path into authority outside the intended operation.
Sources
Written by the Devence Lab research team.




