Enterprise MCP authorisation patterns; A detailed synopsis

Authentication in Agentic flows begins with Authority

Authentication for an agentic system should not begin with a choice between OAuth, OIDC, client credentials, JWTs, or bearer token pass through. It should begin by defining where the agent’s authority originates, which component exercises that authority, and how narrowly its permissions can be constrained.

For the purpose of this article I am only considering enterprise MCP applications and HTTPS transport. Not looking at individual users on a personal client such as Claude Desktop or Cursor. So not covering Dynamic client registration or Client ID Metadata Documents.

An agent may act:

1. On behalf of an authenticated user;
2. Independently as a machine workload;
3. A machine workload carrying delegated user authority.

These models can produce similar MCP requests, but they represent different trust relationships. Treating them as interchangeable creates ambiguity around accountability, permission scope, revocation, and auditability.

The main distinction is between the identity that initiated an action and the identity of the component that executes it.

Event -> Agent -> Task -> MCP Server

For each action, the architecture should be able to answer:

Action = Responsible workload + Authority + Capacity granted + MCP server

In a traditional application these identities are often closely aligned. Agentic systems break that assumption. A request may cross planners, sub-agents, queues, approval steps, workflow engines, and several MCP servers. Authentication must therefore be designed as an explicit flow of identity and authority, rather than as a bearer token forwarded through every component.

This is also a risk-management issue. Agents are designed to search across available capabilities for a path to completion. If an agent inherits broad user or platform permissions, an incorrect tool choice, prompt injection, or poorly constrained plan can exercise more authority than the task required.

Authority should be constrained to the combination of:

Authority = Workload + Capability + Resource + Context

The authentication mechanism should follow from this authority model.

How agentic authentication differs from application authentication

Agentic flows introduce characteristics that conventional application authentication does not normally need to handle.

Execution can fan out

A single user request may produce several independent operations against different MCP resources. Each operation should be authorised according to its own capability, audience, and target resource rather than inheriting the authority of the original request as a whole.

Issue -> Retrieve information -> Check status -> Update -> Additional task

The executor may differ from the initiator

The user-facing application may not perform the action itself. A specialist agent, background worker, or workflow service may execute it later. User identity explains whose authority is represented; workload identity explains which system exercised it. Enterprise audit trails often need both.

• User identity → whose authority is represented
• Workload identity → which system exercises it
• Permission → which operation may be performed
• Audience → which service may accept the credential

Execution may outlive the user session

A request may wait for approval, enter a queue, retry later, or be scheduled for future execution. Workflow state should preserve the initiating identity, intended workload, requested capability, target resource, purpose, and correlation identifier. It should not contain reusable access tokens, refresh tokens, client secrets, or private keys.

A request record proves that an action was initiated. It should not automatically create indefinite authority to perform it. Some actions should be re-authorised at execution time; others may rely on an explicit durable approval. That distinction should be represented as policy, not inferred from the lifetime of an application token.

The model is not the security boundary

The language model may propose a capability, but it should not acquire, inspect, store, refresh, or manipulate credentials. Token acquisition, audience selection, policy evaluation, credential storage, and enforcement should remain within deterministic platform components and should be handled explicitly outside the model bounds.

Proposed action -> Policy -> Credentials -> MCP Server action

Enterprise authentication patterns

For enterprise MCP deployments, the most useful baseline is three patterns: delegated user authorisation, machine-to-machine OAuth, and a hybrid model that represents both the user and the workload. MCP uses established OAuth and OpenID Connect conventions rather than inventing an MCP-specific identity system.

Delegated user authorisation

A user-delegated agent acts using authority derived from an authenticated individual. The user normally authenticates through OIDC, while OAuth is used to authorise access to the MCP resource. This is appropriate where access depends on the initiating user’s role, entitlements, or consent.

User request -> Agent capability -> User auth delegated -> MCP token given ->
MCP server operation

The simplest implementation but the most fraught with danger is direct token pass-through. Rather than receiving authority designed specifically for the MCP operation, the MCP server inherits another system’s token format, trust relationships, and security assumptions. This relies in a single authorisation flow that more strongly couples AI workloads to a IDP or external identity flow outside of your application. A inherited trust relationship. This should normally be treated as a transitional pattern as it couples the agent and MCP server to an identity provider and authorisation flow that sits outside the application.

A stronger implementation exchanges or translates the user’s authority into a short-lived token specifically intended for the target MCP server. MCP requires resource indicators and audience validation, reinforcing the principle that tokens should be issued for a specific resource rather than accepted generically.

Advantages

• Preserves user-specific entitlements and attribution.
• Supports interactive consent and step-up authentication for sensitive actions.
• Fits existing enterprise OIDC and OAuth identity platforms.

Limitations

• Interactive flows do not suit unattended jobs.
• Consent can become repetitive across many MCP servers without central policy.
• Direct pass through creates coupling to upstream token formats and identity providers.
• Long-running tasks require explicit delegated task authority rather than an assumed live session.

Machine-to-machine OAuth

Autonomous agents operating without an active user should derive authority from a workload identity. SEP-1046 finalised support for the OAuth client credentials flow for MCP machine-to-machine scenarios. The authority belongs to the business process or workload rather than to an employee.

Event -> Workload auth -> Policy -> Token issued -> MCP server operation

The MCP client credentials extension supports shared client secrets and signed JWT bearer assertions under RFC 7523. JWT assertions are the recommended default. This does not mean that every MCP access token must itself be a JWT. It means the preferred client-authentication method is a short-lived assertion signed with the workload’s private key, rather than transmitting a long-lived shared secret.

Why JWT assertions are preferred

• The private signing key is not transmitted to the authorisation server.
• Assertions are short-lived and audience-bound to the token endpoint.
• Public keys can be rotated and distributed through standard metadata or JWKS mechanisms.
• Compromise of an individual assertion has a smaller useful lifetime than compromise of a reusable secret.

Trade-offs

• Key management, rotation, and JWKS publication add operational complexity.
• Clock skew and claim validation must be implemented correctly.
• Shared secrets remain simpler and widely supported, but create a larger risk if copied, logged, or leaked. Secrets prove ownership, not authority.
• Client credentials contain no human context; they are unsuitable where a person must approve or be accountable for the action.

The main architectural danger is a single broad platform identity with access to unrelated domains. Workload identities should be separated by business purpose, ownership, resource set, and risk profile. Each workload should have a documented owner, approved capabilities, managed credential lifecycle, and regular access review.

Hybrid user and workload identity

Many enterprise agents require both delegated user authority and a trusted machine identity. The employee or customer supplies the business authority; the approved workload supplies the execution identity. The downstream policy decision can require both.

User initiates -> Workload action -> Human in the loop -> 
User + Workload evalutation permissions -> MCP auth

This evaulation framework requires a workload and a user credentials to be both valid

Aproval = User auth + Workload auth + Permitted action + Valid context

This model is particularly relevant for customer service, HR administration, financial approvals, and other regulated workflows. It prevents a trusted platform from performing sensitive actions without user authority, while also preventing an authorised user from reaching the MCP server through an unapproved workload.

The EU AI Act does not prescribe a specific OAuth design or require every agent request to contain two identities. However, for high-risk AI systems it requires effective human oversight and event logging proportionate to the risk and level of autonomy. A hybrid identity model supports those obligations by making the supervising or approving natural person distinguishable from the machine that executed the action, and by preserving an auditable chain from decision to execution.

Human-in-the-loop should therefore be represented as a real control rather than a user-interface label. For higher-risk actions, the architecture should be able to prove:

1. Which natural person reviewed, approved, rejected, or overrode the action;
2. Which workload proposed and executed it;
3. What information and recommendation were presented to the reviewer;
4. Which capability, target resource, and policy were applied;
5. Whether the person could meaningfully stop or reverse the action.

Advantages

• Strong attribution across human and machine actors.
• Supports separation of duties and approval gates.
• Improves evidence for audit, incident investigation, and regulated oversight.
• Allows policy to reject either an unauthorised user or an unapproved workload.

Limitations

• Token exchange and claim design are more complex than a single-identity flow.
• Not all authorisation servers natively represent actor and subject identities in the same token.
• Human approval can become ceremonial unless the interface provides context, time, and a genuine ability to intervene.
• Storing excessive identity data can create privacy and retention concerns.

MCP authorisation updates that affect enterprise design

The recent MCP SEPs reinforce standard OAuth patterns, but they address different parts of the trust chain. They should not be treated as interchangeable authentication methods.

Protected resource discovery: SEP-985

SEP-985 aligns MCP with RFC 9728. MCP servers should return a WWW-Authenticate challenge containing the protected-resource metadata location, but clients must also fall back to the standard well-known metadata endpoint when the header is absent. This improves deployment flexibility behind gateways and distributed infrastructure.

Enterprise implication: publish reliable protected-resource metadata, use explicit resource indicators, and validate that tokens are intended for the specific MCP server. The benefit is interoperability and less custom configuration; the cost is additional client discovery logic and careful canonical-resource management.

Client registration: SEP-991

SEP-991 makes OAuth Client ID Metadata Documents the preferred registration pattern for clients and servers without a pre-existing relationship, while Dynamic Client Registration becomes optional. A client can use an HTTPS URL as its client identifier and publish its redirect URIs and other metadata at that location.

For open or cross-organisation MCP ecosystems, this creates stable, auditable identifiers without maintaining a registration database. For a closed enterprise environment, pre-registration through the corporate identity platform is still usually the stronger default because it supports explicit ownership, lifecycle controls, and allow-listing.

Advantages include reduced coordination and stable client identity. Risks include metadata-fetch SSRF, trust in external domains, metadata caching, and localhost impersonation. Enterprises should apply domain allow-lists, outbound-fetch controls, response-size limits, caching rules, and visible client identity during authorisation.

Issuer binding: SEP-2468

SEP-2468 proposes using the OAuth authorisation-response issuer parameter defined by RFC 9207 to reduce authorisation mix-up attacks in environments with multiple identity providers.

Where supported, the authorisation server advertises issuer-response support and includes an iss value in success and error responses. The client records the expected issuer before redirecting and rejects a response whose issuer does not match exactly. This is especially valuable in enterprise environments that use several authorisation servers, brokers, or tenant-specific identity providers.

The benefit is strong binding between the authorisation response and the expected issuer using an established OAuth mechanism. The trade-off is stricter callback handling and the possibility that partially upgraded clients or gateways fail until they preserve and validate the iss parameter correctly.

Where authentication should live

The central architectural decision is not only which OAuth flow to use, but where identity translation and policy enforcement occur. A dedicated identity and policy layer can decouple agent applications, workflow engines, authorisation servers, and MCP servers.

Event -> Agent -> Identity and Policy -> Token -> MCP server operation

The application supplies the user identity where relevant, workload identity, requested capability, target resource, execution context, and approval evidence. The identity and policy layer decides which authority model applies, whether delegation is allowed, which workload may exercise it, which audience the token targets, and how long the grant remains valid.

The MCP server should remain comparatively simple: discover or trust the appropriate authorisation server, validate issuer and audience, validate token lifetime and permissions, and enforce the requested operation. It should not need to understand every upstream chat application, agent runtime, or workflow engine.

A practical enterprise selection model is:

Active User, Inherited permissions workload

Action -> User credentials (OIDC) -> Policy -> Operation

Machine workload

Action -> Client credentials (OAuth M2M) -> Policy -> Operation

High Risk/Human in the loop workload

Action -> Client credentials + User credentials -> Policy -> Operation

Recommended enterprise baseline

• Use OAuth 2.1 and OIDC conventions rather than MCP-specific identity mechanisms.
• Issue short-lived, audience-specific tokens for the canonical MCP resource.
• Prefer signed JWT client assertions for confidential machine clients; retain client secrets only where platform support or operational maturity requires them. Option of last resort.
• Keep user identity, workload identity, permission, audience, purpose, and approval evidence distinct.
• Use pre-registration for controlled internal ecosystems and Client ID Metadata Documents for governed cross-organisation or open-client scenarios.
• Support RFC 9728 protected-resource discovery and fallback behaviour.
• Validate the expected authorisation issuer; adopt RFC 9207 issuer-response validation where supported.
• Keep credentials outside prompts, model memory, queues, tool descriptions, and general logs.
• Require meaningful human approval for high-impact actions and log the human and machine roles separately. This is not a formality, it is a core feature of a trust relationship.
• Centralise policy and token translation, but keep enforcement at the MCP resource server.

Conclusion

Authentication in agentic systems should follow the source of authority rather than the convenience of the initial implementation. A user-triggered agent should preserve delegated user context without forwarding the original application token through the architecture. An autonomous agent should use a narrowly scoped workload identity. A regulated or high-impact hybrid workflow should represent both the natural person who supplied or approved the authority and the machine that exercised it.

The recent MCP SEPs do not replace this model. They make it more implementable through standard OAuth discovery, registration, machine credentials, resource binding, and issuer validation. The objective is not to place more identity logic inside the agent. It is to establish a deterministic security boundary around the agent, so that every action has a known initiator, executor, permission, audience, and accountable decision path.

References

MCP SEP-1046: Support OAuth client credentials flow in authorization

MCP SEP-991: Enable URL-based Client Registration using OAuth Client ID Metadata Documents

MCP SEP-985: Align OAuth 2.0 Protected Resource Metadata with RFC 9728

MCP SEP-2468: Recommend Issuer (iss) Parameter in MCP Auth Responses

MCP OAuth Client Credentials extension

MCP Authorization specification (2025–11–25)

Regulation (EU) 2024/1689, especially Articles 12 and 14