MCP agent identity is becoming a protocol priority because browser-based human consent does not fit a cloud agent running while its user is offline. But the protocol has not completed a clean migration from human consent to autonomous agent identity. The accurate 2026 picture is layered: a released OAuth authorization baseline, a stable enterprise extension, several underlying standards, and open proposals for workload identity and proof of possession.
That distinction matters. A roadmap item is not a production control. A self-declared clientInfo field is not an authenticated agent. And a token that proves key possession does not prove that a specific user authorized a specific task.
The useful question is therefore not whether an agent has an identity. It is whether an MCP resource server can verify the whole chain:
Which workload is calling, which human or organization authorized it, which resource and action were delegated, how long that authority lasts, and how the decision can be revoked and audited.
The 2026 MCP Authorization Status Map
The MCP 2026-07-28 specification defines the current production baseline for HTTP authorization. An MCP server acts as an OAuth resource server, an MCP client acts as an OAuth client, and the authorization server issues resource-specific access tokens. The release added issuer validation, issuer-bound client credentials, resource audience checks, scope guidance, and a preference for Client ID Metadata Documents. Authorization remains optional for MCP implementations, and STDIO deployments are expected to obtain credentials from their environment.
The specification is built on the OAuth 2.1 security model, although OAuth 2.1 itself remains an active IETF draft. So it is precise to say that MCP adopts OAuth 2.1 requirements, not that OAuth 2.1 is already a final RFC.
The rest of the identity stack sits at different maturity levels:
| Mechanism | What it proves or controls | Status on 2026-08-30 |
|---|---|---|
| Core MCP OAuth | Whether a client can access a particular MCP resource | Released in the 2026-07-28 core specification |
| Enterprise-Managed Authorization | Whether an enterprise IdP allows a client to act for a signed-in employee at an MCP server | Stable optional MCP extension |
| ID-JAG | How a user's identity assertion and delegated authority cross trust domains | Active IETF working-group draft |
| Workload Identity Federation | Which cloud workload is calling with a platform-issued identity | Open MCP proposal, SEP-1933 |
| DPoP | Whether the access token presenter controls the bound private key | RFC 9449 is final; the MCP profile, SEP-1932, is still open |
| Agent-to-sub-agent delegation | How a parent agent grants narrower authority to a child | Official roadmap direction, not a completed MCP profile |
The new MCP roadmap correctly identifies agent identity and enterprise-ready security as a priority. It explicitly names Workload Identity Federation, ID-JAG, token exchange, and DPoP. It does not promise that all four are already part of the released core protocol or commit them to a specific release date.
One Agent Call Contains at Least Three Identities
The phrase agent identity compresses several different principals into one label.
First is the human or organizational subject. This is the person, service owner, or enterprise policy authority whose resources are affected. It answers who is accountable and whose permissions create the upper bound.
Second is the workload identity. This identifies the Kubernetes service account, SPIFFE workload, cloud runtime, or other executing process. It answers which deployed workload is actually presenting credentials.
Third is the agent and task authority. A logical agent may move across processes, spawn sub-agents, or run several jobs under one workload. This layer answers which task is being executed, what authority was delegated to it, and whether that authority is narrower than both the user's permissions and the workload's platform role.
An OAuth client ID is not automatically all three. Neither is MCP's per-request clientInfo: the 2026-07-28 changelog describes it as client metadata, not a cryptographically authenticated identity.
This is why shared API keys and long-lived service-account tokens fail. They may let the request through, but they collapse actor, subject, task, and authority into one reusable secret. After an incident, the log can show which key was used while remaining unable to show which user, agent, or delegated task caused the action.
What the Stable Enterprise Extension Solves
Enterprise-Managed Authorization is already a stable MCP extension. It places the enterprise identity provider between the MCP client and the MCP server's authorization server. The user signs in to the enterprise IdP, the client obtains an identity assertion, the IdP issues an Identity Assertion JWT Authorization Grant, and the MCP authorization server exchanges that grant for its own access token.
This removes repeated per-server consent prompts and lets the enterprise enforce group, role, conditional-access, onboarding, and offboarding policy centrally. The MCP server still controls its own access token and local authorization policy.
What it does not do is fully identify an autonomous cloud workload. The flow still begins with a user identity assertion. The underlying ID-JAG specification is also still an Internet-Draft, even though the MCP extension that uses it is stable. Those statuses can coexist, but they should not be presented as equivalent.
What Workload Identity Federation Would Add
SEP-1933 proposes Workload Identity Federation for MCP. Instead of registering another long-lived client secret, an agent workload would present a short-lived JWT issued by Kubernetes, SPIFFE/SPIRE, or a cloud runtime. The authorization server would validate the trusted issuer and workload claims, then exchange that assertion for an MCP access token.
This is a strong direction because it reuses the identity lifecycle the execution platform already operates. A terminated pod loses its credential. A moved workload receives a new platform identity. Trust can be restricted by issuer, namespace, service account, audience, and deployment policy.
But SEP-1933 is still an open proposal. Its pull request is unmerged, its testing section remains incomplete, and maintainer discussion still points to conformance tests and SDK implementations as future work. It belongs in architecture planning and controlled experiments, not in a claim that MCP workload identity is already standardized.
It also answers only part of the authorization question. Workload identity can prove which process is running. It does not by itself prove which user delegated an action, whether the task is within that delegation, or whether a child agent received narrower authority than its parent.
What DPoP Proves, and What It Does Not
RFC 9449 DPoP binds an access token to a key controlled by its presenter. Each request carries a proof signed by that key. A stolen token is therefore less useful to an attacker who lacks the private key.
DPoP is valuable, but its boundary is narrow. It is not client authentication, a workload identity system, or an authorization policy. The open MCP DPoP proposal follows the standard HTTP method, URI, token, and key binding model. It does not currently bind the full JSON-RPC tool arguments into the proof. A valid DPoP proof can therefore show who holds the key without proving the semantic integrity of every MCP tool argument.
The distinction creates a useful control model:
- Workload identity identifies the executing machine principal.
- ID-JAG carries a user's identity and delegated authorization across trust domains.
- OAuth access tokens describe the target resource and granted scope.
- DPoP reduces replay by binding the token to a key holder.
- MCP authorization policy decides whether the requested operation is allowed.
- Elicitation or another human approval mechanism handles high-risk escalation.
No single layer replaces the others.
A Verifiable Delegation Chain for Production MCP
A production design should issue a resource-specific token for each trust boundary instead of forwarding the user's original token through an agent and its tools. The chain can be modeled as:
Human or organization policy
↓ delegates
Logical agent and task
↓ runs as
Platform workload identity
↓ exchanges
Resource-specific, short-lived access token
↓ sender-constrained where supported
MCP resource request
↓ recorded as
Subject + actor + client + resource + scope + task + proof + parent delegation
The effective permission should be the intersection of four sets:
effective authority = user ceiling
∩ organization policy
∩ workload role
∩ task-specific delegation
This prevents a broadly privileged user token from silently becoming a broadly privileged agent token. It also gives sub-agents a natural rule: a child can receive a subset of the parent's remaining authority, never a superset.
The audit record should preserve the stable subject identifier, workload issuer and subject, OAuth client, target resource, requested and granted scopes, token identifier, proof-key thumbprint where available, task ID, parent delegation ID, policy decision, and revocation status. Logging only the model name or API key leaves the accountability chain incomplete.
Security Tests Are the Migration Gate
Identity architecture becomes trustworthy when its failures are executable tests. Before allowing unattended MCP calls, test at least these cases:
- Reject a token with the wrong issuer or resource audience.
- Reject expired tokens and credentials from terminated workloads.
- Reject replay when sender-constrained tokens are enabled.
- Reject a child agent requesting scopes absent from its parent delegation.
- Reject cross-tenant subject or issuer substitutions.
- Revoke a parent delegation and verify that all descendant authority stops working.
- Require step-up approval for destructive actions even when the agent has a valid identity.
- Confirm that audit logs can reconstruct the human subject, workload actor, task, resource, policy decision, and resulting action.
These tests expose the difference between authentication and accountable authorization. A request can carry a valid workload identity and still be unauthorized for a specific task.
What Teams Can Deploy Now
Teams do not need to wait for every draft to finish.
Use the released MCP authorization baseline for issuer discovery, audience restriction, least-privilege scopes, issuer-bound client credentials, and short token lifetimes. Use the stable Enterprise-Managed Authorization extension where centralized workforce policy fits the deployment. Use established platform workload identity and token-exchange systems behind a carefully controlled gateway when unattended services need machine identity, while treating SEP-1933 as an interoperability target rather than a finished specification.
Keep DPoP experiments behind capability negotiation until the MCP profile stabilizes. Preserve human approval for irreversible operations, permission escalation, and ambiguous intent. This complements the MCP Elicitation control flow: identity determines who and under what prior authority; elicitation creates a recoverable decision point when that authority is insufficient.
The broader lesson also differs from the interface question in MCP versus CLI. CLI and MCP can both execute a command. Unattended remote execution raises a separate problem: proving the actor and authority at every resource boundary.
MCP is moving toward that answer. The released protocol already provides a stronger OAuth foundation, the enterprise extension solves an important user-delegation case, and the roadmap names the remaining pieces. The honest 2026 architecture keeps those layers separate until each can be verified.
FAQ
What is MCP authorization?
MCP authorization is the HTTP transport framework that lets an MCP client obtain and present OAuth access tokens to a protected MCP server. It covers resource discovery, client registration, scopes, issuer checks, audience binding, token use, and error handling.
Does agent identity eliminate human consent?
No. It moves low-risk, pre-authorized, unattended work from repeated browser prompts to explicit delegation and policy. Destructive actions, privilege escalation, ambiguous intent, and new resource access can still require human approval.
What is the difference between agent identity and workload identity?
Workload identity identifies the executing process or runtime. Agent identity may also need to identify the logical agent, task, represented user, parent delegation, and authority. A complete agent identity architecture links these layers without treating them as one principal.
Is MCP Workload Identity Federation ready for production?
MCP's SEP-1933 is still an open proposal as of 2026-08-30. Teams can use mature cloud or SPIFFE workload identity systems today, but should not claim MCP-wide interoperability until the proposal, tests, and implementations stabilize.
Is Enterprise-Managed Authorization the same as workload identity?
No. Enterprise-Managed Authorization carries enterprise user identity and policy across trust domains. Workload identity identifies the cloud process making the call. Many unattended enterprise agents will ultimately need both.