Identity for AI

AuthPlayground concepts

Enterprise AI becomes easier to understand when you consider the trust problems protocols solve. The AuthPlayground lets you explore OAuth 2.0 extension protocols using a common enterprise scenario.

Ready to jump right into the playground? Learn how in Getting Started with the AuthPlayground.

The enterprise AI problem

Imagine you’re the Chief Architect at an enterprise company. Over the past year, the company has moved from isolated experiments with AI to a company-wide initiative:

  • Sales wants AI to prepare account teams for customer meetings

  • Support wants AI to summarize cases and highlight risk

  • Engineering wants coding assistants

  • HR wants policy assistants

  • Finance wants AI to analyze spending trends

You face two competing directives:

  1. The Chief Executive Officer (CEO) wants to use AI to make every employee more productive.

  2. The Chief Information Security Officer (CISO) requires that every AI action remains secure, attributable, governed, and auditable.

These goals can be hard to reconcile. Enterprise AI is more than connecting a Large Language Model (LLM) to a few APIs. You must preserve identity, authorization, context, and accountability as AI acts across systems and services, on behalf of people or under its own machine authority.

The meeting preparation scenario

Consider Sarah, a Senior Account Executive at your company. The night before an important customer meeting, she opens the company’s AI assistant and asks:

Prepare me for tomorrow’s Apex Logistics meeting.

For Sarah, this is one request. But behind the scenes, the AI assistant might need to:

  • Read the Apex Logistics opportunity in Salesforce

  • Retrieve open ServiceNow support cases

  • Search relevant communications in Microsoft 365

  • Analyze customer data in Salesforce and Databricks

  • Review engineering Jira issues

  • Generate a meeting briefing

  • Potentially perform follow-up actions

One human request becomes a multi-step, multi-system workflow:

Diagram showing the request from Sarah to the AI assistant, MCP servers, and resources.

Sarah doesn’t need to understand this complexity, but the enterprise architecture must.

Identities in the workflow

Sarah is the human identity. Non-Human Identities (NHI) might include an AI assistant, an AI agent, a Model Context Protocol (MCP) server, and other internal services. In this context, NHIs are workloads, or software performing work. Just like Sarah, workloads need identities to authenticate and be authorized.

The human and workload identity distinction matters because the enterprise needs to answer two different questions:

  1. Which human initiated the activity?

  2. Which software workload is performing the activity?

Sometimes, a human isn’t involved. An autonomous monitoring agent, retrieval agent, or background telemetry service might operate under its own machine authority.

There are two patterns to keep in mind:

Diagram showing the human-initiated and automous patterns.

Delegation is relevant when a workload exercises authority involving another principal. Workload identity doesn’t depend on delegation when workloads exercise autonomous authority.

Understanding the architecture

To handle complex workflows such as Sarah’s, it helps to picture the architecture in three layers.

Layer 1: User and AI assistant

This is how the workflow begins:

  1. Sarah signs on, opens the AI assistant, and asks for help.

  2. The enterprise establishes Sarah’s human identity.

  3. The AI assistant acts as the orchestrator. It interprets Sarah’s request, determines the required work, and coordinates the work.

Knowing that Sarah authenticated is only the beginning. The enterprise must determine which software is executing, whose authority is involved, and what the software is allowed to do.

Layer 2: MCP tools, agents, and other workloads

The AI assistant can invoke specialized workloads to perform parts of the job. For example, a planner agent might determine which information is required. A retrieval agent might gather that information. An MCP tool or gateway might provide controlled connectivity to an enterprise API.

Diagram showing the workload workflow from AI assistant, Planner Agent, and Retrieval Agent to the MCP Gateway.

These are software workloads participating in execution. Some operate under their own machine authority. Others participate in an operation involving delegated human authority. Some cross into another authorization domain. Others continue through a chain of internal services. These differences determine which security controls are appropriate.

Layer 3: Downstream enterprise systems

These are the systems (such as Salesforce, ServiceNow, Databricks, Jira, Microsoft 365, or internal APIs) that hold enterprise data or perform business actions. Each system protects its own resources and can have its own authorization requirements.

Sarah’s authentication to the AI assistant doesn’t automatically mean that every downstream system accepts whatever credential the assistant presents. The target system must decide whether the requested operation is allowed.

Trust boundaries

A trust boundary is a point where one security or authorization domain must decide whether to trust and allow a request coming from another context. For example:

Diagram showing the AI workflow on one side of the trust boundary and Salesforce on the other side.

Crossing that boundary raises questions such as:

  • Who authenticated the principal (Sarah)?

  • Which workload is acting?

  • Is delegated authority involved?

  • Is the credential intended for this authorization domain?

  • Which resource is being requested?

  • What permissions should apply?

  • Should the target system allow the operation?

Because of these boundaries, enterprise AI can’t be secured with user authentication alone. The architecture must preserve enough trusted context for each system to make the decisions it owns.

What can go wrong?

Without the right controls, several problems emerge.

Generic service accounts hide accountability

When every MCP tool uses a powerful service account, you can’t tell who updated a record, for example in Salesforce. Important context is lost. When human delegation is involved, the enterprise must understand both the principal behind the request and the software actor performing the action.

One user token becomes a universal key

It’s tempting to forward Sarah’s original token everywhere. But a token issued for one application, audience, or resource shouldn’t automatically become valid across every enterprise system. Salesforce, ServiceNow, and other systems can have different authorization and trust requirements.

Powerful workload credentials create their own risk

Giving software an identity doesn’t mean giving it unlimited authority. An AI workload can have a legitimate identity and still request something it shouldn’t be allowed to do.

  • Identity answers the question: Who is this?

  • Authorization answers: What is it allowed to do?

  • When delegation is involved, there’s another question: What is it allowed to do using authority associated with this principal?

Too much approval destroys usability

The opposite extreme is to ask Sarah to approve every individual action. Approve Salesforce, then approve ServiceNow, then approve another internal service. This can cause approval fatigue and undermine the productivity AI was supposed to provide. Enterprise AI needs a middle ground:

Preserve identity and control without turning one credential into a universal key or every AI action into another sign-on prompt.

Securing the workflow with the right controls

Not every step in Sarah’s workflow has the same security problem.

Diagram showing the internal execution and cross trust boundary workflows side by side.

Protocols work together to answer different enterprise trust problems inside the workflow. They’re composable pieces, not a mandatory sequence. You can combine protocols to solve specific problems your enterprise faces.

Protocol Description

PKCE

Protects authorization-code redemption

After the user-facing authorization flow, the client receives an authorization code. Proof Key for Code Exchange (PKCE) protects the Authorization Code grant from interception attacks by introducing a cryptographic verifier that only the legitimate client can produce.

PAR

How the request reaches the authorization server

Pushed Authorization Requests (PAR) invert the traditional authorization flow. Instead of passing authorization request parameters through the browser redirect, the client pushes them directly to the authorization server first and receives a short-lived reference URI to use in the redirect. This eliminates parameter tampering in the front channel entirely.

DPoP

Binds credentials to the caller’s key

A bearer token is only as secure as the channel it travels on. What if someone copies the token? Demonstrating Proof of Possession (DPoP) sender-constrains access tokens by binding them to a client-generated key pair. Even if a token is intercepted, it can’t be used because the attacker doesn’t hold the private key.

DPoP doesn’t require a human or delegated authority. It can sender-constrain tokens used by autonomous workloads as well as tokens used in human-initiated workflows.

Token Exchange

A new token for a different context

Token Exchange enables an agent or downstream service to exchange a subject’s token for a new one scoped to the action it needs to perform, while the original subject remains auditable in the chain. The subject’s authority is delegated to the actor, preserving the distinction between them without impersonation.

RAR

What’s the client allowed to do?

Standard OAuth scopes are coarse-grained strings. Rich Authorization Requests (RAR) allow clients to express fine-grained authorization requirements as structured JSON objects using the authorization_details parameter. This is helpful when you need to authorize a specific transaction rather than a class of operations.

Transaction Tokens

Providing context in a transaction chain

Transaction Tokens are short-lived tokens designed to propagate authorization context through a chain of microservices. Each service in the chain can verify not only that the request is authorized, but that it originated from the expected upstream caller. This is critical for zero-trust service-to-service communication.

XAA / ID-JAG

Carries delegated user identity across the authorization domain boundary

Cross-Domain Access (XAA) / Identity Assertion JWT Authorization Grant (ID-JAG) enables cross-domain resource access by exchanging an ID Token for an ID-JAG assertion. When a user authenticates with one identity provider, but needs to access a resource governed by a different authorization server, XAA allows delegated identity information to be conveyed to another authorization domain. The receiving authorization domain evaluates that relationship under its own policy and determines what access should be granted.

SPIFFE

Which workload is running?

Secure Production Identity Framework for Everyone (SPIFFE) moves beyond service accounts and API keys. It provides cryptographic workload identity through SPIFFE Verifiable Identity Documents (SVID), giving every service in your infrastructure a verifiable identity it can use to authenticate to other services.

A workload can have a SPIFFE identity and separately use a DPoP key to sender-constrain an OAuth token. SPIFFE establishes workload identity while DPoP protects use of a credential.

Resource Metadata

What’s the resource?

Protected Resource Metadata enables resource servers to advertise their own authorization requirements in a machine-readable document. Clients discover which authorization server governs a resource and which scopes or policies apply. This happens automatically, without out-of-band configuration.

CIMD

Who’s the client?

Client ID Metadata Documents (CIMD) demonstrate a model where OAuth clients are identified by an HTTPS URL hosting a JSON file as its client_id, instead of an opaque string registered in a directory. The authorization server fetches the client’s metadata document directly from that URL, enabling self-sovereign client registration and dynamic discovery.

Full Cross-Domain Access

How to combine protocols

Full Cross-Domain Access combines PKCE, PAR, Token Exchange, DPoP, and XAA / ID-JAG into a single end-to-end scenario for cross-domain resource access. Each protocol contributes something to the whole picture.

Key takeaways

One AI prompt can require many different security decisions. A human such as Sarah is sometimes the principal behind an activity. An autonomous workload can act entirely under its own machine authority. Agents, MCP tools, gateways, and services are software workloads with identities of their own. Authorization constrains what these identities are allowed to do.

Crossing an authorization boundary can require security context appropriate for the receiving domain. Internal service chains might need trusted transaction context to survive multiple hops. And possession of a token isn’t always enough to use it.

As you explore individual protocols, keep returning to the underlying questions:

  • Which principal is involved?

  • Which workload is acting?

  • Is delegated authority involved?

  • What operation is being requested?

  • Which authorization domain owns the decision?

  • What transaction does this request belong to?

  • Is the credential intended for this context?

  • Can the presenter prove possession of the key associated with the token?

  • Can the enterprise reconstruct what happened afterward?

The protocols solve different pieces of these problems. Together, they provide building blocks that operate across users, workloads, services, and trust boundaries without losing the identity, authorization, context, and accountability needed to govern it.

Next steps

Learn how to get started with the AuthPlayground.