Vault-centric PAM assumes an identity persists long enough for credential issuance, storage, and reuse to make sense. Agentic identities may exist only for a short task window and choose tools at runtime, so the reusable secret becomes the control failure rather than the control point. The access decision has to move into execution time, not sit in a vault.
Why This Matters for Security Teams
Vault-centric PAM was designed for human administrators and stable service accounts, not for agents that decide at runtime which tool to invoke, which dataset to inspect, or which workflow to chain next. That mismatch turns the vault into a bottleneck while leaving the real control gap at execution time. Current guidance from OWASP Agentic AI Top 10 and NHIMG research such as AI Agents: The New Attack Surface report points to the same problem: autonomous behavior expands blast radius faster than static access design can constrain it.
For teams, the operational risk is not only secret exposure. It is that a reusable credential effectively becomes a standing permission grant for an entity whose actions are not fully predictable in advance. Once an agent can discover new paths through tool chaining, hidden prompt paths, or indirect API calls, the vault no longer governs the moment of use. In practice, many security teams encounter the breach only after the agent has already read, transformed, or exfiltrated data that no human ever intended it to reach.
How It Works in Practice
Agentic systems need identity and authorisation that travel with the workload, not with a stored secret. That means the primary question shifts from “what password can this agent retrieve?” to “what is this workload, what is it trying to do, and should it be allowed right now?” Emerging practice combines workload identity, ephemeral credentials, and policy evaluated at execution time. Standards-oriented approaches such as NIST AI Risk Management Framework and CSA MAESTRO agentic AI threat modeling framework support this direction, while NHIMG coverage of OWASP Agentic Applications Top 10 shows why runtime controls matter more than vault storage.
- Issue short-lived, task-scoped secrets instead of durable credentials, and revoke them when the task ends.
- Bind the agent to workload identity, not just a shared token, so the system can verify what the agent is and what environment it is running in.
- Evaluate policy at request time using context such as action type, data sensitivity, destination system, and recent behaviour.
- Separate secret retrieval from secret use so the vault is never the only enforcement point.
In practical architectures, this usually means federated identity, OIDC-backed workload assertion, or SPIFFE-style identity for the agent runtime, with policy-as-code deciding whether the call is permitted. The key operational shift is that the credential should be narrow, short-lived, and non-reusable, because the agent may choose a different path on every execution. These controls tend to break down when legacy applications require long-lived shared secrets or when the agent is allowed to chain tools across disconnected environments without a common policy engine.
Common Variations and Edge Cases
Tighter runtime control often increases orchestration overhead, requiring organisations to balance reduced secret exposure against slower integration and more policy maintenance. That tradeoff is real, especially where teams still depend on legacy APIs, batch jobs, or vendor systems that only support static keys. There is no universal standard for this yet, so best practice is evolving around layered controls rather than a single replacement for PAM.
Some environments can keep a vault in the design, but only as a secret source of last resort, not as the trust anchor. That distinction matters for agents that operate across multiple tools, because the highest risk is not storage alone but uncontrolled reuse after retrieval. For that reason, the strongest patterns pair ephemeral secret issuance with real-time authorisation and continuous monitoring, a direction reinforced by NHIMG reporting on CoPhish OAuth Token Theft via Copilot Studio and the broader threat landscape described in LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
Where the model breaks down fastest is in multi-agent pipelines that share a workspace, because one agent’s granted token can become another agent’s unintended privilege path if identities are not isolated per task and per step.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A03 | Addresses runtime misuse and over-privileged agent actions that vault-centric PAM misses. |
| CSA MAESTRO | GOV-2 | Covers agent governance, identity, and policy enforcement for autonomous workloads. |
| NIST AI RMF | GV.1 | Governance is needed when agent behaviour and access decisions are dynamic. |
| NIST CSF 2.0 | PR.AC-1 | Identity and access control must be tied to workload context, not stored secrets. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Static credentials and poor rotation are central failure modes in this question. |
Replace static secret reuse with task-scoped runtime checks and least-privilege agent actions.