Secure agent runtimes close the gap vaults leave open

At a glance

What this is: This is an analysis of how a secrets manager and a secure agent runtime split storage from execution, with the central finding that protecting credentials at rest does not by itself control how an AI agent uses them.

Why it matters: It matters because IAM and security teams now have to govern credential use at runtime, not just storage and rotation, when agents can request actions through tools and APIs.

By the numbers:

• 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management, according to the 2024 State of Secrets Management Survey.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.

Context

A secrets manager solves storage, rotation, and issuance, but it does not automatically control what happens after a credential is retrieved. In AI agent workflows, that gap matters because the credential can be copied into logs, traces, memory, or tool outputs unless execution is governed separately.

The core governance problem is not secret storage alone, but secret use inside an agent-driven action path. That is why runtime policy, not just vault policy, becomes part of the identity control surface for AI agents and their delegated access flows.

Key questions

Q: What breaks when an AI agent receives the secret instead of a reference?

A: The control boundary breaks because the credential can leak into logs, memory, traces, or tool flows outside the vault. Once the agent receives the raw value, storage security no longer guarantees use security. A governed runtime keeps the secret out of the model path and applies it only when policy approves the action.

Q: Why does runtime policy matter if the vault already secures the credential?

A: Because the vault only governs storage and retrieval, while runtime policy governs whether the action should happen at all. If policy is checked before retrieval, a denied request never exposes the secret. That changes the control point from secret custody to secret-mediated execution, which is the real risk in agent workflows.

Q: What are the signs that secrets are being overexposed in agent workflows?

A: Look for credentials appearing in prompts, logs, traces, memory stores, or repeated tool configuration updates. Those are signs that the agent is handling secret values directly instead of references. When that happens, rotation and vault hygiene are no longer enough because the exposure path has moved into the execution layer.

Q: What are the best practices for rotating credentials for AI agents?

A: Rotate AI agent credentials regularly and whenever an agent is reconfigured, retired, or suspected of compromise. Use short-lived secrets where possible, separate credentials per agent and environment, and revoke unused tokens immediately. Monitor for failed authentications, unusual token use, and privileges that outlast the task the agent is meant to perform.

Technical breakdown

Why secrets at rest are not enough for AI agent execution

A secrets manager is designed to keep credentials stored, rotated, and retrievable under policy. A secure agent runtime changes the control point by preventing the agent from ever handling the secret value directly. Instead, the agent passes a tool request and business parameters, while the runtime resolves the credential inside a controlled boundary. That boundary matters because the moment a secret is delivered to the model or its surrounding workflow, it can leak into logs, memory, traces, or downstream tool calls. The architectural shift is from secret possession to secret-mediated execution. See the Secrets Management Guide.

Practical implication: Separate secret storage from secret use so the agent never receives raw credentials.

How policy enforcement changes when access is resolved at runtime

Runtime resolution means the policy decision happens before the secret is fetched, not after the agent already has it. That order matters because authorization can block an action before any credential leaves the vault. The runtime then applies the current credential on behalf of the agent and can strip or suppress sensitive response fields before returning a result. This is a different control model from handing a token to an agent and trusting it to behave. The design turns the runtime into an enforcement boundary, not just an execution wrapper. See the AI Agent Authorisation Guide.

Practical implication: Put policy in front of secret retrieval and treat the runtime as the enforcement point.

Why vault references are safer than copied values in agent workflows

A reference-based design keeps the vault as the system of record and lets the runtime resolve the current secret only when needed. That avoids static placement of credentials in agent configuration, which is where drift and reuse create exposure. It also means rotation can happen without reconfiguring every agent, because the reference stays stable while the underlying secret changes. In practical terms, the agent works with an identifier, not an authenticator. That is the difference between governed use and uncontrolled propagation. Read Guide to NHI Rotation Challenges.

Practical implication: Store references in agent tooling and resolve the live credential only at execution time.

NHI Mgmt Group analysis

Runtime governance is the missing control layer in agentic secrets management. A vault can protect storage, but it cannot by itself govern what an AI agent does after retrieval. The article's core point is that secret exposure now depends on execution-time handling, not just at-rest protection. That shifts identity control from the vault boundary to the action boundary, where policy, tool mediation, and response filtering determine whether the credential becomes visible at all. The practitioner implication is that storage controls and use controls must be treated as separate control planes.

Secret possession is the wrong trust model for AI agents. The old assumption is that the identity can hold a credential long enough to use it safely. In an agent workflow, that assumption breaks because the credential may move through logs, memory, traces, or tool chains the moment it is handed over. The result is credential sprawl inside the runtime itself, even when the vault is correctly managed. Practitioners should treat direct credential delivery to agents as a governance failure, not just a storage issue.

Ephemeral credential trust debt: every design that copies a live secret into an agent increases the chance that governance ends at the vault and exposure begins in the workflow. The article shows that the real control objective is not merely issuance and rotation, but constrained use under policy at the point of action. That makes agent execution a first-class identity concern, not an implementation detail. The implication is that teams must design for mediated use rather than assumed restraint.

Agentic access control has to separate request authority from credential authority. The agent may be allowed to ask for an action, but it should not inherit the secret itself as part of that request path. This distinction matters because shared workflow tooling often blurs who is authorised to decide, who is authorised to fetch, and who is authorised to act. When those boundaries collapse, the vault becomes a storage dependency instead of a governance control. Practitioners should preserve that separation as the basis for AI agent identity design.

From our research library:

• Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
• 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
• Read next: Secrets Management Guide

What this signals

Secret mediation is becoming the real control plane for AI agents. Teams that only harden vaults will still miss the exposure point if agents can receive raw credentials during execution. The more durable pattern is to keep the secret behind a runtime boundary and let the agent request actions, not values.

Reference-based credential use should replace credential copying wherever possible. When agent tooling stores a vault path instead of a secret, rotation becomes easier and the blast radius of a workflow compromise shrinks. That design choice also makes audits more meaningful because the control objective is use, not just storage.

The governance question is shifting from whether a secret is protected in storage to whether the system can prevent it from becoming visible during tool execution. That is the line security and identity teams will need to draw in agent-enabled environments.

For practitioners

• Define a runtime enforcement boundary Keep the vault as the system of record and require the runtime to resolve credentials only after policy approval.
• Remove raw secrets from agent context Pass tool names, vault references, and business parameters to the agent instead of copying credential values into prompts or tool state.
• Audit credential propagation paths Check logs, traces, memory stores, and tool outputs for any point where a secret can escape the controlled execution boundary.
• Treat rotation as a reference problem Keep references stable while rotating the underlying secret so agents do not need direct credential updates.

Key takeaways

• A secrets manager can protect credentials at rest without controlling how an AI agent uses them during execution.
• The main governance gap is the handoff point between retrieval and action, where secrets can leak into logs, memory, or tool flows.
• Runtime mediation changes the control model by keeping raw credentials out of the agent path and enforcing policy before retrieval.

Related NHI Mgmt Group resources: Secrets Management Guide · Guide to the Secret Sprawl Challenge · AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide

Key terms

• Secure Agent Runtime: A secure agent runtime is the execution layer that governs what an AI agent can do with a credential without handing the credential to the agent itself. It mediates policy checks, tool use, and response handling so the secret stays inside a controlled boundary during execution.
• Secret Reference: A secret reference is a pointer used in configuration or policy code to retrieve a sensitive value at runtime. It lets teams keep the secret out of the file itself while still making it available to the control that needs it. This pattern improves rotation and reduces accidental exposure.
• Execution boundary: The point at which an authorised task turns into a real system change, such as writing data, deleting records, spending money, or invoking a downstream tool. In AI governance, controlling the execution boundary matters more than simply approving access, because harm occurs when actions are allowed to complete unchecked.
• Runtime Mediation: A control model where access is granted, checked, and potentially revoked at the moment an action is taken. For AI agents, runtime mediation is the practical alternative to one-time consent because decisions, context, and tool use can change during a session.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.