MCP Server Authentication Boundaries: Don't Mix User Identity, Tool Permissions, and Service Credentials

When connecting an MCP Server to a production API, many teams' first instinct is to configure the Server with a highly privileged API key. The demo is soon up and running, but every subsequent call uses the same key: the boundaries around who initiated the call, what it may access, and who is accountable when something goes wrong all disappear. The model, client, Server, and downstream business system do not have the same identity and must be explicitly separated.

Distinguish Four Types of Identity First

A reliable design involves at least four types of principals: the end user, MCP client, MCP Server, and downstream service account. The end user determines business permissions, such as whether they can view a particular project's data; the client represents a registered application; the Server is the intermediary that executes tool calls; and the service account is responsible only for connecting to databases, ticketing systems, or internal APIs. Collapsing all of them into a single bearer token makes least privilege and auditing impossible.

The recommended principle is: use user identity for authorization, client identity for admission control, and service accounts for network connectivity. The Server must not pass off its own service credentials as user identity, nor should it trust an arbitrary tenantId supplied by the client. Every tool call must carry verifiable caller context.

An Executable Call Flow

The request can be divided into the following five steps:

1. The user signs in to the MCP client, which obtains a short-lived user session.
2. When the client establishes a connection to the MCP Server, the Server verifies the client identity, callback URL, and audience.
3. The Server converts the user session into internally verifiable authorization context containing the user ID, tenant, role, allowed scopes, and expiration time.
4. Before executing a tool, it authorizes the operation again based on the tool name and input resource. For example, tickets.read must not automatically grant tickets.write.
5. The Server accesses downstream systems using its own low-privilege service account while writing the authorization context and correlation ID to an audit event.

The third step is critical. Downstream services do not need to trust the original client token or understand the MCP protocol; they only need to verify context issued by the internal identity service. This provides one place to handle tenants, roles, disabled users, and session revocation consistently.

Scopes Must Correspond to Tool Capabilities

Do not define a catch-all mcp:access scope. Split scopes by risk, for example:

repo.read
repo.pull-request.write
incident.read
incident.comment.write
analytics.query
analytics.export

When a tool is registered, it declares its required scopes; the executor checks them again immediately before issuing the downstream request. This way, even if prompt injection tricks the model into calling a high-risk tool, the authorization layer will reject it. Write operations should also require user confirmation or policy approval. Natural language generated by a model must not be treated directly as authorization.

Common Credential-Handling Mistakes

First, do not place long-lived keys in tool arguments, model context, or logs. The model may repeat its context, and debug logs may be visible to a broader group. Second, do not let a public Server use a shared administrator database account. Third, do not make a token valid for as long as the user's login session; executing a tool usually requires only a few minutes of access.

If the Server must access a third-party service on the user's behalf, use an audience-restricted, short-lived, revocable token, and record the tool, resource, and session for which the token was issued. When token exchange fails, return an actionable error such as "The current connection does not have analytics.export permission." Do not return internal keys or the complete upstream response.

Prelaunch Validation Checklist

• Call the same tool as a regular user, an administrator, and a disabled user, and verify that the results differ and are explainable.
• Change the tenantId in the tool input and verify that data cannot be read across tenant boundaries.
• Simulate an expired token, a revoked session, and a downstream service timeout, and verify that the system does not fall back to anonymous privileged access.
• Inspect the logs and verify that they contain no raw tokens, passwords, complete national identification numbers, or exported data.
• Require an explicit scope for every write tool and record who confirmed the operation.

The goal of MCP authentication is not to make calls more complicated, but to ensure that every tool execution can answer three questions: who requested it, why it was allowed, and what it actually accessed. Answering these questions clearly during the design phase prevents security gaps from accumulating as more tools are integrated.

Further Reading

• MCP Protocol Deep Dive
• Core Architecture of AI Agents
• Defending Against Prompt Injection