The MCP authentication boundary, reviewed
MCP servers authenticate the client (the agent) not the end user. When a user-facing agent invokes an MCP server, the server has no way to enforce per-user authorisation unless authentication is layered in explicitly. This piece maps the gap and the controls.
Authentication is one of the most fundamental security controls in any distributed system. In MCP-connected agent architectures, authentication exists — but it is often authenticating the wrong entity. The MCP server verifies the identity of the client (the agent host) but has no direct relationship with the end user who initiated the agent session. This structural gap is the MCP authentication boundary problem.
It is not a bug. It is the default state of most MCP deployments. And it creates a category of authorization failure that looks like normal operation in every log and every audit trail — because the client is authenticated, the session is valid, and the tool invocations are correctly formed.
This article is part of the MCP security review cluster. It covers the authentication boundary in detail: what the gap is, why it matters for systems that serve multiple users, and the controls that close it.
The authentication gap
In a standard MCP deployment, the authentication model looks like this:
- A user interacts with an AI assistant or agent through a user-facing application.
- The application's agent runtime decides to invoke an MCP tool to complete the user's request.
- The agent runtime (the MCP client) connects to the MCP server and authenticates using its own credentials — an API key, a service account token, or a client certificate.
- The MCP server accepts the connection because the client credentials are valid.
- The MCP server executes the requested tool with whatever permissions the client identity carries.
The user is entirely absent from this authentication chain. The MCP server knows it is talking to a valid MCP client. It does not know — and by default has no mechanism to know — which user's request triggered the tool invocation.
MCP transport modes — auth comparison
| Transport | Auth mechanism | Boundary strength | Attack surface |
|---|---|---|---|
| stdio | None — the OS process model is the trust boundary. The parent process spawns the child; no token exchange occurs. | Strong for process isolation; weak if the parent process has broad OS permissions or the child inherits excess file descriptors. | Local process compromise, excessive filesystem permissions inherited by the subprocess, IPC interception on misconfigured systems. |
| HTTP | Application-layer tokens (API key or Bearer JWT in the Authorization header). TLS secures the channel; the token authenticates the client. | Client identity verified; user identity not verified unless explicitly forwarded. Per-user authorization requires additional design. | Token theft, TLS misconfiguration (disabled certificate validation), credential embedding in code, absent per-user authorization layer. |
| SSE | Same as HTTP for the POST (tool invocation) channel. The persistent SSE stream relies on session continuity after the initial authenticated handshake. | Session hijacking risk on long-lived connections. Same per-user auth gap as HTTP. Connection state must be explicitly managed. | Session fixation on the SSE stream, authentication bypass if the SSE connection is not re-validated after token rotation, per-user auth gap. |
Client auth vs user auth
Client authentication and user authentication address different security questions:
- Client authentication asks: is this a legitimate MCP client that is authorised to connect to this server? It verifies the identity of the software component making the request.
- User authentication asks: which end user is behind this request, and what are they authorised to access? It verifies the identity of the human whose intent the request represents.
Traditional API security addresses both layers. An API gateway verifies that the calling application has a valid API key (client auth) and, for user-facing operations, that the user's session token is valid and that the user has the required permissions (user auth). The two layers are treated as independent and both are enforced.
Most MCP deployments implement client auth only. User auth at the MCP layer requires explicit design — it is not provided by the protocol. In assessed systems, this explicit design is absent more often than it is present.
Why it matters
The authentication gap matters most in multi-user agent deployments — situations where a single agent instance or agent service handles requests from multiple end users. This is the standard architecture for user-facing AI assistants, enterprise chat interfaces backed by MCP tools, and any agent offered as a shared service.
In these deployments, User A and User B both interact with the same agent service. The agent service has a single set of MCP client credentials. When User A asks the agent to retrieve data via an MCP tool, the request runs with the client credentials — which also authorise the same actions for User B. If User A is not supposed to access User B's data, but the MCP server's tools can access any user's data given valid client credentials, the boundary between their data is not enforced.
The downstream services the MCP server calls may have per-user access controls. But if those services accept the MCP server's service account as a valid caller — which they must for the server to function at all — and the MCP server does not pass user context to them, then the downstream access controls cannot enforce per-user boundaries either.
The failure mode
The concrete failure mode: User A accesses an agent that is connected to an MCP server with read access to the organisation's CRM. The MCP server authenticates the agent client. User A asks the agent to look up a customer record. The agent invokes the MCP read-customer tool. The MCP server executes the tool using its service account. The service account can read all customer records. User A receives the result.
User A may not have direct CRM access. They may be a junior employee who would be denied access if they tried to log in to the CRM directly. Through the agent, they can access any customer record the MCP server can reach. The access control policy of the CRM has been effectively bypassed — not by exploiting a vulnerability, but by using the agent as a proxy with a higher-privileged identity.
In most assessed systems with MCP-connected agents, the agent acts as an inadvertent privilege escalation path. Users can access, through the agent, data and capabilities they would be denied if they accessed the underlying service directly. The access control gap is structural, not exploitable in the traditional sense — it is simply the default outcome of deploying MCP without per-user authorization at the MCP layer.
Controls
Three control layers close the MCP authentication boundary gap:
Pass user identity tokens to the MCP server
The agent can include the end user's identity in the MCP request — typically as a header or a parameter attached to the tool invocation. The MCP server reads this identity claim and uses it to scope the tool's behaviour.
This requires that the identity claim is verifiable. The MCP server should not accept unverified user identity assertions from the client — any client could claim to be any user. The claim should be a signed token (a JWT from the organisation's identity provider) that the MCP server can validate independently.
Per-user authorization at the MCP layer
Once the MCP server can verify the end user's identity, it should enforce per-user authorization at the tool level. Each tool handler should check whether the verified user identity is permitted to perform the requested operation. This check should be implemented in the MCP server, not delegated entirely to downstream services — downstream services may not have the context to enforce the policy correctly.
Scope scoping by user context
For tools that access external systems on behalf of users, the MCP server should use the user's own credentials (or a delegated token) when calling those systems, rather than its own service account. This preserves the downstream access control policies of those systems for agent-mediated access — the user can only access, through the agent, what they could access directly.
Review checklist
An AI security review of the MCP authentication boundary should address the following questions and produce corresponding evidence:
- Is client authentication required? Does the MCP server require valid client credentials before accepting any connection or tool invocation? Evidence: auth enforcement test showing unauthenticated connection is rejected.
- Is per-user authentication implemented? Does the MCP server have a mechanism to identify the end user behind a tool invocation? Evidence: review of the authentication architecture showing the user identity flow.
- Is per-user authorization enforced?Does the MCP server restrict tool access based on the verified user identity? Evidence: test showing that a tool invocation with User A's identity cannot access User B's data.
- Are downstream systems called with user-scoped credentials?When the MCP server calls external systems on behalf of a user, does it use the user's credentials or a token derived from them? Evidence: review of the downstream call implementation.
- Are MCP server credentials managed? Are the client credentials the agent uses to authenticate to the MCP server stored securely, rotated on a defined schedule, and not embedded in code? Evidence: credential management policy and rotation record.
For the full MCP security review framework, see MCP security — the four attack surfaces. For the complete checklist, see An MCP server security review checklist.
Blog
Get new posts in your inbox
AI security review, OWASP Agentic Top 10, ISO 42001 evidence, and what AI Committees actually need. No cadence promises — we publish when there's something worth reading.
Assess your MCP authentication boundary with Drel
Drel's AI security review includes a structured assessment of the MCP authentication gap — covering client auth, per-user authorization, and downstream credential scoping — with a defensible evidence pack.
A note on scope: Drel reviews assessed systems against documented architecture, configuration and intent. It does not ingest live telemetry from production environments. Dispositions reflect the assessed system at the time of review and the re-assessment triggers that govern when the disposition must be revisited.