Topic starter
22/07/2026 4:38 pm
TL;DR: Legacy IAM assumes the thing logging in is a person, but AI agents make hundreds of API calls per minute, spawn sub-agents, and change scope mid-task, according to Pomerium. That breaks human-paced review, static role mapping, and owner-based accountability, making identity-first enforcement and continuous verification the practical baseline.
Editorial analysis by NHI Mgmt Group, based on content published by Pomerium: “Your IAM Was Built for People. Your Biggest Identity Problem Isn't People Anymore.”.
Key questions
Q: How should organisations govern AI systems that can change scope at runtime?
A: They should treat runtime behaviour as part of the compliance boundary.
Q: Why do AI agents complicate traditional access reviews?
A: AI agents complicate access reviews because they can accumulate permissions across tools and environments faster than manual certification cycles can observe.
Q: What are the signs that agent identities are poorly governed?
A: Common signs include shared service accounts, long-lived OAuth grants, unclear ownership, and logs that cannot distinguish agent actions from human actions.
Practitioner guidance
- Define each agent as a first-class principal Assign unique identities to AI agents instead of sharing service accounts or inherited human credentials.
- Shift enforcement to the request layer Place policy checks outside the agent and evaluate every action at the point of access.
- Issue short-lived credentials only Remove static API keys and long-lived OAuth grants from execution environments.
Bottom line: The article shows that people-first IAM assumptions fail when the authenticated subject can act like an agent rather than a user. That changes identity from a static record problem into a runtime authorisation problem.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
22/07/2026 4:42 pm
People-first IAM is now an assumption mismatch, not just a scale problem. The article shows that the core IAM design centre still expects a person, even when the principal is an AI agent that can request, chain, and change access mid-task. That is a structural mismatch between governance model and runtime behaviour. The implication is that identity architecture must be judged against actor behaviour, not legacy user assumptions.
A question worth separating out:
Q: What should security teams do after an AI agent token is exposed or redirected?
A: Immediately assume the agent's standing authority is compromised and review every service the token could reach. Revoke the session, rotate the affected credentials, inspect tool-call history for abnormal actions, and validate whether any helper service redirected traffic or stored copied credentials. Containment has to start before the agent completes another tool call.
👉 Read our full editorial: Why agentic AI breaks people-first IAM assumptions