TL;DR: Microsoft Entra, Google Cloud IAM, Okta and Ping each ship different pieces of AI agent support, while Auth0 and Keycloak mainly provide delegation primitives, leaving the hardest governance question inside the application, not the IdP, according to Agentic Fabriq. The real gap is not agent registration but delegated authority over a named person’s data and actions.
At a glance
What this is: This is a vendor-by-vendor analysis of how current identity providers support AI agents, and the key finding is that most products cover only part of the control problem.
Why it matters: It matters because IAM teams need to know whether they are governing a true agent principal, a delegated workflow, or just an application token flow before they decide where accountability and policy enforcement belong.
Context
The core governance problem is not whether an identity provider can issue a token to an AI agent, but whether the programme can express who the agent is, who sponsors it, and what it may do on behalf of a human. Most current products cover the machine-principal side and leave the named-person authority check to the application layer.
That split matters because an AI agent acting for a person is neither a normal user nor a standard workload. In practice, the hard part is delegated authority: the application still has to intersect the user’s rights with the agent’s rights before any sensitive action is allowed.
Key questions
Q: What should security teams do first when they introduce AI agent identities?
A: Start by deciding whether the agent is a first-class principal or a delegated workflow, then assign a human sponsor and document the enforcement point for its permissions. If the team cannot name the owner and the decision engine, the control model is incomplete and auditability will fail when the agent touches sensitive data.
Q: Why do AI agent identities still need application-side authorization checks?
A: Because an identity provider can prove who the agent is and issue a token, but it cannot know whether a specific business action is valid for a specific record. The application must intersect the user’s rights, the agent’s rights and the resource scope before it allows the action, otherwise delegated access becomes overbroad.
Q: Where do identity providers stop in AI agent governance?
A: They stop at identity issuance, lifecycle hooks and, in some cases, delegation primitives. The final authorization decision still belongs to the application or gateway because only that layer understands the record, the business process and the current user context. That boundary should be written down and tested.
Q: What is the difference between an AI agent and a normal service account?
A: A normal service account authenticates and executes fixed instructions. An AI agent adds reasoning and can choose actions based on model output, which makes its effective behaviour dynamic. That difference matters because the risk is not only access, but decision-making combined with access. Governance must account for both authority and autonomy.
Technical breakdown
What makes an AI agent identity different from a service account?
A service account assumes a stable workload with a durable operating pattern, while an AI agent identity has to cope with task-scoped existence, changing context and human sponsorship. That difference changes the governance model: the identity is not just an authentication handle, it is part of a delegation chain that can begin with a person and end with a machine action. Vendor documentation in this article shows that some products now model agents as first-class principals, but only some of them bind that principal to lifecycle, review and disablement controls. Practical implication: treat agent identity as a governed principal, not as a renamed service account. See the Agentic AI Identity Guide.
Practical implication: Use a distinct lifecycle and sponsorship model for agent principals rather than reusing workload-account assumptions.
Why does delegated authority remain the hardest part of agent identity?
Delegated authority is the point where identity stops being about authentication and becomes about action approval. The article shows that several products can identify the agent, issue a short-lived credential, and even record a sponsor, but the policy question still lands in the consuming application: may this agent, carrying this person’s authority, perform this specific operation on this specific record? That requires intersection logic between user rights and agent rights, plus awareness of data scope and task scope. Practical implication: design for application-enforced authorization decisions, not IdP-only trust decisions. See the AI Agent Authorisation Guide.
Practical implication: Place the user-scope and agent-scope intersection check in the application or gateway, not in the directory alone.
How do short-lived tokens change AI agent security architecture?
Short-lived tokens reduce secret persistence, but they do not solve delegated-authority ambiguity. The article’s vendor comparisons show a common pattern: the IdP issues a credential or assertion, then the runtime or application decides what that credential may do. That separation is useful, but it also means security teams can mistake identity issuance for access control. In an agent workflow, a valid token can still be too broad if the action model is not bound to the exact task, user context and target resource. Practical implication: govern the token path and the authorization path as separate controls. See the AI Agent Observability, Audit and Incident Response Guide.
Practical implication: Map where credentials are issued and where the final action decision happens, then control both layers independently.
Threat narrative
Attacker objective: To use a legitimate agent identity or delegated token to perform actions that the human sponsor did not explicitly intend.
- Entry occurs when the agent receives a valid identity or delegated token from the IdP, often through a standard sign-in or exchange flow.
- Escalation happens when the application treats that token as sufficient authority without intersecting the user’s scope, the agent’s scope and the target record’s scope.
- Impact follows when the agent can act on sensitive records or third-party APIs in a way that exceeds the intended human delegation boundary.
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.
- Kubeflow cryptomining attacks 2020: Exposed Kubeflow dashboards and a notebook's mounted Kubernetes service account let attackers run cryptominers on tens of ML clusters.
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
Agent identity is now a product category, but delegated authority is still a design problem: The article shows that several identity providers can mint a distinct agent principal, yet that does not resolve who can authorise what the agent does. The market is converging on identity issuance, not on policy correctness. Practitioners should read this as a signal that the control boundary has shifted into the application and gateway layers.
The most important gap is not agent registration, it is named-person accountability: Most of the shipped capabilities govern the agent as a machine principal, while the enterprise risk comes from an agent acting for a specific employee or adjuster. That means the identity model must preserve sponsor, ownership and offboarding semantics across the delegation chain. Agent identity governance matters, but only if the human-to-agent relationship stays explicit.
Delegated authority is the named concept that separates identity from authorisation: A token proves that the agent exists and was issued credentials, not that the requested business action is safe. The article makes clear that the final decision remains in the consuming application, which means teams need to stop treating IdP support as the finish line. The practical consequence is to define where the intersection check lives and who owns it.
Short-lived credentials reduce persistence, but they do not remove policy drift: The vendor landscape is improving the lifecycle of agent credentials faster than it is improving action-level governance. That creates a false sense of completeness if teams stop at registration and token issuance. Security leaders should expect the next wave of incidents to come from over-trusted delegation paths rather than from static secret storage alone.
Identity providers are becoming enablers of agent governance, not arbiters of agent permission: Entra, Okta, Google and Ping all move the industry toward first-class agent representation, but none of them replaces the need for business-specific authorisation logic. That is the right division of labour, not a deficiency in the product set. Organisations should design for that split instead of waiting for the IdP to solve it end to end.
Read next: AI Agent Authorisation Guide
What this signals
Delegated authority will become the control plane for agent programmes: As more identity providers add first-class agent objects, the differentiator will shift from whether an agent can log in to whether the enterprise can prove which action it was allowed to perform. That pushes governance teams toward policy at the application boundary, not just at enrolment time.
The next maturity step is operational, not conceptual: teams will need to map sponsor ownership, task scope and offboarding into the same workflow. When agents can be created and retired quickly, control failures will surface as missing enforcement points rather than missing identities.
For practitioners
- Define the agent principal model Document whether each AI agent is a distinct principal, a service account surrogate or a delegated workflow, and assign an accountable human sponsor for each one.
- Implement application-layer scope intersection Require the consuming application to evaluate user scope, agent scope and record scope before any sensitive action is approved.
- Separate token issuance from authorization Map where the identity provider issues credentials and where the final business decision is enforced, then verify both controls during design reviews.
- Review offboarding for delegated agents Ensure agent disablement, sponsor transfer and token revocation are covered in the same offboarding flow used for human access and automation accounts.
Key takeaways
- The article shows that current identity providers are converging on agent principals, but the hardest governance problem remains delegated authority over a named person’s data and actions.
- Short-lived credentials help, yet they do not replace application-side policy checks that intersect user scope, agent scope and record scope.
- IAM teams should treat agent identity as a shared control boundary across identity, application and lifecycle governance, not as a directory feature alone.
Related NHI Mgmt Group resources: Agentic AI Identity Guide · AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide · AI Agents vs Agentic AI
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on how agent identities and delegated privileges are represented and constrained. |
| ASI09 — Human-Agent Trust Exploitation | The article repeatedly focuses on agents acting on behalf of named people and the trust boundary that creates. | |
| Recommendation — Map agent principal designs to ASI03 and enforce task-scoped privilege boundaries before execution. Apply ASI09 controls to separate human authority from agent authority in delegated workflows. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article’s central risk is overbroad authority when an agent token is treated as sufficient access. |
| NHI-01 — Improper Offboarding | The article highlights sponsor transfer, disablement and lifecycle gaps for agent identities. | |
| Recommendation — Audit agent principals for overprivileged scopes and reduce grants to the minimum task-bound access. Tie agent disablement and sponsor transfer to formal offboarding controls so access does not outlive ownership. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article discusses short-lived credentials, token issuance and credential governance for agents. |
| AC-6 — Least Privilege | The article’s core issue is preventing agents from carrying more authority than each task requires. | |
| Recommendation — Use IA-5 to govern agent credential issuance, expiry and revocation across the lifecycle. Apply AC-6 to cap each agent’s effective permissions at the minimum required for the specific action. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The post is about how access is authorised for agents and who owns that decision. |
| Recommendation — Define and enforce agent authorisation boundaries under PR.AA-05 before allowing business actions. | ||
| NIST Zero Trust (SP 800-207) | 4.4 — Policy Enforcement Point | The article makes clear that the final decision should sit where the application or gateway can evaluate context. |
| Recommendation — Place the agent decision check at the enforcement point closest to the resource and context. | ||
Key terms
- Agent Principal: An agent principal is a distinct identity issued to an AI agent so it can authenticate and be audited separately from the human it serves. In practice, it should have its own lifecycle, scoped credentials, and revocation path, because borrowing a human session collapses accountability and widens blast radius.
- Delegated Authority Model: A delegated authority model defines who is allowed to approve, review, or execute control-related decisions across the enterprise. It helps ensure requests reach the correct responsible party, especially when control owners, managers, and process owners sit in different teams, regions, or systems.
- Application-Side Authorization: The permission decision made inside the application itself after authentication has occurred. It can differ from IAM policy if the app uses custom role logic, local accounts, or inconsistent permission checks, which is why the enforcement point matters as much as the identity record.
- Ownership and sponsorship: The accountable human or process link behind an identity relationship. Ownership identifies who is responsible for the identity’s access, while sponsorship explains why the relationship exists and who should approve changes, reviews, and termination decisions.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org