Should organisations use a credential vault for AI agents or keep secrets in environment variables?

Why vaulting matters for AI agents

AI agents are most safely treated as runtime participants, not as places to store long-lived secrets. A credential vault keeps issuance and revocation under server control, which means the agent can be given only the access needed for a task and only for as long as that task lasts. That reduces the blast radius when prompts, logs, memory, or tools are exposed.

Environment variables are convenient, but they are still readable process state. Once a raw secret is injected into the runtime, it tends to spread into crash dumps, debug output, inherited child processes, and adjacent tooling, which makes containment and rotation much harder.

What changes operationally when secrets stay outside the agent process?

With a vault-backed model, the control point moves from the agent to the server that brokers access. That creates a clearer ownership boundary for issuing, refreshing, and revoking credentials, and it lets the agent call for a scoped token rather than hold the underlying secret itself. For agent systems that already use delegated access patterns, this is the cleaner design because privilege can be narrowed per action instead of being embedded in the runtime.

By contrast, environment variables encourage a static configuration model. They work best for simple boot-time settings, not for credentials that should expire, be exchanged, or be revoked independently of the agent lifecycle. If a secret must survive for the whole process, then compromise of the process usually means compromise of the credential.

For implementation detail on least-privilege agent access, AI Agent Authorisation Guide is a useful companion, because it shows how task-scoped and per-action decisions reduce overreach. For identity handling across the agent lifecycle, Agentic AI Identity Guide explains why registration, delegation, and retirement need to be explicit rather than implicit.

Where environment variables break down in practice

The main weakness is not that environment variables are always instantly exposed, but that they are difficult to govern once they exist. A secret in an env var is often copied, inherited, or logged without any central policy decision, so the organisation loses visibility over where it is used and how widely it can be replayed. That is especially risky when the same agent can invoke tools, call APIs, or hand work to other systems.

Vaults also help with rotation discipline. If the secret is externalised, the server can rotate or revoke it without waiting for every agent instance to be rebuilt. That matters when an agent crashes, restarts, or is scaled horizontally, because stale secrets in memory or configuration are much harder to retire cleanly.

For broader guidance on why storing secrets in agent context is a recurring failure mode, AI Coding Agents Security Guide covers how secrets leak through toolchains and runtime context. For a related threat pattern around consent and token theft, CoPhish OAuth phishing via Copilot Studio is a concrete example of why token handling needs to be tightly governed.

Risk and Threat Considerations

Putting secrets in environment variables increases exposure because the agent process becomes both the consumer and the de facto storage location. If the process is compromised, inspected, or misconfigured, the secret can be reused directly, and downstream abuse can extend well beyond the original task or session.

Failure mechanism: Secrets placed in process environment are easier to inherit, leak, or reuse than short-lived credentials issued from a brokered vault, so compromise of the agent runtime can become credential compromise.

Impact: Attackers or misbehaving tools can pivot from one compromised agent session into API abuse, lateral access, or unauthorized actions, and responders may need to revoke broadly because the original secret was never tightly scoped.

For a broader attacker and control view of this pattern, Agentic AI Security Guide maps the threat surface around tools, memory, and identity, while AI Agent Observability, Audit and Incident Response Guide shows why revocation and attribution become harder once secrets have spread into runtime state.

Practitioner Guidance

What to verify: Confirm that the agent never receives a reusable long-lived credential when a short-lived token or brokered exchange will do. The test is simple: if the value can be replayed outside the intended action window, it is too powerful to live as an env var.

Decision rule: Use environment variables only for low-risk configuration values, not for secrets that need central rotation, revocation, or per-action scoping. If the credential can reach production systems or external APIs, treat vaulting as the default and env vars as an exception requiring explicit acceptance.

What good looks like: The agent asks for access when needed, receives a narrow credential, and loses that access automatically when the task ends or the server revokes it. In that state, compromise of the agent process does not automatically equal compromise of the underlying secret.

Practitioner takeaway: The key design choice is not storage convenience, but control over issuance and blast radius, and that control belongs outside the agent process.

Related resources from NHI Mgmt Group

• How can organisations govern AI agents that use service accounts and tokens?
• What is the difference between managed identities and hardcoded secrets for AI agents?
• How should teams govern AI agents that use MCP?
• Why are AI agents creating a new category of secrets risk?