Agent identity and authorization for enterprise integration
Every agent call answers three questions: who is the user, which agent is acting, and what may this call do downstream. Most agent incidents start with one of those answers being wrong or missing.
Integration platforms have spent twenty years learning to carry identity across systems: principal propagation, SAML bearer assertions, OAuth client credentials, technical users with carefully trimmed roles. AI agents break some of those habits. An agent acts for a person, but it also chooses its own calls; it may delegate to another agent; and it may run for hours after the person has closed the browser. The shortcuts that were tolerable for fixed interfaces, such as one powerful technical user per system, become the root cause of agent incidents.
Three identities on every call
| Identity | Question it answers | How to represent it |
|---|---|---|
| User | On whose behalf is this happening? | The subject of the access token, propagated or exchanged end to end |
| Agent | Which software is acting, and in which version? | A registered OAuth client (or workload identity) per agent, not per platform |
| Downstream service | What credential reaches the system of record? | A narrowly scoped token minted for that API, never the user's original token |
The rule that follows: an agent's effective permission is the intersection of what the user may do and what the agent is allowed to do, never the union. An HR copilot should not read a salary its user could not read, and a user with broad rights should not inherit them all just because they asked an agent a question.
Two modes: on behalf of a user, or as itself
- Delegated (on-behalf-of). The agent acts in an interactive session for a signed-in user. Use OAuth authorization code with PKCE, then exchange the user's token at the gateway for a downstream token scoped to the tool (OAuth 2.0 Token Exchange, RFC 8693). The downstream token can carry an
actclaim naming the agent, so logs show both the user and the actor. - Autonomous (agent-as-principal). The agent runs on a schedule or reacts to events with no user present, for example reconciling bank statements overnight. Give it its own identity, its own minimal role and short-lived credentials, and treat it like a service account with an owner and a recertification date.
Most incidents come from mixing the two: an autonomous job running under a user's long-lived refresh token, or an interactive agent quietly falling back to a technical user when token exchange fails. Make the mode explicit in the agent's registration.
What MCP specifies
For HTTP transports, MCP authorization is built on OAuth 2.1. The MCP server (or the gateway in front of it) is an OAuth resource server:
- It publishes Protected Resource Metadata (RFC 9728) so clients can find the right authorization server.
- Clients request tokens bound to the specific server using resource indicators (RFC 8707), which stops a token for one MCP server being replayed at another.
- Token passthrough is explicitly discouraged: the server should not forward the client's token to upstream APIs.
- The 2026-07-28 revision adds
issvalidation (RFC 9207), binds client credentials to their issuer, and deprecates Dynamic Client Registration in favour of Client ID Metadata Documents, where a client's ID is a URL to a document you can inspect and allow-list.
Client ID Metadata Documents are the quiet enterprise win here. Instead of letting any MCP client self-register against your authorization server, you approve known client metadata URLs, which turns "which agents can connect?" into a reviewable list.
The hard problem: multi-hop delegation
User → orchestrator agent → finance agent (over A2A) → MCP tool → API. By the fourth hop, who authorized what? OAuth handles one hop of delegation well. Chains across agents, organizations and asynchronous gaps are where current standards run thin, and both NIST and recent academic surveys call this out as the main open gap.
Until standards settle, pragmatic patterns work:
- Exchange at every hop. Each agent exchanges the incoming token for one scoped to its next call, preserving the original subject and appending itself as actor.
- Narrow with each hop. Scopes only shrink along the chain. A sub-agent never gets more than its caller had.
- Bound the lifetime. Tokens issued for long-running tasks expire with the task; resumption after a pause (A2A
AUTH_REQUIRED, MCPinput_required) triggers re-authorization. - Carry a correlation ID through every hop, so the audit trail can be stitched even when token chains cannot.
Workload identity for agents
Static API keys and long-lived client secrets are the most common agent credential in 2026, and the most common finding in reviews. SPIFFE/SPIRE workload identity is becoming the default alternative: each agent instance gets a short-lived, automatically rotated, cryptographically verifiable identity that can be exchanged for OAuth tokens. Cloud platforms offer equivalents (managed identities, workload identity federation). The direction is the same everywhere: no secrets in agent configuration, and identities that disappear when the agent does.
Where the standards are
| Body | Work | Status (Oct 2026) |
|---|---|---|
| NIST CAISI | AI Agent Standards Initiative: interoperability, security, identity | Launched 17 Feb 2026; treats MCP and A2A as interoperability baselines |
| NIST NCCoE | Concept paper on software and AI agent identity and authorization (OAuth 2.0/2.1, OIDC, SPIFFE/SPIRE, SCIM, NGAC, SP 800-207) | Comments closed 2 Apr 2026; practice guide to follow |
| IETF | Drafts extending OAuth delegation and WIMSE workload identity to agents; discovery work on named agents | Individual drafts and early chartering; not yet standards-track RFCs |
| MCP | OAuth 2.1 resource server model, resource indicators, Client ID Metadata Documents | In the 2026-07-28 specification |
| A2A | Security schemes declared on Agent Cards: OAuth 2.0 with PKCE, OIDC, device code, API keys, mTLS; signed cards | In the v1.0 specification |
The consistent message from NIST is adapt, don't reinvent: existing OAuth, OIDC and workload identity standards can cover most agent needs today if applied rigorously. Waiting for a dedicated "agent identity standard" is not a reason to keep shared technical users.
In SAP landscapes
SAP integration architects already know principal propagation from the Cloud Connector and the OAuth 2.0 SAML bearer flow. SAP is rolling out principal propagation and SAML bearer token exchange for the MCP Gateway from its September 2026 update, carrying end-to-end user identity from the calling agent to the backend. Where it is not yet enabled on your tenant, enforce user scoping in the API artifact's policies from the authenticated identity, and avoid tools that accept a user or employee ID as a free argument.
Checklist
- Register every agent as its own client with an owner, mode (delegated or autonomous) and review date.
- Remove shared technical users and static API keys from agent paths.
- Bind tokens to resources (RFC 8707) and exchange them at the gateway (RFC 8693); never pass through.
- Record user, agent and tool on every audit event, joined by a correlation ID.
- Allow-list Client ID Metadata Documents for MCP clients; validate
iss. - Expire task-scoped tokens with the task; re-authorize after long pauses.
- Verify A2A Agent Card signatures and prefer mTLS or OAuth with PKCE for partner agents.
- Recertify agent access quarterly, like any privileged account.
Frequently asked questions
Should an AI agent use the user's token to call backend APIs?
No. The gateway or MCP server should exchange the user's token for a narrowly scoped downstream token (OAuth Token Exchange), keeping the user as subject and recording the agent as actor. Passing the original token through is discouraged by the MCP specification.
What is a Client ID Metadata Document?
It is a document at a URL that describes an OAuth client; the URL itself is the client ID. MCP 2026-07-28 recommends it over Dynamic Client Registration, which lets enterprises allow-list known agent clients instead of accepting self-registration.
Is there a standard for AI agent identity yet?
Not a single dedicated one. NIST's 2026 work recommends adapting OAuth, OpenID Connect, SPIFFE and related standards, and the IETF has early drafts. MCP and A2A already specify how to use OAuth-based schemes.
Sources and further reading
- WorkOS: NIST AI Agent Standards Initiative explained
- Cloud Security Alliance: IETF's race to standardize AI agent identity
- Model Context Protocol: 2026-07-28 key changes
- A2A: What's new in v1.0
- AI Identity: standards, gaps and research directions for AI agents (arXiv)