The Limits of Vaulting AI Agent Credentials

Quick Answer: Palo Alto Networks Unit 42 showed how a prompt-injected AWS AgentCore agent could steal and replay a credential even though it was securely stored in AgentCore Identity. The research exposes a broader problem with AI agent security: protecting credentials at rest and in transit is not enough if they become readable inside the agent runtime. Akeyless addresses that gap by keeping downstream credentials out of the agent process and governing what agents can do with authorized access.

What Happened in the AgentCore Test

On September 18, Palo Alto Networks’ Unit 42 published research that exposed an important gap in how AI agent credentials are protected at runtime. Researchers showed that the default configuration of AWS AgentCore Harness lets a prompt injection steer an agent into exfiltrating plaintext credentials that were managed by AgentCore Identity, AWS’s recommended identity and credential store for agents.

The vault itself did what it was designed to do. AgentCore Identity protected the credential at rest and in transit with encryption, KMS-backed keys, and IAM-gated access. Every checkbox a credential store is supposed to tick was ticked.

The exposure happened later, when the credential had to become usable plaintext inside the agent runtime. That distinction is the important part of the story.

The Details: How the Credential Was Exposed

Unit 42 built a fictional support company whose agent read inbound tickets and looked up account records through a downstream MCP server, using a standard, out-of-the-box deployment. This was a controlled security test, not a reported customer breach. The attack chain went like this:

1. A support ticket carried a hidden HTML comment instructing the agent to download a script and pipe it into Python using the harness’s built-in shell tool.
2. That shell tool ships enabled by default and runs as root inside the harness.
3. The shell process shared the same user ID as the harness runtime (PID 1), so its memory was fully readable via /proc/1/mem.
4. The harness had to resolve the vault ARN into a real JWT to authenticate to the MCP server, and that resolution happened inside PID 1’s memory.
5. A heap scan pulled out the live JWT and the MCP server URL, and posted both to an external webhook.
6. From a laptop with no AWS credentials at all, the researchers replayed the token, listed the MCP tools, and retrieved customer PII. They were also able to use that stolen access to create a support ticket.

The stolen token belonged to the operator’s service account, a stable, long-lived credential the operator configured when the harness was created and which was reused across sessions. The caller was only authorized to invoke the agent. The credential the caller captured, however, was authorized to reach everything the operator had connected.

AWS reviewed the report and closed it as informative under the shared responsibility model, pointing to allowedTools scoping and egress filtering as customer-side controls. That is a fair position, but it also means the burden lies with you.

Why This Goes Beyond AgentCore

The Unit 42 researchers put it this way: “Vaults protect at rest and in transit, not in use.”

Every credential an agent runtime resolves has to become plaintext to be useful. Unit 42’s closing recommendation is that any credential the runtime resolves must live somewhere the shell tool cannot read, or the shell must run in a sandbox isolated from the process that resolves it.

The same exposure exists in any architecture that hands a credential to the agent’s process, whether from a vault, an environment variable, a config file, or an MCP gateway that stores the key and forwards it. If the agent’s runtime holds the secret, and the agent can be talked into running code, the secret is one heap scan away. As Unit 42 notes, the model’s reasoning cannot reliably tell a legitimate instruction from an injected one. What an attacker can do is therefore bounded by what the shell tool can reach.

AWS’s own Harness documentation describes the same trust boundary: the Harness validates the structure of incoming requests, but does not inspect the meaning of prompts or enforce behavioral constraints on the agent. You cannot fix this by making the model smarter. This can only be fixed by making sure there is no credential in the runtime to find..

How Akeyless Breaks the Attack Chain

Akeyless Agentic Runtime Authority closes the runtime credential security gap. Rerun the SupportCo scenario with Akeyless in the access path and the chain breaks at step 4 and stays broken through step 6.

1. SecretlessAI™: the agent holds nothing, so the heap holds nothing. The harness never resolves a downstream credential at all. Instead of storing a service-account JWT and referencing it by ARN, the agent authenticates to the customer-side Akeyless Gateway using the workload identity its runtime already mints: in this case, the harness execution role, accepted through the Akeyless AWS IAM Auth Method. No secret is stored for the agent, no secret is fetched by the agent, and no secret is ever present in the agent’s process memory. A root shell scanning /proc/1/mem finds an IAM attestation it already had and nothing else.
2. The MCP connection is brokered inside the Gateway, not inside the harness. When the agent requests access to the downstream MCP server, the Gateway spins up and brokers the connection on the agent’s behalf. Credentials are injected into that brokered session inside the Gateway boundary, deployed in your environment, and are never returned to the agent. The agent talks to the Gateway. The Gateway talks to the target. The plaintext credential lives in neither the agent’s config nor the agent’s memory.
3. Nothing long-lived exists to replay. The stolen mcp-service token was valuable because it was stable and reused across every session. Akeyless replaces standing service-account credentials with just-in-time Dynamic Secrets: minted at the moment of execution with the minimum permissions for that one action, bound to a TTL, and destroyed on the target when the task completes. Even a hypothetically leaked session credential expires with the session. The replay-from-a-laptop step has no token to replay.
4. Zero direct connectivity means the replay target is unreachable anyway. With Runtime Authority, the agent has no direct network path to the MCP server; the Gateway is the mandatory route. An attacker’s laptop cannot present the harness execution role’s AWS IAM attestation, so it cannot authenticate to the Gateway, so it cannot reach the target. A stolen URL without a valid workload identity is a dead end.
5. Intent-aware policy and response masking limit what a hijacked agent can do and see. Runtime Authority classifies every requested action for intent (read-only, data modification, destructive, privilege escalation) and checks it against rules the target-system owners defined in advance, before any credential is minted. In the SupportCo case, the customer-lookup response would pass through in-session masking, so PII fields such as phone numbers and SSN fragments are redacted per policy before they reach the agent’s context window. Even a legitimately authorized query returns only what the rules permit.
6. One audit chain from prompt to action. Every request through the Gateway produces a single immutable record: which identity asked, what it attempted, how it was classified, which rule applied, whether it ran, and what happened on the target. The compliance question shifts from “the service account did it” to a traceable line back to the originating prompt.
7. The platform itself is beyond compromise. All of this runs on the Akeyless Identity Security Platform, protected by Akeyless DFC™ (Distributed Fragments Cryptography). Encryption keys exist only as separate fragments that are never combined in one place, delivering true Zero-Knowledge: not even Akeyless can read your secrets. The platform is FIPS 140-3 validated. When one system is minting and destroying credentials for every agent action, it matters that the system has no master key to steal.

What this Looks Like in Practice

The difference is visible in the agent configuration itself. A typical MCP agent configured to connect directly to three downstream tools can carry three separate credentials. The same agent on Akeyless carries zero:

{
  "mcpServers": {
    "akeyless-connector": {
      "command": "akeyless",
      "args": [
        "mcp-runtime-authority",
        "--gateway-url", "https://gateway.your-domain.internal:8000",
        "--profile", "support-agent-prod"
      ]
    }
  }
}

In this example, support-agent-prod uses the agent’s workload identity to authenticate to Akeyless rather than a stored access key.

One connector, every target, no secrets in the file, none in memory, none in the heap.

What Akeyless Does not Replace

To be clear, Runtime Authority does not turn off the AgentCore shell tool, and it does not filter your container egress. Unit 42’s recommendations to scope allowedTools per session, apply least privilege to every downstream service account, and monitor outbound traffic remain correct, and you should do all three.

The distinction is in what each layer accomplishes. AWS’s controls narrow how far an injected instruction can reach. Akeyless removes what it would find when it gets there.

The Takeaway

The AgentCore research is a controlled demonstration, not a breach, and AWS is right that operators own the configuration. But it proves something that applies to every agent platform, every framework, and every MCP integration you run today: a credential that is secured at rest and in transit, then resolved into the agent’s own process, is a credential that a prompt injection can take.

Akeyless Agentic Runtime Authority keeps the credential out of the agent runtime entirely. The Gateway brokers the connection and uses the credential there, so the agent’s heap stays empty.

Ready to see it on your own agents? Request a Runtime Authority demo and bring your current MCP config. We’ll show you how many secrets come out of it.

Frequently Asked Questions