How should organisations govern access when PAM does not fit cloud-native workloads?

Why This Matters for Security Teams

PAM is still valuable, but it was designed for human elevation workflows, not for ephemeral workloads, service-to-service calls, or software that acts on goals. When a cloud-native workload needs access for minutes, or an AI agent can chain tools without a predictable path, ticket-based approval becomes a lagging control rather than a guardrail. Current guidance suggests governing the identity lifecycle and the runtime action, not just the request for access.

This is where teams need to separate standing privilege from task-scoped authority. The problem is not only over-permissioned accounts; it is also that modern systems increasingly use secrets, tokens, and certificates that can outlive the workload that requested them. That is why the The 2026 Infrastructure Identity Survey is relevant here: 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments. The control gap is often visible first in cloud automation, not in the PAM console. In practice, many security teams encounter privilege misuse only after an automated job or agent has already used it to move faster than the review process.

How It Works in Practice

The practical model is to use PAM for human administrators, but to govern workloads with workload identity, policy evaluation at request time, and short-lived credentials. For cloud-native systems, that means cryptographic identity for the workload, a clear trust boundary, and a policy engine that decides whether the action is allowed in the current context. The SPIFFE workload identity specification is useful here because it shifts the question from “who logged in?” to “what workload is this, and should it do this now?”

A workable operating model usually includes:

• JIT credentials issued per task and revoked when the task finishes.
• Ephemeral secrets with tight TTLs instead of reusable static tokens.
• Policy-as-code for intent-based authorization at runtime.
• Separate controls for human elevation, automation identities, and AI agents.
• Continuous logging of the action, the workload identity, and the policy decision.

That approach aligns with the broader NHI lifecycle discussed in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the risk patterns covered in Top 10 NHI Issues. For cloud governance, pair that with the access discipline in NIST Cybersecurity Framework 2.0 and the identity guidance in OWASP Non-Human Identity Top 10. These controls tend to break down when legacy platforms cannot evaluate policy at request time because the application can only understand long-lived account credentials.

Common Variations and Edge Cases

Tighter runtime control often increases operational overhead, requiring organisations to balance stronger least privilege against deployment complexity and developer friction. That tradeoff is real, especially in mixed estates where some workloads are cloud-native and others still depend on static service accounts or human-owned break-glass paths.

Best practice is evolving rather than settled in a few areas. There is no universal standard for how to authorise AI agents yet, but current guidance suggests using intent-based checks, scoped tool permissions, and strong workload identity rather than treating an agent like a normal user. The The 2026 Infrastructure Identity Survey also shows why this matters operationally: organisations that grant AI systems more access than they would give a human employee are taking materially higher risk, so over-permissioning should be treated as a design flaw, not just a policy violation.

Edge cases often include regulated systems, Kubernetes operators, CI/CD runners, and multi-agent workflows. In those environments, PAM can still sit in the background for human break-glass access, but it should not be the default for machine action. The right question is whether access can be bound to workload identity, constrained by policy, and removed automatically when the task ends. When that is not possible, organisations should document the exception, shorten credential lifetime, and revisit the architecture rather than stretching PAM beyond its intended role.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities that have persistent access?
• How should security teams govern non-human identities in cloud environments?
• How should security teams govern API keys used for generative AI access?
• How should teams govern Oracle ERP Cloud access beyond native controls?