Notifications
Clear all
Topic starter
06/06/2026 11:20 am
TL;DR: AI agents behave like users but decide their own next steps, which means static entitlements, standing credentials, and admin-time approvals leave gaps in control, according to Ping Identity. Runtime identity shifts governance to execution time, tying each agent action to a real delegate, context, and fine-grained rule.
NHIMG editorial — based on content published by Ping Identity: runtime identity for AI agents and delegated access controls
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full article
Ping Identity's full article covers the operational detail this post intentionally leaves for the source:
- How Agent Core registers agents and expresses delegate relationships in practice
- How Agent Gateway translates identity controls into MCP-enabled applications
- Examples of runtime decision enforcement for customer bots, employee copilots, and personal agents
- The source article's explanation of how human-in-the-loop approval fits into delegated agent safety
👉 Read Ping Identity's analysis of runtime identity for AI agents and delegated access →
AI agent runtime identity: are your controls keeping up?
Explore further
06/06/2026 12:04 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Runtime identity for AI agents: why static entitlements fall short
