Your MCP server authenticates users. Does it preserve their permissions?

Two customers connect the same MCP integration to different accounts. Both can sign in. The next test is whether either customer can retrieve the other's records by changing an ID in a tool call.

Authentication identifies the caller. Authorization checks which actions that caller can take. Follow those checks from the client to the MCP server, from the MCP server to the upstream API, and from each API operation to the tenant's records.

Identify the resource receiving the token

The MCP authorization specification requires servers to validate that access tokens were issued for their use. A token intended for some other resource must not become a valid MCP credential merely because its signature can be verified.

Check issuer, intended audience, validity and the required permissions using the authorization server's documented validation method. A signed token and an opaque token may require different validation mechanisms. Do not assume every deployment uses the same token format.

Clients use the OAuth resource parameter to identify the intended protected resource in the flows described by the specification. That resource binding helps keep a credential issued for one service from being accepted by another.

Treat upstream authorization separately

When an MCP server calls another API, it acts as a client of that API. The MCP security best practices prohibit accepting a client token and simply passing it through as an upstream credential.

Use an appropriate upstream credential issued for the downstream resource. Depending on the application, that may involve a user-authorized connection or a deliberately constrained service account. Document whose authority the operation uses and how that connection can be revoked.

A service account with broad access needs application-level authorization before every delegated operation. It is not enough to authenticate the user once and then let arbitrary tool arguments select resources from the entire upstream account.

Bind the tenant on the server

Tenant isolation is application authorization design, not an automatic consequence of MCP. Determine the caller's organization from trusted identity and membership data. Check each target record belongs to an allowed tenant. A caller-supplied organization ID is input to validate, not evidence of membership.

Test the negative paths with two synthetic tenants. Can a user fetch another tenant's known record ID, change the tenant argument, follow a cross-tenant search result, or reuse a cached response? Successful same-tenant tests cannot establish those denials.

Tool availability can reflect scopes and authorization, but hiding a tool does not replace enforcement. Keep checks on the execution path and at the downstream API. A stale client tool list should never grant access that the caller no longer has.

Check revocation and evidence

Define what happens when a user disconnects an account, loses membership or has permissions reduced. Include caches and background jobs in that design. Short token lifetimes can limit exposure, but they do not replace checking current policy where the application requires it.

Log the principal, connection identity, tenant, tool, resource and authorization outcome without recording access tokens. Use correlation identifiers to investigate a request through the layers. Keep denied attempts visible enough to diagnose configuration mistakes and attempted cross-tenant access.