Whose identity an MCP tool should use when it reaches a business system

Up to four identities in a single tool call

A remote MCP call involves the person using the assistant, the client application acting for them, the MCP server and the business system behind it. The current MCP authorization specification, which is optional, covers one hop. For a server protected over HTTP, the client obtains a token for the MCP server, naming the server in the resource parameter, and the server must validate that the token was issued for it. For stdio, the specification says implementations should instead take credentials from the environment, which usually means a credential configured by whoever started the server.

The hop from MCP server to business system is outside what MCP standardises. The specification allows the server to act as an OAuth client to upstream APIs with a separate token from the upstream authorisation server, and forbids passing through the token it received. Nothing in the MCP flow gives the server the user's rights in the business system on its own.

Three options for the downstream call

1. 1

   Delegated consent in the business system

   The user authorises the MCP server through the business system's own OAuth flow. That system's rules decide what is visible, and its audit log names the person. The server must store a token per user and handle expiry and revocation.

2. 2

   Token exchange

   A security token service issues a new token for the business system's audience, as defined in RFC 8693. The RFC separates impersonation, where the server becomes indistinguishable from the user, from delegation, where the server keeps its own identity while acting for the user. Delegation keeps both visible to auditors, if the business system reads it.

3. 3

   Service identity

   The server uses its own credential. This fits scheduled jobs and data that is not user-specific. The business system sees only the service, so the server enforces any per-user rules itself and logs the authenticated service or workflow identity, plus the person who started or authorised the action when there is one. Who owns each workflow is recorded separately.

A worked decision for three hypothetical tools

Here is how the choice might fall for an HR and procurement assistant. The systems and tools are invented for the example.

• get_leave_balance reads one employee's leave data. The HR system already controls who sees whose records, so the tool uses the requester's delegated token. A service identity would force the server to copy HR's visibility rules, and any gap would expose other people's data.
• nightly_supplier_sync updates supplier risk ratings from an external feed. No person is behind the run, so a service identity that may write only those fields is the honest choice, with its own credential and a named owner.
• create_purchase_request uses the requester's delegated token, so approval chains and spending limits apply to the right person. The requester confirms the exact request, and the server or procurement system verifies that confirmation before anything is created.

A mixed outcome is normal. Decide per tool and record the reason next to the tool's definition, where reviewers will look for it.

Token boundaries to verify before launch

• The MCP server rejects tokens issued for any other audience, including valid tokens from your own identity provider meant for another application
• Downstream calls never reuse the inbound token, and each upstream token is requested for that API with the narrowest scopes
• Per-user tokens held by the server are encrypted, keyed by user and issuer, and deleted when the user revokes access or leaves
• Access tokens are short-lived, and refresh tokens issued to public clients are rotated, which the specification requires of authorisation servers
• No token or authorisation code appears in logs, traces or tool output, since the specification treats tokens cached or logged on the server as a theft risk
• Disabling a user in the identity provider ends their access through every tool within a time you have measured

Where enterprise-managed authorisation fits

Many organisations want the identity provider, not each employee, to decide which MCP servers may be used. The official Enterprise-Managed Authorization extension does this: the client obtains an identity assertion grant from the corporate identity provider, which evaluates policy such as group membership, and exchanges it for an access token at the MCP server's authorisation server. Access to MCP servers can then be granted and revoked centrally.

Two limits matter. The extension governs access to the MCP server, not rights inside the systems behind it, so the downstream choice above still has to be made. It also needs explicit client support and is never active by default; the MCP project keeps a community-maintained matrix of client support. For connections with no user at all, a separate official extension covers the OAuth client credentials grant and recommends signed JWT assertions over long-lived client secrets.

A useful next step is a one-page identity map for the first server you plan: each tool, the identity it uses downstream, the reason, and who can revoke it.

MCP server development