What breaks when organisations rely on traditional PAM models for AI-driven environments?

Why This Matters for Security Teams

Traditional PAM was built to protect a human administrator who requests access, uses it briefly, and then logs off. AI-driven environments break that assumption because agents can invoke tools repeatedly, chain actions, and change intent mid-task. When enforcement is still centered on approval workflows and session elevation, the control plane lags behind the workload. That creates gaps in least privilege, revocation, and auditability, especially where secrets and API keys are the real mechanism of access. NHIMG’s research on the State of Secrets in AppSec shows how fragmented secrets handling already weakens central control, and the same weakness becomes more dangerous when the “user” is an autonomous system. Current guidance aligns better with runtime governance and workload identity than with one-time privileged sessions, as reflected in the NIST Cybersecurity Framework 2.0. In practice, many security teams discover the mismatch only after an agent has already overreached across multiple tools rather than through intentional access design.

How It Works in Practice

The practical failure is not that PAM is useless, but that it is too static for autonomous execution. Traditional PAM assumes a stable identity, a bounded session, and a predictable request path. Agentic systems often need per-task access, short-lived credentials, and real-time policy checks based on context such as data sensitivity, tool risk, and current task state. That pushes teams toward workload identity, not just credential vaulting. For many implementations, the right starting point is cryptographic identity for the workload through SPIFFE or OIDC-backed assertions, then policy-as-code enforcement at request time using a runtime decision engine. The important shift is from “who approved this session?” to “what is this agent trying to do right now, and does the current context allow it?”

Operationally, this often means combining JIT credential issuance, short TTL tokens, and automatic revocation on task completion. It also means separating human approval from machine authorization. A human may define boundaries, but the policy engine should decide whether the agent can call a database, trigger a payment flow, or export a file at that moment. NHIMG’s BeyondTrust API key breach coverage illustrates why protecting privileged credentials alone is not enough when one compromised secret can unlock broad downstream access. The same runtime logic is supported by SPIFFE and by the access-control model described in NIST SP 800-207. These controls tend to break down when agents share long-lived secrets across multiple tools because revocation cannot keep pace with autonomous tool chaining.

• Issue credentials per task, not per environment, when the agent’s work scope is narrow and time-bounded.
• Use workload identity to bind every action to the agent instance, model, and execution context.
• Evaluate authorisation at request time, not only at login or approval time.
• Revoke tokens automatically when the task ends, the context changes, or the policy engine flags drift.

Common Variations and Edge Cases

Tighter runtime control often increases operational overhead, requiring organisations to balance agility against stronger containment. That tradeoff is real in multi-agent pipelines, legacy applications, and vendor platforms that cannot evaluate fine-grained policy on every call. In those cases, best practice is evolving rather than settled: some teams proxy agent actions through a broker, while others accept limited standing privilege for low-risk read-only operations. The key is to avoid treating all agent access as equivalent.

There is also a difference between human-assisted copilots and fully autonomous agents. Copilots may still fit a more traditional PAM wrapper if access is manually triggered and narrowly scoped. Fully autonomous systems do not. Where an agent can discover new tools, pass outputs to another agent, or attempt lateral movement, static PAM controls become brittle. NHIMG’s DeepSeek breach analysis is a reminder that exposed secrets and uncontrolled data paths can turn a single failure into broad exposure. For risk teams, the practical rule is simple: if the access pattern is dynamic, the control must be dynamic too.

Related resources from NHI Mgmt Group

• Why do legacy IAM and PAM controls become harder to manage as organisations adopt more AI-driven applications and agents?
• How should organisations build identity security skills for AI-driven environments without creating a long hiring lag?
• What breaks when organisations rely on traditional file access logs for AI-assisted work?
• What breaks when organisations rely on patching as the main defence against AI-driven attacks?