Developer using laptop illustrating multi-tenant OAuth permission and token checks for AI agents

A remote Model Context Protocol (MCP) tool can feel like a simple function call from an AI assistant, but its security boundary is closer to a web API. The server may read documents, query customer records, or initiate actions, so the access token presented to it must belong to the intended resource and represent the correct client, user and authorization context. Successful login by itself is not proof of safe authorization.

The MCP authorization specification dated July 28, 2026 describes authorization for HTTP-based MCP servers. Separately, IETF RFC 9728, OAuth 2.0 Protected Resource Metadata, defines how protected APIs can communicate authorization-server information and related metadata. Together they give implementation teams a useful architecture; they do not eliminate the need to test the actual tenant and resource isolation in a deployment.

Start with the correct transport and trust boundaries

Document whether the tool connection is a local stdio process or a remote HTTP server. OAuth authorization applies to the remote HTTP deployment pattern, not indiscriminately to every locally launched tool process. Draw the boundaries between AI client, browser or login interface, authorization server, MCP resource server, downstream APIs and tenant data. A request that crosses two of these boundaries may require a distinct credential even when the user sees only one assistant conversation.

Record ownership of each secret and token. Browser-facing client code should not contain confidential server credentials. Access tokens should not appear in analytics URLs, ordinary application logs or prompt text. Authentication establishes an identity and permission context; the resource server must still enforce what tools and records the identity may touch.

Bind access tokens to the intended resource

Check token validity, expiry, issuer, expected audience or resource indicator, scopes and any other relevant authorization claims at the MCP server. Do not accept an otherwise valid token merely because it was signed by a trusted issuer; a token intended for another API can otherwise become a confused-deputy path. The MCP specification’s resource-indicator requirements help ensure that an authorization request designates the resource the token is meant to protect.

For multi-service systems, use a separate resource identifier for each protected API where appropriate. If one service calls another, do not blindly forward the incoming access token downstream. Obtain or exchange credentials only through a documented trusted flow with scope and audience appropriate to that destination. Failure should produce a controlled authorization response, not a silent fallback to a broadly privileged service account.

Publish and validate resource metadata

Implement protected resource metadata at the server according to the relevant MCP and OAuth standards, then test what a client learns from that metadata. The metadata must identify the correct protected resource and supported authorization servers, and it must not be based on arbitrary untrusted host headers. The specification and RFC 9728 are primary references for endpoint discovery and expected properties.

Test configuration drift deliberately: wrong metadata URL, removed issuer, rotated signing keys, an invalid resource URL, and authorization attempts against a different environment. A deployment that works only with a developer’s hard-coded authorization endpoint has not demonstrated interoperability. In systems with several tenants or regions, metadata routing must not leak an authentication session from one customer environment into another.

Make scopes and tenant checks explicit at tool execution

A token can be legitimate while a proposed tool action is still unauthorized. Maintain a server-side table connecting each MCP tool with its minimum authorization requirements. Read-only search, personal-document export, organization-wide reporting and write actions should not all share the same generic permission. When a user belongs to multiple tenants, establish the active tenant from verified context rather than from a free-form model instruction.

For a tool that retrieves a customer report, enforce access at the record-query layer as well as the MCP route. For a write tool, check the exact target object before executing it. Prevent a prompt, tool argument or retrieved document from changing the tenant ID used for authorization. These checks remain necessary even when the AI assistant already filtered which tools to show in its interface.

Build negative tests before the first production release

Construct a matrix of denied cases: missing token, expired token, unknown issuer, valid token for another resource, insufficient scope, disabled account, user removed from tenant, wrong tenant target, revoked entitlement and replayed request after logout. For every case, assert that no downstream action occurs. Do not stop at checking an HTTP status code: verify databases and outbound queues did not change as a side effect.

Include a normal authorized case and a read-only case to catch overly strict implementations. Rotate signing keys in a staging exercise. Compare logs with real execution traces while suppressing token strings and customer content. Every new MCP tool should inherit a standard authorization test suite, not a one-time reviewer checklist that becomes stale when tool definitions change.

Operate the boundary with accountable observability

For each tool invocation, record a request identifier, verified authorization-server identity, resource identifier, tenant, tool name, required permission, decision and outcome. Avoid capturing tokens or sensitive arguments as debugging shortcuts. Monitor unusual patterns such as repeated wrong-audience tokens, unexpected cross-tenant access attempts or an agent rapidly invoking privileged tools after a document retrieval.

An incident plan should specify how to disable an exposed client, revoke access, rotate secrets and reconstruct attempted tool side effects. Security owners should review actual authorization denials alongside new tool releases. The practical engineering measure is simple: a valid token for the wrong resource or tenant must never become a successful operation, no matter how persuasive the model’s generated arguments appear.

Sources

Featured photo: Shamin Haky / Unsplash.