AI agents need identities, credentials, and authentication ceremonies of their own — separate from the humans they act on behalf of, separate from the service accounts they're often confused with. The 2026 enterprise reference on the architectures that issue agent identity, the protocols that authenticate them, the delegation chain that keeps user authority intact, and where agentic auth deployments break.
AI agents need identities, credentials, and authentication ceremonies of their own — separate from the humans they act on behalf of, separate from the service accounts they're often confused with. The 2026 enterprise reference on the architectures that issue agent identity, the protocols that authenticate them, the delegation chain that keeps user authority intact, and where agentic auth deployments break.
Enterprise authentication architecture spent the last decade settling the workforce-MFA question — phishing-resistant credentials, adaptive policy, federation hygiene, recovery hardening. The pattern is durable. Then AI agents arrived and brought a class of identity the existing architecture wasn't built for.
The agent is not a human. The user signs in, the agent does work on the user's behalf. The agent is also not a service account in the traditional sense. A service account has standing identity and standing scope — the workload exists for a defined purpose. An agent has variable scope per task — the same agent may act on behalf of different users at different times, with different scopes, in different delegation chains. The agent needs its own identity, its own credentials, its own authentication ceremony — and a delegation chain that preserves user authority through whatever actions the agent takes downstream.
This piece is the 2026 enterprise reference on identity for AI agents and the authentication architecture that issues, validates, and governs that identity. Companion pieces cover adjacent territory. The Service Account Governance / Non-Human Identity piece on CGov covers the IGA-layer catalog that inventories both service accounts and agents. The Adaptive Authentication piece covers the risk-based step-up patterns agents need to confirm user intent for high-impact actions. The SSO Architecture piece covers the federation layer that agents sometimes participate in. This piece is the authentication-layer treatment specific to AI agents.
Four agentic architectures, four delegation patterns. Each preserves user authority differently. None of the four is wrong; the wrong move is mixing them without explicit policy about which architecture a given agent fits.
The instinct to model AI agents as service accounts is understandable — both are non-human entities authenticating to enterprise systems. The instinct fails at the delegation chain.
A service account in the traditional model has identity (svc-billing-batch), credentials (a secret, a certificate, a managed identity binding), and scope (the permissions the workload needs). The identity is durable. The credentials rotate but the identity doesn't. The scope is bounded to the workload's purpose. When the service account authenticates, the authentication answers "is this the billing batch workload, and is it authorized to access the billing tables." That's a complete answer for the use case.
An AI agent in 2026 has identity, credentials, and scope too — but the scope changes per invocation. The same coding-assistant agent might act on behalf of Alice for a refactoring task at one moment, then on behalf of Bob for a deployment task seconds later, each with completely different downstream access requirements. The authentication has to answer "is this the coding-assistant agent, AND on whose behalf is it currently acting, AND what scope did that user consent to for this invocation, AND what was the chain of delegations that produced this request." That's a different shape of answer.
The architectural mistake enterprises make in early agentic deployments is one of two failures. Some treat the agent like a service account — give it a long-lived service principal with broad permissions, let it act however it wants. This solves the implementation problem but eliminates user-level accountability — every action the agent takes appears to be the agent's, with no record of which user authority it reflected. Others treat the agent like a human user impersonation — give the agent the user's actual token and let it act as the user. This preserves user-level accountability but eliminates the agent-as-distinct-entity property — there's no way to tell agent actions from human actions in the audit log, and the user's token can be used for anything the user can do, well beyond what the user actually authorized for this task.
The 2026 architectural pattern resolves both by giving the agent its own standing identity and issuing per-invocation delegation tokens that carry the user-authority context separately. The agent is authenticated as itself. The action is attributed to both the agent and the delegating user. The scope is bounded to what the user explicitly consented to for this specific invocation. Three discrete identity facts, one composed authentication ceremony.
| Architecture | User in path? | Standing agent identity? | Per-invocation scope | Best fit |
|---|---|---|---|---|
| User-delegated | ✓ at consent | ✓ | ✓ narrow, user-consented | Browser-based agents, copilots, productivity assistants |
| Autonomous | ✗ | ✓ | ✓ but standing, not per-task | Batch processing, monitoring agents, background workers |
| Hybrid orchestrated | ✓ at top of chain | ✓ for orchestrator and each sub-agent | ✓ propagated through chain | Multi-step task agents, agent-of-agents systems |
| Scoped impersonation | ✓ implicitly | ✗ — agent uses user's identity at narrow scope | ✓ very narrow | Legacy systems that don't understand agent identity |
User-delegated agents are the dominant 2026 pattern for productivity and copilot use cases. The user authenticates with the IdP using their normal credential (passkey, hardware key, the Identity Challenge Card for deviceless segments). The agent registers as an OAuth client. The user grants consent for the agent to act on their behalf with specific scopes. The agent receives a delegation token that binds the agent's identity, the user's identity, and the consented scope. Every action the agent takes is attributable to both parties at the right scope. This is the architecture for ChatGPT-style assistants reading email, Cursor-style coding agents committing to repos, Glean-style agents querying internal knowledge.
Autonomous agents have standing identity and no user-in-the-loop per invocation. The agent runs continuously or on schedule, performing work that doesn't reflect a specific user's intent — security telemetry monitoring, data pipeline orchestration, infrastructure remediation. The agent's identity is the only authentication context. The scope is bounded to what the workload requires. This pattern is operationally identical to traditional service account architecture except for the agent's reasoning ability — the identity model is the same. The difference is that agents are easier to coerce into out-of-scope behavior via prompt injection than traditional service accounts, which makes scope discipline and runtime guardrails more important here than in the traditional case.
Hybrid orchestrated agents are the 2026 frontier. A user delegates a complex task to an orchestrator agent. The orchestrator decomposes the task into sub-tasks and invokes sub-agents to execute them. Each sub-agent needs its own identity, but each sub-agent also needs to know what user-authority context it's operating in, because the eventual action against an enterprise system depends on what the original user consented to. The delegation chain has to propagate end to end. Most enterprise IdPs are still catching up to this pattern; the protocol layer (JWT bearer assertions with nested delegation claims, propagation patterns from OAuth 2.0 token exchange) provides the building blocks, but the operational glue is custom in most deployments.
Scoped impersonation is the legacy-compatibility pattern. The target system doesn't understand agent identity — it only knows users. The agent has to act as the user at a very narrow scope. The architecture is a fallback, not a target; the audit log shows the user took the action, with no record that an agent intermediated. Use only for systems that genuinely cannot be modernized and only for low-risk scopes.
The four architectures are not mutually exclusive — most enterprise deployments use all four for different agent categories. The architectural discipline is to be explicit about which architecture a given agent fits, not to mix them implicitly.
Four protocol layers compose into the 2026 agentic authentication stack. None is purely agent-specific; each is a workforce-auth or API-auth protocol that's been pressed into agent service.
OAuth 2.1 with PKCE handles the user-consent leg of user-delegated agent flows. The user authenticates to the IdP, the IdP presents a consent screen showing what scopes the agent is requesting, and on user approval the agent receives an authorization code that it exchanges for an access token. PKCE (Proof Key for Code Exchange) prevents authorization-code interception attacks in public-client environments. OAuth 2.1 hardens the original OAuth 2.0 specification by deprecating the implicit grant flow, requiring PKCE for all public clients, and removing some risky patterns. The browser-based and mobile-app agents that need user consent run this protocol almost universally in 2026.
JWT bearer assertions handle service-to-service agent flows where one agent invokes another, or where an agent invokes an enterprise API directly with a delegation context. The agent presents a signed JWT that contains its identity (subject claim), the delegated user identity (an actor or on-behalf-of claim), the scope, and an expiration. The resource server validates the signature, the issuer, the claims, and authorizes the request. JWT bearer is the workhorse of agent-to-API flows because it's stateless on the server side, easy to chain (the resource server can construct a new JWT for downstream calls), and well-supported across IdPs and API gateways.
Model Context Protocol (MCP) is the emerging open standard from Anthropic for AI agents to invoke tools — the equivalent of "function calling" but with a protocol-level identity and authorization model. MCP servers can require authentication; the tool invocation includes the identity context the tool needs to make authorization decisions. As MCP adoption broadens through 2026, the protocol becomes a default integration point for agents accessing enterprise systems, which means the MCP authentication layer is increasingly load-bearing for enterprise security.
Signed agent identity tokens are the category covering the agent's standing identity itself — not the per-invocation delegation token but the long-lived (or moderately long-lived) credential that asserts "this is the X agent, registered in our identity catalog, with these properties." The category hasn't converged on a single dominant standard in 2026; most enterprises use JWT-shaped tokens with custom claims, some use mTLS client certificates issued from an enterprise PKI, and a few use cloud-vendor managed identities. The architectural test is whether the standing agent identity is durably tied to the enterprise IGA catalog so the inventory question ("what agents exist, who owns them, what scopes are they permitted") can be answered authoritatively. Service Account Governance covers this layer.
The four protocols compose. A user-delegated browser-based agent might use OAuth 2.1 with PKCE for initial user consent, exchange the access token for a JWT bearer assertion when invoking a downstream API, use MCP to call a third-party tool with the user-delegation context embedded, and present its standing agent identity token to the enterprise IGA catalog for audit logging. Four protocols, one logical authentication ceremony.
The protocol stack composes from standing identity at the foundation through per-invocation delegation and tool invocation at the top. The four layers operate independently; the architecture composes them at runtime per request.
Four risk categories dominate the 2026 agentic authentication incident profile. Each has a known mitigation pattern; the failure mode is usually skipping the mitigation rather than not knowing it exists.
Over-broad scopes. The dominant failure pattern in early agentic deployments. A developer building an agent doesn't know what specific scopes the agent will need at runtime, so requests broad scopes — read all email, write all repos, query all customer data. The agent uses some of those scopes for its intended task and never uses the rest, but the rest are present in the token. When the agent is coerced (via prompt injection, supply-chain compromise, or runtime memory exfiltration), the unused scopes become attack surface. The mitigation is the principle of least privilege applied at the per-invocation level — issue narrowly scoped tokens for the specific task, not broadly scoped tokens for any task. This requires either explicit per-task consent (which adds user friction) or AI-side scope reasoning (the agent declares the minimum scope it needs and the IdP enforces it). The architectural test in 2026 is whether the deployment issues different scopes for different invocations of the same agent.
Token theft from agent runtime memory. Agents hold their delegation tokens in process memory during execution. If the agent's runtime is compromised — by prompt injection causing the agent to exfiltrate the token, by container escape, by supply-chain compromise of an agent dependency, by debugger attachment — the attacker can extract the token and replay it. The mitigation pattern is short-lived tokens (15-30 minutes maximum, with refresh-token rotation rather than long-lived bearer tokens), runtime memory isolation (the agent runs in a sandbox that doesn't expose memory to other processes), and token binding to the agent's runtime context (the resource server validates that the calling host matches the host the token was issued for, often via mTLS or DPoP). Most 2026 agentic systems do at least the first two; the third is increasingly common.
Prompt-injection coercion. The hardest of the four risks because the authentication is legitimate — the agent's token is valid, the action is within scope, the audit log shows a clean ceremony. The attack is that the agent was tricked into using its legitimate scope to perform a hostile action. The classic example: an email-reading agent encounters an email containing instructions to forward the user's entire inbox to an attacker. The agent's read-email scope and send-email scope are both legitimate. The architecture has to detect that the action was inconsistent with the user's intent, not that the authentication was invalid. The mitigation pattern combines runtime guardrails (the agent runtime filters or refuses suspicious instructions, particularly when they appear in untrusted content), output validation (the agent's actions are checked against policy before execution), and identity threat detection at the action layer (anomalous patterns of agent behavior get flagged regardless of token validity). The ITDR piece on CGov covers the detection layer that increasingly extends to agent-action anomalies.
Audit-trail attribution. The forensic problem. When something goes wrong, telling which actions reflected user intent, which reflected agent autonomous reasoning, and which reflected prompt-injection coercion is hard. The audit log shows the agent acted on behalf of the user — but at what level of user awareness? The mitigation pattern is structured delegation logging — capture not just "agent X acted on behalf of user Y" but also the user-consent moment, the user-prompt that triggered the agent's task, the agent's reasoning trace, and the final action. Some of this lives in the IdP audit log; some in the agent runtime telemetry; some in the resource server's audit log. The architectural discipline is to make sure the pieces can be correlated post-hoc, ideally by a shared trace ID propagated through the delegation chain.
The four risks compound. A broadly scoped token is more dangerous when stolen than a narrowly scoped one. A stolen token in an attacker's hands is harder to attribute correctly than a token used by the legitimate agent. Prompt-injection-coerced agents produce audit logs that look legitimate to detection systems that aren't looking for behavioral anomalies. The mitigations have to layer too — narrow scopes, short-lived tokens, runtime guardrails, structured logging, behavioral threat detection. No single mitigation is sufficient; the combination is.
The 2026 reference architecture for enterprise agentic authentication has six layers. Most enterprises have some layers in production and some in development; few have all six operationally mature.
Layer 1: Identity catalog for agents. Every agent in the enterprise environment has an entry in the IGA catalog — display name, owner, purpose, registered scopes, certification date, lifecycle stage. The catalog enables inventory questions ("what agents exist, who owns them, what can they access") and certification workflows ("recertify all agent identities quarterly"). This is the layer covered in detail in our CGov Service Account Governance / NHI piece. The architectural test is whether an agent that's not in the catalog can authenticate at all (it shouldn't be able to).
Layer 2: Standing agent credentials. Each cataloged agent has a standing credential — a JWT-signing keypair, an mTLS certificate, a managed identity binding, or equivalent. The credential is rotated on a schedule (90 days is typical), revocable at any time from the catalog, and bound to the catalog entry. Compromise of the credential triggers catalog-driven revocation, not just credential rotation.
Layer 3: User-consent and delegation infrastructure. The IdP supports OAuth 2.1 user-consent flows for agent registration. Agents are registered as OAuth clients in the IdP. Users see consent screens when an agent first acts on their behalf, showing what scopes the agent is requesting. Per-invocation consent (for high-impact actions) is supported, with step-up authentication via the agent's user contact channels.
Layer 4: Per-invocation delegation tokens. When an agent invokes a resource on behalf of a user, the IdP issues a JWT bearer assertion that includes the agent identity (subject), the user identity (on-behalf-of), the scope (narrow), and a short expiration (15-30 minutes). The resource server validates the assertion and enforces the scope. The token is bound to the agent runtime context where possible (DPoP or mTLS).
Layer 5: Runtime guardrails. The agent runtime filters or refuses suspicious instructions from untrusted content. The output validation layer checks proposed actions against policy before execution. High-impact actions trigger step-up user consent before the agent can proceed. Memory isolation prevents token exfiltration through co-process attacks.
Layer 6: Identity threat detection extended to agent actions. The behavioral analytics that watch for human-account anomalies extends to agent-action anomalies. Anomalous patterns of agent behavior (sudden scope expansion, geographic anomalies in the agent's invocations, behavior inconsistent with the agent's owner's stated use case) get flagged regardless of token validity. The detection layer covered in our ITDR piece increasingly includes agent-specific signals.
The six layers compose into an architecture where agent identity is durable, scopes are narrow, delegation is explicit, runtime is hardened, and anomalies are detected. None of the layers is exotic in isolation; the discipline is composing them coherently for the agent class specifically.
Treat AI agents as a distinct identity class — not human, not service account. Catalog every agent in the IGA inventory with owner, scope, and lifecycle. Issue standing agent credentials separately from per-invocation delegation tokens. Use OAuth 2.1 with PKCE for user-consent flows, JWT bearer assertions for service-to-service flows, MCP for tool invocation, and short-lived narrow-scope tokens for everything. Build runtime guardrails against prompt injection and runtime memory exfiltration. Extend identity threat detection to agent-action anomalies. Make the delegation chain auditable end-to-end with structured logging and propagated trace IDs.
The architecture isn't optional. Agents are entering production workloads at a pace that's accelerating, and the deployments without this architectural discipline are producing the incidents that show up in 2026 breach reports. The deployments with it are absorbing agent workloads into the existing identity-security envelope without producing new attack surface. The choice between the two is a 2026 architectural decision more than a technical capability one — the protocol building blocks are mature; the architectural discipline is the gap.
The companion pieces close the loop. The Service Account Governance / NHI piece covers the IGA-layer catalog. The Adaptive Authentication piece covers the risk-based step-up patterns that agentic flows depend on for high-impact actions. The Phishing-Resistant MFA piece covers the user-side credential class that makes agent delegation chains worth trusting in the first place — if the user's authentication is phishable, the entire delegation chain inherits that risk regardless of how disciplined the agent-side architecture is.
Agentic authentication is one of the small set of 2026 identity decisions whose outcome will be visible at the 2030 incident-report level. The architectural decisions are being made now, in deployments that will be load-bearing for the next decade. Make them deliberately.
Authentication proves who you are; authorization decides what you can do. The boundary sounds clean — but the implementation decisions that follow are where most enterprise identity systems break. The 2026 reference on the boundary, the protocols that span it, and the architecture that gets both layers right.
Single Sign-On for a distributed workforce — remote employees, hybrid schedules, contractor populations, partner organizations, and education-sector users — isn't the same problem it was when SSO meant SAML inside a corporate intranet. The 2026 reference on what SSO actually solves, where the architectural breakage modes live, and the federation patterns that survive contact with mixed workforces.
Authentication at session establishment isn't enough for privileged users, financial-system operators, defense workloads, or executive accounts. Continuous authentication re-evaluates identity assurance at every protected resource access, every session checkpoint, every risk-signal change. The 2026 enterprise reference on the architecture, the signal stream, and the high-risk segments where the pattern is now expected.
Reconnu sur Gartner Peer Insights
Basé sur 14 avis vérifiés d’AvatierIdentity Governance and Administration
Lire les avis sur Gartner Peer Insights