Runtime identity for AI agents: why static entitlements fall short

At a glance

What this is: This is a runtime identity analysis for AI agents, with the key finding that static access controls are not enough when agents set their own next steps.

Why it matters: It matters because IAM, PAM, and NHI programmes now have to govern delegated machine actions at execution time, not just provision access once and assume behaviour stays bounded.

👉 Read Ping Identity's analysis of runtime identity for AI agents and delegated access

Context

Runtime identity is the governance problem of deciding who or what an agent can do at the moment it acts, rather than only at the moment credentials are issued. That matters because AI agents can vary their own execution path, which breaks assumptions built around fixed privilege and predictable request patterns.

For IAM and NHI teams, the issue is not whether agents are useful. The issue is whether the identity model can preserve accountability when an agent acts on behalf of a human, crosses channels, and chooses actions dynamically inside a live workflow.

Key questions

Q: How should security teams govern AI agents that act on behalf of users?

A: Security teams should treat each AI agent as a registered identity tied to a specific human delegate, then evaluate access at the moment of action. That means policy must consider the delegate, the session context, and the requested task together. Standing entitlements alone are too coarse when the agent can choose its own next step.

Q: Why do static access controls fail for AI agent governance?

A: Static controls fail because they assume access can be defined once and then reused safely across future actions. AI agents can choose different paths inside the same session, so the risky decision happens after provisioning. Governance has to follow the action path, not just the original grant.

Q: How do I decide which AI agent actions need human approval?

A: Use human approval for actions that change records, permissions, financial state, or customer identity, because those are the points where delegation risk becomes material. Routine information retrieval may stay automated, but the approval boundary must sit inside the live workflow. If the action can create lasting impact, it should not proceed unattended.

Q: What is the difference between runtime identity and normal IAM?

A: Normal IAM often decides access at login or provisioning time, while runtime identity re-evaluates the agent at each action. That matters because AI agents can vary their behaviour mid-session and may not follow the same path twice. Runtime identity is therefore a delegated decision model, not just an authentication model.

Technical breakdown

Runtime identity and delegated access for AI agents

Runtime identity means the agent is authenticated and authorised as a first-class identity each time it acts, using the delegate relationship as part of the decision. In practice, that shifts control from static provisioning to contextual enforcement, where the system checks who the agent represents, what the action is, and whether the current context supports it. This is different from simply giving the agent the same access as the human user. The key technical idea is delegated authority, not shared standing privilege.

Practical implication: bind every agent to a named delegate and enforce action-time authorisation, not broad standing access.

Agentic identity in MCP-enabled applications

In MCP-enabled environments, the agent can reach tools and data sources through a standardised interface, which increases the need for identity decisions at the point of tool use. The security question is no longer only whether the model can call a tool, but whether the tool call is permitted for this delegate, this session, and this action. Without a runtime control plane, the agent may chain benign steps into an unsafe outcome, such as modifying records or surfacing data outside the intended business case.

Practical implication: place policy checks at the tool boundary, not only around the application or user login.

Human-in-the-loop approvals and delegated decision boundaries

Human-in-the-loop is not the same as full control, but it is an important boundary for higher-risk actions. The point is to separate routine agent behaviour from actions that materially change records, permissions, or customer state. If approvals are only used during enrolment or initial setup, they do not govern the risky step itself. Runtime identity works because it aligns the approval boundary with the actual act, which is where accountability and intent can still be verified.

Practical implication: reserve human approval for high-risk actions and make that approval part of the live decision path.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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

NHI Mgmt Group analysis

Static entitlements are the wrong trust model for agents. AI agents do not just consume access, they choose how to use it at runtime, which makes admin-time privilege assignment an incomplete control model. That is why standing credentials and role mapping are insufficient when the actor can alter its own next step. Practitioners should treat this as a boundary problem, not a mere permissions problem.

Runtime identity is the named control pattern this market has been missing. The useful shift is not simply adding more IAM policy, but binding agent action to delegate, context, and decision time in one control plane. That aligns with delegated identity thinking in IAM, but extends it into agent behaviour where the action path is non-deterministic. The practitioner conclusion is that agent governance must be evaluated at execution time, not only at provisioning time.

Access review processes assume access is stable long enough to certify. That assumption fails when the actor is autonomous in the behavioural sense of choosing its own next steps, because the meaningful control point moves inside the session. When the runtime decision can bypass the expected workflow, the governance model built on periodic review no longer describes the real risk surface. Practitioners must rethink whether review cadence can ever see the action it is meant to govern.

Delegation chains need identity logic, not just workflow logic. The article's central insight is that an agent acting on behalf of a human is not a generic automation step, it is a delegated identity relationship that changes what access means. That has implications for customer service bots, employee copilots, and customer personal agents, because each delegate relationship narrows or expands legitimate action differently. The practitioner takeaway is that identity architecture must encode delegation, not just authenticate the actor.

Agent identity governance is now a cross-domain IAM problem. This topic sits at the intersection of human identity, NHI governance, and runtime authorisation, because the agent borrows human intent but executes machine-speed actions. That creates a control gap that cannot be solved by a single control family. The practical conclusion is that IAM, PAM, and NHI teams have to coordinate around the same delegated identity model.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface.
• Only 44% have implemented any policies to govern AI agents, even though 92% agree that governing them is critical to enterprise security.
• For a broader control baseline, read Ultimate Guide to NHIs for lifecycle, visibility, and offboarding guidance.

What this signals

Runtime identity will become a programme design requirement, not a feature request. Once AI agents are allowed to act on behalf of users, the control model has to express delegation, not just authentication. Teams that already map service accounts, workloads, and human roles into one identity view will be better positioned to extend that discipline to agents without creating a separate governance silo.

The practical signal for IAM and PAM teams is that approval logic, delegation mapping, and tool-level enforcement now need to be designed together. If those controls live in different systems, the agent can drift across them faster than review cycles can reconcile the behaviour.

For practitioners

• Register agents as first-class identities Create an identity record for each agent, map it to the human delegate, and require that mapping before any tool or data access is allowed.
• Move authorisation to the moment of action Check delegate, context, and requested action at runtime so the agent can only perform what is valid for that specific interaction.
• Separate routine actions from high-risk actions Define which agent tasks can proceed automatically and which must pause for human approval before the workflow can continue.
• Control MCP tool access at the boundary Apply policy at the application and tool layer so the agent cannot translate a permitted chat interaction into an unauthorised system change.

Key takeaways

• AI agents expose a governance gap where identity is granted once but behaviour changes at runtime.
• The strongest evidence is the shift from static entitlement thinking to delegate-aware authorisation at the moment of action.
• Practitioners should redesign control points around agent registration, delegation mapping, and live approval boundaries.

Key terms

• Runtime Identity: Runtime identity is the practice of making an access decision when the action happens, not only when credentials are issued. For AI agents, that means the system evaluates delegate, context, and task together so the agent can be allowed or blocked based on the live request.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another identity within defined limits. In agent governance, the delegate relationship is the control anchor, because the agent inherits intent from a human but still needs its own identity and policy boundaries.
• Human-in-the-loop Approval: Human-in-the-loop approval is a control step where a person must confirm a high-risk action before it completes. For AI agents, it is most useful when the action changes durable state, such as records, permissions, or customer details, because the approval is part of the live decision path.
• MCP Enabled Application: An MCP enabled application is a system that exposes tools and data to an AI agent through Model Context Protocol. That expands the identity problem beyond chat access, because the agent can now reach operational actions, so policy has to sit at the tool boundary as well as at login.

Deepen your knowledge

Runtime identity for AI agents is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending IAM, PAM, or NHI governance into agentic workflows, it is worth exploring.

This post draws on content published by Ping Identity: runtime identity for AI agents and delegated access controls. Read the original.