AI agent identity and PAM controls need a new operating model

At a glance

What this is: This article argues that AI agents are becoming execution identities, and that existing PAM models must adapt to short-lived, non-deterministic access patterns.

Why it matters: It matters because IAM, PAM, and governance teams now have to control not just whether an identity can connect, but how an AI agent decides to use credentials, tools, and delegated privilege.

👉 Read SSH Communications Security's analysis of AI agent access and PAM controls

Context

AI agent identity is now a PAM problem, not just an AI problem. The article’s core point is that agents are no longer limited to generating output, they are executing actions through the same protocols and systems that existing identity programmes already govern. That changes the control question from static access issuance to runtime decision control.

The gap is not that HTTP, SSH, or file systems are new. The gap is that a non-human identity can now choose how to use access in a non-deterministic way, across short-lived runtimes and delegated contexts. That is why traditional identity assumptions built around human operators and stable service accounts start to break down.

Key questions

Q: How should security teams govern AI agents that need privileged access?

A: Treat AI agents as non-human identities with their own lifecycle, access scope, and audit trail. Brokering access through PAM, limiting permissions to the specific endpoint or command, and recording every session are the controls that keep agent privilege bounded. The main objective is to prevent reusable credentials from becoming standing access for unpredictable runtime behaviour.

Q: Why do AI agents complicate traditional PAM models?

A: Traditional PAM assumes access is relatively stable and can be mediated around known operators or fixed service identities. AI agents break that assumption because they are short-lived, non-deterministic, and able to choose actions across multiple tools in a single task. That makes static roles and reusable secrets a poor fit for controlling their behaviour.

Q: What breaks when agents are given a human user's permissions?

A: Privilege cloning inflates access because human workflows and machine workflows are not the same. An agent can chain actions faster than a person, use more tools, and cross system boundaries without the same judgement or pause points. Scoped delegation with explicit time, scope, and approval limits is the safer model.

Q: How can organisations tell whether AI agent governance is actually working?

A: Look for evidence that agent access is ephemeral, traceable, and constrained at the action level. If the organisation cannot show which runtime acted, what it touched, and which endpoint or command it used, then governance is still too coarse. Effective control produces auditable decisions, not just authentication events.

Technical breakdown

AI agent runtimes and trust boundaries

An AI agent runtime is the execution environment where the agent lives, such as an endpoint, Kubernetes cluster, serverless function, or SaaS service. The runtime defines the trust boundary because it determines what the agent can reach, what identity evidence it can present, and what controls can be enforced around local execution and outbound access. In practice, this means the same agent behaviour can carry very different risk depending on where it runs and what nearby systems it can touch. The security model therefore has to treat the runtime as part of identity governance, not just infrastructure.

Practical implication: Map agent runtimes to explicit trust boundaries before granting access to any production system.

PAM-mediated access versus vaulted credentials for AI agents

The article describes two access patterns: PAM-mediated access, where the agent authenticates to PAM and access is brokered, and vaulted credentials, where the agent receives secrets directly and those secrets are rotated. The first pattern reduces direct secret exposure because the agent never holds standing credentials for target systems. The second can work, but it still leaves the burden of safe issuance, scoping, and revocation. For AI agents, the architectural difference is not cosmetic: brokered access centralises control, while embedded secrets widen the abuse surface.

Practical implication: Prefer brokering access through PAM instead of distributing reusable credentials to the agent.

Fine-grained authorization for API endpoints and SSH commands

The article makes clear that role-based control alone is too coarse for AI agents that can interact with many tools in the same session. Fine-grained authorization is needed at the level of API endpoint, HTTP method, SSH command, and contextual conditions. That is where policies can finally express what the agent may do, not just what system it may touch. This matters because agent behaviour is non-deterministic, so the same identity may need different permissions across different tasks or phases. Broad roles leave too much room for unintended action.

Practical implication: Define permissions at the endpoint, method, and command level instead of granting broad task-based roles.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent identity is now an execution problem, not a model problem. The article’s strongest signal is that agents are no longer merely producing recommendations, they are acting across HTTP, SSH, file systems, and databases. That moves the control discussion from AI output governance into identity and privilege governance. In NHI terms, the identity is no longer passive infrastructure; it is an execution layer that can initiate tool use. Practitioners should treat this as a governance boundary shift, not a product feature shift.

Ephemeral identity for AI agents is becoming the decisive control gap. Static API keys and reused service identities do not fit agents that spin up, act, and disappear. That creates a lifecycle mismatch between how the identity exists and how the control stack expects to review it. SPIFFE and SPIRE are relevant because they point toward short-lived, verifiable workload identity, but the field is still missing a common operating pattern for agent lifecycles. Teams should assume the identity model is under-specified until proven otherwise.

Delegated user privilege cloning is the wrong abstraction for agentic access. The article correctly warns against simply copying a user’s permissions onto an agent. That creates privilege inflation because human access patterns are not the same as machine action patterns, especially when the agent can chain tools without pause. A safer mental model is scoped delegation with explicit limits on time, scope, and approval path. Practitioners should re-evaluate every workflow that assumes a human-shaped access model can be reused for non-human execution.

Named concept: execution identity drift. AI agents can shift from one model, runtime, or tool path to another without changing the underlying business objective, which means the practical identity being exercised may drift while the programme still sees a single actor. That makes authorisation and audit harder because the access context is no longer stable across the session. The implication is that governance has to track runtime context, not just issued credentials, if it wants to preserve accountability.

PAM is being asked to absorb a new class of non-human privilege without losing control boundaries. The article shows why PAM remains relevant, but also why its legacy assumptions need adjustment. Session recording, short-lived certificates, brokered access, and granular policy now sit closer to the centre of AI agent governance. Practitioners should read this as a category expansion for PAM, not a narrow use case.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Another finding from the same research shows that 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a wider view of how agent risk is changing, see OWASP NHI Top 10 for the current agentic application risk model.

What this signals

Execution identity drift: the operational problem is no longer simply whether an agent has access, but whether the same agent can shift tool paths, runtimes, and model backends faster than governance can observe. With 44% of organisations reporting any policy for AI agents in our research, the control environment is still forming around the actor instead of around the action.

The next programme-level question is whether IAM, PAM, and security monitoring share one authoritative view of the agent lifecycle. If session records, access grants, and runtime evidence live in different tools, AI agent governance will stay fragmented even when the policy language looks mature.

Teams should expect agent access reviews to become less about recertifying a static entitlement and more about validating that the runtime, tool scope, and delegated purpose still match the approved task. That is where the governance model either proves it can handle non-human execution or exposes its blind spots.

For practitioners

• Classify AI agents as non-human identities with lifecycle controls Create an explicit inventory of agent runtimes, associated systems, and access pathways so AI agents are governed as non-human identities rather than ad hoc automations.
• Broker access through PAM instead of exposing reusable secrets Use PAM-mediated access for target systems and reserve vaulted credentials for only the cases where direct issuance is unavoidable; keep issuance short-lived and task-scoped.
• Apply endpoint-level authorization to agent actions Define policies at the API endpoint, HTTP method, SSH command, and context level so the agent cannot exceed its task simply because it has a valid session.
• Record every agent session into SIEM with usable structure Capture commands, file transfers, and API calls in a form that supports response workflows, not just archival logging, and make those records traceable to the agent runtime.

Key takeaways

• AI agents create a governance problem because they can decide how to use access at runtime, not just inherit access from a script.
• The research cited in the article shows that 80% of organisations have already seen agents act beyond intended scope, which makes the control gap operational rather than theoretical.
• The most effective response is to treat agents as short-lived non-human identities and bind their access to brokered, auditable, task-scoped controls.

Key terms

• AI Agent Runtime: The execution environment where an AI agent runs and takes actions. It is the practical trust boundary because it determines what the agent can reach, which identity evidence it can present, and which controls can be enforced around access and execution.
• Delegated Identity: An access model where an agent acts on behalf of a user under constrained permissions. In governance terms, it is not a copy of the user’s full rights but a scoped privilege relationship that should be limited by time, purpose, and approval path.
• Ephemeral Identity: A short-lived identity issued for a specific task and retired once that task is complete. For AI agents, ephemeral identity helps reduce standing exposure, but only if issuance, scope, and revocation are tightly controlled and auditable.
• PAM-Mediated Access: A control pattern in which privileged access is brokered through a privileged access management layer instead of handing credentials directly to the actor. For AI agents, this keeps secrets out of the runtime and makes the access path easier to observe and govern.

Deepen your knowledge

AI agent identity and PAM controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for short-lived execution identities, this is a practical place to start.

This post draws on content published by SSH Communications Security: AI agents, PAM, and privileged access controls. Read the original.