MCP server authorization for downstream access

In enterprise MCP deployments, authentication and authorization at the MCP server don’t fully determine downstream authorization. The server still has to reach downstream systems with the right credential, the right scope and clear attribution. That’s where much of the enterprise risk and complexity shows up. 

Current enterprise MCP deployments often handle downstream authorization with broad user credentials, per-server logic or shared service accounts. While those patterns work in local or single-user setups, they break down when a single MCP server must operate across multiple users and backend systems with varying identity and access models. The practical near-term solution is a generalized authorization layer that translates identity, enforces policy and preserves least privilege on the way to downstream access. 

Key takeaways

• In the context of an MCP server, authentication determines whether a user can connect to the server and authorization establishes which tools the user can use downstream.
• In current MCP deployments, the hard problem is how the server reaches downstream systems with the right authorization context.
• Shared credentials weaken least privilege, erase attribution and create high-value service tokens.
• Human approval prompts are not a reliable control mechanism for downstream authorization. 
• For most enterprises, the practical direction now is a generalized authnz layer above the server, paired with separate identity patterns for humans and agents. 
• Longer term, workload-specific identity becomes more relevant as agents need machine identity provisioned at machine scale.

On this page

• Authentication vs. authorization
• MCP server authorization in current deployments
  • The risk of the shared-credential pattern
  • Identity passthrough across backend systems
  • Human-in-the-loop isn’t a reliable control mechanism
• How Stacklok approaches MCP authorization
  • Now: A generalized auth layer and separate identity patterns
  • Later: Workload-specific, provable identity
• Backend authorization patterns enterprises can deploy today
• FAQ

Authentication vs. authorization

In the context of an MCP server, authentication determines whether a user can connect to the server. Authorization establishes which tools the user can use downstream.

Consider a shared Google Drive MCP server across an enterprise. Both a CEO and an intern can authenticate through the client and reach the same server, which shows that the authentication step is working as intended. It doesn’t determine what the server’s allowed to do when it starts calling Google Drive on either user’s behalf. 

If backend access is handled with a broad shared credential or a user token with open-ended permissions, the downstream system doesn’t have a reliable basis for treating requests from the CEO and the intern differently. The intern could end up with access to documents that should only be available to finance or leadership. That’s an authorization failure.

MCP server authorization in current deployments

In an enterprise setting, there are two authorization paths. One runs from the client to the MCP server, and the other runs from the server to the backend system it accesses. The problem is that different MCP servers connect to different backend systems, each with their own identity and access patterns. A client can acquire an OAuth token and present it to the server. That still leaves the question of how that MCP server should reach its downstream system with the right credential.

Right now, the common pattern is either straight-shot MCP passthrough or organizations building their own authorization into each server. Those servers are usually built around a single-tenant model: one server, one user and one credential, often running locally. That model breaks down when a server has to support multiple users in shared infrastructure. It also doesn’t translate well to environments where users aren’t installing and running MCP servers locally. 

In shared infrastructure, identity context and authorization still have to be handled somewhere. The usual fallback is broad passthrough, authorization logic built into each server or a single credential for everybody to use. In current deployments, that often leaves three recurring failure points: shared credentials, weak downstream identity context and too much reliance on user approval at runtime. 

The risk of the shared-credential pattern

Using a single credential for everybody is the weakest implementation pattern because it usually takes the form of a shared service account. That creates two problems. It becomes difficult to tell on whose behalf the server is calling a downstream API, and teams often give the account broad access so it works across users and tasks. That makes the tokens high-value targets, and the chain of attribution disappears because the service account becomes the only visible identity. 

Identity passthrough across backend systems

Identity passthrough means carrying enough identity context across the MCP server boundary into the backend system. In the simplest form, the credential presented to the server is forwarded to the backend system. For that to work, the MCP server has to accept a token meant for the target service. That immediately creates a token-audience problem because each component should only accept a token meant for that component.

It also weakens attribution. On the backend side, the system may just see a user token for a target service, typically acquired by the client application, without a clear audit trail showing that the request came through a specific server on the user’s behalf. The harder requirement is preserving enough identity context for the backend system to receive a credential it can evaluate, with privileges scoped to the current task and attribution preserved to the user the agent is acting on behalf of. That quickly gets complicated because cloud providers like AWS, databases and SaaS applications all support different access patterns. An OAuth token presented to the MCP server might enter a federation or token-exchange flow on one backend, while another backend supports an entirely different authentication model. 

Human-in-the-loop isn’t a reliable control mechanism

When downstream authorization is too broad or too loosely scoped, teams often fall back to human approval prompts in the client. That looks like a safety layer, but it’s not a reliable control mechanism. After enough harmless actions, people get desensitized; they stop reading closely and start approving out of habit. Relying on humans for their behavior is a non-starter. Agents have to be set up with credentials and privileges scoped precisely to the task they’re expected to accomplish, and no more.

How Stacklok approaches MCP authorization

Taken together, these problems show that enterprises need a more consistent way to handle authentication, authorization and identity across MCP deployments. 

Now: A generalized auth layer and separate identity patterns

Stacklok’s approach is to move those controls out of individual servers and handle them in a way that works across shared infrastructure.

• Separate authentication and authorization from server implementation: That gives enterprises a framework they can use to authenticate requests, apply additional authorization policies and translate requests into backend credentials with the right privileges across different servers and backend systems. 
• Separate identity patterns for humans and agents: Make the agent visible in the request path while keeping the originating user in scope for attribution and policy. In practice, that requires:
  • Delegated auditability: An agent identity model built around delegated credentials. In this configuration, the request is clearly coming from an agent, not a human directly, but it still preserves attribution to the originating user.
  • Descoped tokens: The token is distinct, the privileges are descoped to the task and the system can apply additional authorization policies with the knowledge that the caller is an agent. That creates a cleaner basis for least privilege, attribution and policy enforcement across the full execution path. 

For most enterprises, that’s currently the practical direction. It lets teams work with the identity providers and backend systems they already run without falling back to broad passthrough or open-ended user permissions, while leaving room for a more explicit workload identity model over time. 

Later: Workload-specific, provable identity

A longer-term direction is a workload identity model built around workload-specific, cryptographically verifiable credentials. Frameworks like SPIFFE are examples of that approach. They’re useful in environments where agents need machine identity provisioned dynamically, since agents are created, run and retired at a much higher rate than human users. 

Backend authorization patterns enterprises can deploy today

In the rest of this series, we’ll look at the main backend authorization patterns enterprises can deploy today: GitHub for direct external OAuth, AWS for federated identity and token exchange, and Atlassian and Google Docs for SaaS APIs that need user-specific upstream access and internal services for generic token-exchange flows.

We’ll start with GitHub because it’s familiar, relatively simple to set up and removes the shared-credential pattern immediately.