Credential Vaulting for AI Agents Guide: Keeping Secrets Out of Prompts and Code

Most AI agents today reach their tools with static API keys and tokens that sit in prompts, configuration files, environment variables or the repository the agent is working in, where the agent, its tools and anyone who can steer it with injected text can read them. Credential vaulting changes that: the secret lives in a vault or broker, the agent receives a short-lived, narrowly scoped credential at the moment it needs one, and every release is logged against a named agent identity. This guide covers the architecture patterns, how to scope and expire agent credentials, how to deliver them without exposing them to the model, and how to roll the approach out and measure it. It is written for platform, security and identity engineers who run agents in production, on developer workstations or inside CI/CD.

Key takeaways

• The model must never see the secret. Credentials belong in the tool or broker layer that makes the call, not in system prompts, context windows, agent memory or tool output; OWASP is explicit that a system prompt is not a security control.
• Anything the agent can read, injected text can exfiltrate. Prompt injection turns every credential in the agent's environment, files or context into a target, so reduce what is reachable before you tune detection.
• One agent, one identity, one scoped credential per task. Shared keys across agents or with humans destroy attribution and make revocation disruptive.
• Short-lived beats rotated. Dynamic credentials with leases of minutes to hours, or federated workload identity with no stored secret at all, shrink the value of a stolen credential far more than a 90-day rotation schedule.
• The vault is only as good as its release policy and its logs. Decide who or what may release which credential, under what conditions, and alert on releases that do not match a running task.

Why agents need a different credential model

Traditional service accounts run fixed code paths: you can read the code and know which secret is used for what. An agent decides at run time which tools to call, with which arguments, based on text that may come from untrusted sources. Three properties follow.

• Reachability equals exposure: an agent with file and shell tools will search the workspace when it gets stuck. In the PocketOS Database Deletion 2026, a coding agent found an account-scoped Railway token in a file unrelated to its task and used it to delete a production volume and its backups. Nobody gave the agent that token; it was simply there.
• Inherited environments leak everything: local tools and MCP servers started by an agent client usually inherit the developer's environment. In the Amazon Q MCP Config Vulnerability 2026, servers defined in a repository's configuration started with the developer's AWS session, API keys and SSH agent access available to them.
• Instructions arrive as data: in the Sentry MCP Agentjacking 2026 research, a fake error report read through an MCP server told coding agents to run a package that probed the environment for cloud, GitHub, npm, Docker and SSH credentials. Vaulting does not stop the injection, but it decides how much the injected command can find.

The design goal is therefore not only "store secrets securely" but "make the secret unreachable to the reasoning loop and worthless shortly after use". See the Secrets Management Guide for the general foundations this guide builds on.

Where agent credentials leak today

Vaulting architecture patterns

There are four common patterns. Most organisations end up using two or three of them, chosen per target system.

• Dynamic secrets in practice: in HashiCorp Vault every dynamic secret carries a lease with a lease_id and TTL. Leases can be renewed with vault lease renew, revoked one at a time with vault lease revoke, or revoked in bulk by path with vault lease revoke -prefix aws/, and revoking a token revokes every lease it created. For the AWS secrets engine, revoking the lease deletes the access key in AWS. This is the property you want for agents: when the task or the agent is suspect, revocation is one operation.
• Broker separation: agent identity services from cloud providers follow the broker idea. AWS documents that AgentCore Identity separates credential storage from credential access so agents never directly access long-term secrets or refresh tokens, and it supports OAuth 2.0 tokens, API keys, client certificates and other credential types through credential providers.
• Workload identity: SPIFFE's Workload API gives a workload its SPIFFE ID, a private key and a short-lived X.509 or JWT SVID without the workload needing any prior secret, which is how you avoid the "secret zero" problem. SPIFFE recommends X.509-SVIDs where possible because JWT-SVIDs are susceptible to replay. See the Workload Identity Federation Guide.
• Delegation for user-facing agents: when an agent acts for a person, OAuth 2.0 Token Exchange (RFC 8693, grant type urn:ietf:params:oauth:grant-type:token-exchange) lets a broker swap the user's token (subject_token) and the agent's own token (actor_token) for a new token whose act claim records the agent as the actor. That keeps the agent's identity visible downstream rather than having it impersonate the user. See the OAuth Token Exchange and Delegation Guide.

Scoping, lifetime and release policy

A vault that hands any agent any secret on request has moved the problem, not solved it. Define release policy in four dimensions.

• Identity: each agent (and ideally each agent deployment or environment) has its own vault identity, authenticated by platform attestation rather than a stored token. No agent shares a credential with a human or with another agent. See the Agentic AI Identity Guide.
• Scope: one credential per target and purpose, scoped to one environment. The PocketOS token was created to manage custom domains but was account-scoped across every workspace; a domain-only, staging-only credential could not have deleted production. For OAuth targets, request the narrowest scopes and use the resource parameter (RFC 8707) so the token is audience-bound.
• Lifetime: set TTLs to the expected task duration plus a margin, typically minutes for interactive tasks and no more than a few hours for batch work. OWASP notes that restarting an application does not revoke a stolen credential; only lease expiry or explicit revocation does.
• Conditions: release only when a task is running (correlate with the orchestrator's task ID), from the expected runtime, and, for destructive or production scopes, only after an approval bound to the exact action and parameters. The OWASP AI Agent Security Cheat Sheet recommends short-lived approvals with replay protection and failing closed if checks or audit logging fail.

Keeping secrets out of prompts, context and code

1. Move authentication into the tool layer. The tool or MCP server that calls the API obtains the credential itself. The model sees a tool called create_ticket, not a token. OWASP LLM07 advises externalising credentials to systems the model does not directly access.
2. Do not put credentials in tool arguments. If a tool schema has an api_key parameter, the model will be asked to fill it, which means the key must be in its context. Remove such parameters.
3. Scrub tool output. Run secret pattern detection over tool responses before they enter the context window and over anything written to long-term memory. MITRE D3FEND calls the general technique Credential Scrubbing (D3-CS).
4. Start child processes with a minimal environment. Local MCP servers and command tools should receive only the variables they need, not the parent's full environment. The Amazon Q case shows why: inherited environments put every workstation credential within reach of a malicious server.
5. Keep shared configuration secret-free. Managed or committed MCP configuration files are readable by many users. Claude Code's documentation, for example, warns administrators not to store API keys in the env blocks of its system-wide managed MCP file and to use per-user OAuth, environment expansion or a helper that generates headers at connection time.
6. Prefer files or sockets over environment variables for delivery when a secret must be present. The OWASP Secrets Management Cheat Sheet recommends mounted files or in-memory sidecar delivery and does not recommend environment variables unless other methods are impossible.
7. Block secrets at commit time. Coding agents commit code. Enable pre-commit scanning and server-side push protection; GitHub push protection covers command-line pushes, web commits, uploads, REST API requests and, for public repositories, GitHub MCP server interactions. See the Git Secret Scanning Guide.
8. Use secure introduction for bootstrap material. If an agent runtime must receive an initial secret, deliver it in a single-use wrapper such as Vault response wrapping (X-Vault-Wrap-TTL), so interception is detectable because the wrapping token can only be unwrapped once.

Choosing an approach

• Target supports federation (cloud IAM, internal services with OIDC): use workload identity and skip stored secrets entirely. This is the default for cloud resources.
• Target is a database or system with a dynamic secrets engine: use dynamic credentials with short leases and per-agent roles.
• Target is a SaaS API that only accepts static keys: broker the call so the key never leaves the broker, and rotate the key on a schedule. Runtime retrieval into the agent process is the fallback when no broker exists.
• Agent acts on behalf of a user: use delegated OAuth with token exchange or per-user consent, so the agent cannot exceed the user's rights and the audit trail shows both parties.
• Developer workstation agents: the biggest gain is removing long-lived credentials from the laptop: SSO-issued short cloud sessions, no production keys locally, and minimal environments for agent child processes. See the AI Coding Agents Security Guide.
• Small organisations: start with the cloud provider's managed secrets service and managed identities, plus secret scanning. A broker can come later.
• Large organisations: standardise one release policy model across vaults, publish an agent credential catalogue (owner, scope, TTL, target), and run the broker as a shared platform service with its own high-availability and incident plan. See the Secrets Management Buyer's Guide when evaluating platforms.

Implementation roadmap

1. Inventory (weeks 1 to 3): list every agent, its tools and MCP servers, and every credential each one can reach, including environment variables, files in its workspace and keys in prompts or configuration. Run secret scanners over agent repositories, prompt templates, memory stores and trace exports.
2. Remove the worst exposure first: take credentials out of system prompts, tool arguments and committed configuration. Revoke and reissue any secret found in a prompt or log, because you cannot know who saw it.
3. Issue agent identities: give each agent a workload identity in the vault or identity platform. Disable any shared "agents" credential.
4. Pilot one pattern on one agent: pick a low-risk agent, move it to dynamic or brokered credentials, and run in parallel with logging only. Confirm the agent works with the shorter TTL and that release logs carry the agent and task identifiers.
5. Enforce: remove the old static credential, set release policies to deny by default, and add approval requirements for production write and destructive scopes.
6. Expand by risk: production data access, then customer-facing agents, then developer workstation agents and CI/CD agents.
7. Rollback: keep the previous credential disabled rather than deleted for a defined window (for example 7 days) so a failed migration can be reversed by re-enabling it, then delete and confirm it no longer authenticates. Use the Secrets Rotation Runbook Template for the cut-over steps.

Detection and measurement

The OWASP Secrets Management Cheat Sheet lists what vault audit logs should capture: who requested secrets and whether requests were approved, when and by whom secrets were used, expiry events, attempts to reuse expired secrets, authentication and authorisation errors and administrative actions. For agents, add the agent identity, the orchestrator task ID and the tool call that triggered the release.

• Release without a task: a credential released when no task for that agent is running, or from an unexpected runtime or network location.
• Scope drift: an agent requesting a credential outside its catalogue entry, or a sudden first-time request for a production or destructive scope.
• Use outside the expected path: a brokered or dynamic credential presented from an IP address or service other than the broker or agent runtime, which suggests theft (ATT&CK T1528 Steal Application Access Token, T1550.001 Application Access Token).
• Secrets in the wrong place: scanner hits in prompts, traces, memory stores or agent commits (ATT&CK T1552.001 Credentials In Files; ATLAS AML.T0055 Unsecured Credentials).
• Metadata endpoint access: agent tools or MCP servers calling the cloud instance metadata service, a known route to cloud credentials (T1552.005).

Common failure patterns

• Vault in front, static key behind: the agent fetches a long-lived, broadly scoped key from the vault at start-up and keeps it in memory for days. The vault adds an audit trail but no reduction in blast radius.
• Old credentials left reachable: teams move an agent to vaulted credentials but leave the previous token in a .env file or script. Agents search; the PocketOS token was in an unrelated file.
• One credential for the whole agent fleet: a single service account shared across agents means you cannot tell which agent did what, and revoking it stops all of them.
• Trusting inherited environments: local MCP servers, plugins and shell tools run with every credential in the developer's session, so one malicious server or injected command reaches all of them.
• Secrets echoed into context: a tool reads a configuration file or returns an HTTP error containing a token, and the model writes it into a ticket, a commit message or memory.
• Unprotected broker: the credential broker or AI gateway accepts weak or default authentication, so attackers go straight to the component holding every key. The LiteLLM MCP Auth Bypass 2026 exposed provider keys held by an AI gateway.

Framework mapping

Practitioner checklist

• No credentials in system prompts, agent instructions, tool schemas or committed MCP configuration; any found have been revoked and reissued.
• Every agent has its own workload identity and a catalogue entry naming owner, targets, scopes and TTL.
• Cloud and internal targets use federated workload identity; databases use dynamic credentials with short leases.
• SaaS keys that cannot be federated are held by a broker or gateway, never by the agent process.
• Production write and destructive scopes require an approval bound to the exact call, or are not released to agents at all.
• Child processes, local MCP servers and shell tools start with a minimal environment.
• Tool output, traces and memory writes are scanned and redacted for secrets.
• Push protection and pre-commit scanning are on for every repository agents commit to.
• Vault logs carry agent identity and task ID, and alert on releases without a running task.
• Revoking all credentials of one agent has been tested and takes minutes.

Standards and references

• OWASP: Secrets Management Cheat Sheet
• OWASP: AI Agent Security Cheat Sheet
• OWASP: Top 10 for LLM Applications 2025
• IETF: RFC 8693 OAuth 2.0 Token Exchange
• Model Context Protocol: Authorization specification
• SPIFFE: SPIFFE Concepts
• HashiCorp: Vault Lease, Renew, and Revoke
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Secrets Management Guide · AI Agent Authorisation Guide · MCP Security Guide · Secrets Rotation Runbook Template · Secrets Management Buyer's Guide