Runtime identity for AI agents: why static entitlements fall short

At a glance

What this is: This is Ping Identity's analysis of runtime identity for AI agents, arguing that static entitlements cannot govern non-deterministic agent behaviour at the moment of action.

Why it matters: It matters because IAM, PAM, and NHI programmes now need to govern delegated AI actions in context, not just assign privileges at setup.

Context

AI agents change the access problem because they do not behave like fixed workflows with predictable next steps. When an identity can decide how to proceed at runtime, static approval and entitlement models stop being enough on their own.

This article frames runtime identity as an identity governance problem, not just an AI feature. The core issue is how to bind an agent to a human delegate, constrain what it may do on that person's behalf, and evaluate each action as it happens.

That makes the topic relevant to both NHI governance and broader IAM design. The same programme that controls standing machine credentials now has to decide how delegated agent authority is registered, constrained, and reviewed.

Key questions

Q: How should security teams govern AI agents that browse and transact on behalf of users?

A: Security teams should govern AI agents as delegated actors with narrow, task-scoped permissions, not as enhanced browsers. The right model is to bind access to the specific action being performed, preserve auditability at the transaction layer, and separate machine identity from the human principal wherever possible.

Q: Why do static entitlements create risk for AI agents?

A: Static entitlements create risk because they are granted before the agent decides how to complete the task. An AI agent can choose a different path, call different tools, or pursue an easier shortcut after the access decision has already been made. Runtime authorization closes that timing gap.

Q: What breaks when an agent is treated like a normal service account?

A: What breaks is the assumption that the account only performs one bounded function. A modern agent may browse, retrieve data, interact with multiple applications, and carry state across steps, so a normal service-account model can miss the broader path of privilege and the need for tighter lifecycle control.

Q: Should organisations use the same access model for customer bots and employee copilots?

A: No. They can share an identity-aware architecture, but the access rules should reflect who they serve, what data they may reach, and which actions need escalation. Customer bots, employee copilots, and personal agents represent different risk profiles even when they use the same systems.

Technical breakdown

Why static entitlements fail for AI agents

Static entitlements assume the access decision made at provisioning time remains valid when the action occurs. AI agents are different because they can set their own next steps, choose among possible paths, and optimise for task completion in ways humans did not pre-authorise line by line. That makes admin-time access checks too early to capture intent drift, context changes, or unsafe shortcuts. In identity terms, the problem is not just privilege size. It is that the privilege boundary is being evaluated before the real decision exists.

Practical implication: move evaluation from issuance time to execution time for agent actions that can branch or self-direct.

Delegated identity needs human context, not just a token

Runtime identity treats an agent as a first-class identity bound to the human it represents. That delegated relationship matters because an agent may be allowed to act for one user but not another, and some actions should still require human-in-the-loop approval. This is closer to an identity relationship model than a simple service account model. The control objective is to preserve who the agent acts on behalf of, what it can do in that role, and when escalation back to a human is required for riskier steps.

Practical implication: register agents with explicit delegate mappings and approval boundaries before allowing them to touch business systems.

MCP-enabled apps need runtime authorization at the action layer

The article links runtime identity to MCP enabled applications because AI agents often reach tools through a protocol layer that can expand their effective access. If the app only checks a broad session or account entitlement, the agent can overreach once it starts chaining tool calls. Runtime decisions need to be fine-grained enough to validate each action against the current delegate, purpose, and context. That turns authorization from a session property into an action property, which is the right fit for agentic behaviour.

Practical implication: enforce per-action authorization on tool calls, not just broad login or session permissions.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Meta Muse agent hijack 2026: An undocumented Muse setting let local malware hijack Meta's personal AI agent, steal its authentication material and abuse user access.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static entitlement models collapse when the actor can decide its own next step. The article describes non-deterministic AI agents that can alter their approach mid-task, which means access that looked acceptable at setup can become unsafe during execution. The broken premise is that least privilege can be fixed at provisioning time for a task whose path is not fixed. Practitioners should treat runtime decision authority as the governance boundary, not the original grant.

Delegation, not merely authentication, is the real control plane for AI agents. An agent acting "on behalf of" a person is not just another workload. The identity question is which human, which scope, and which actions are permitted under that relationship. That is why first-class registration and delegate mapping matter more than a generic agent account. Practitioner implication: identity programmes need relationship-aware governance, not just identity presence.

Runtime identity is the named concept that best captures this control shift. It is the practice of evaluating agent authority when the action occurs, with context and delegate binding included in the decision. That shifts governance away from standing privilege and toward task-scoped authorization. For IAM and NHI teams, the message is that AI agents are not governed safely by the same lifecycle assumptions used for static machine accounts.

Agent safety will increasingly depend on whether organisations can separate helpfulness from authority. The article shows why customer bots, employee copilots, and personal agents all need different limits even when they use the same systems. A single identity-aware architecture only works if it can distinguish channel, delegate, and risk level at runtime. Practitioner implication: standardise the control model, not the agent behaviour.

Agentic access is becoming a governance problem across human, NHI, and AI control planes. The same enterprise that already manages users and machine identities now has to decide how delegated AI authority fits into existing IAM, PAM, and lifecycle processes. That broadens the identity surface without changing the underlying governance discipline. Practitioner implication: align AI agent controls to the same access governance programme that already covers privileged and non-human access.

From our research library:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Authorisation Guide

What this signals

Governance teams should expect AI agents to force a shift from provisioning-time access decisions to execution-time authorization. The practical question is no longer whether an identity exists, but whether each action can be constrained by the delegate relationship and current context.

Runtime identity: this is the control pattern that binds an agent to a human delegate and evaluates authority at the moment of action. That matters because access reviews and standing entitlements were built for stable identities, not for actors that can re-plan mid-task.

Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey. That gap suggests policy design is still lagging behind deployment reality.

For practitioners

• Define agent identities as first-class records Register each AI agent with a unique identity, named purpose, and explicit delegate relationship so the control plane knows who it acts for and what it may do.
• Move authorization to the moment of action Evaluate each agent action against current context, delegate, and requested operation instead of relying only on standing entitlements issued at setup.
• Set human approval gates for high-risk actions Require human-in-the-loop approval where the agent is about to perform irreversible or sensitive operations that exceed routine delegated scope.
• Separate customer, employee, and personal agent policy Apply different access rules for customer-facing bots, employee copilots, and customer personal agents even when they use the same backend systems.

Key takeaways

• AI agents are governed differently from static workloads because they can make independent runtime decisions that outgrow the original access grant.
• Delegated authority is the central design issue, since the same agent may be acceptable for one person or task and unacceptable for another.
• Runtime authorization is the control shift that matters, because it evaluates agent actions at the moment they occur rather than at provisioning time.

Key terms

• Runtime Identity: Runtime identity is the practice of making identity and authorization decisions at the moment an action occurs. For agents and workloads, it means access is validated against live context, not only against the identity state set during onboarding or provisioning. That makes accountability and scope enforcement possible inside fast-moving workflows.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Standing Entitlement: A standing entitlement is any persistent right that remains attached to an identity between uses. In NHI environments, standing entitlements create hidden blast radius because the identity can act later without a fresh access decision, even when the original need has passed.
• Human-in-the-Loop Approval: A review step where a person explicitly approves a high-risk access request before it is granted. It is most useful for exceptional privilege expansion, not for routine automation, because the goal is to catch unusual requests without turning every machine action into a manual process.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.