TL;DR: AI agents are effectively operating as delegated identities across endpoints, SaaS platforms, and the “mushy middle” of productivity tools, with long-lived OAuth and SAML grants creating persistent access paths that security leaders often do not fully see, according to Reveal Security. The identity model is shifting faster than conventional IAM review cycles, because agents can act as the user while retaining permissions long after the original task ends.
Editorial analysis by NHI Mgmt Group, based on content published by Reveal Security: “What Security Leaders Should Actually Understand About AI Agents”.
Key questions
Q: What breaks when AI agents are given broad standing access?
A: Broad standing access breaks governance because the agent can move from one task to another without a fresh authorization check.
Q: Why do long-lived user tokens create governance risk for AI agents?
A: Long-lived tokens assume access remains valid until a person revokes it, but agent behaviour changes the risk model because the actor can decide and act at runtime.
Q: How can security teams tell whether agent permissions are too broad?
A: The clearest signal is whether the agent can still complete its job after permissions are reduced in a sandbox.
Practitioner guidance
- Define explicit agent ownership Assign a business owner and technical owner to every AI agent that can act on behalf of a user, service, or team.
- Scope delegated access to the task Limit agent permissions to the minimum tool set, data set, and action set required for the specific workflow.
- Track and revoke long-lived tokens Inventory OAuth and SAML grants that outlive the immediate use case, then remove access when the workflow ends or the agent is retired.
Bottom line: AI agents are not just tools in the workflow. They are delegated identities that can carry user authority across systems and continue acting after the immediate task ends.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
AI agents turn delegated access into a standing governance problem: once an agent can act as the user, IAM is no longer only authenticating a person. It is governing an executor that can inherit, retain, and reuse authority across sessions. That shifts the control point from login assurance to delegation scope, which is where many programmes are still weakest. The practitioner conclusion is that agent access must be managed as an active identity state, not a one-time approval.
A few things that frame the scale:
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: Who should be accountable for AI agent approvals and audits?
A: Accountability should sit with the human owner of the agent path, the application owner, and the identity governance process together. The agent cannot be the sole accountable subject because it is not a governance endpoint. Teams should tie approvals, logs, and access reviews to the person or team responsible for the agent’s use.
👉 Read our full editorial: AI agent identity risk is outpacing enterprise IAM controls