MCP 工具授權需要在同一決策中考慮請求、token 和工具

MCP tool authorization needs the request, token, and tool in one decision

Model Context Protocol servers increasingly sit between an agent and systems that hold real authority. A single server may expose a harmless search tool beside one that reads mailboxes, changes cloud resources, or submits code. Authentication at the HTTP endpoint answers who sent a request. It does not answer whether this user, on this connection, should be allowed to call this particular tool with these arguments.

The 2026-07-28 MCP specification makes that distinction easier to build into a gateway. Streamable HTTP requests carry Mcp-Method and Mcp-Name headers, and the server must reject a mismatch between those headers and the JSON-RPC body. The method and tool name therefore become inputs to routing and policy. A gateway can inspect them before the request reaches a tool handler, but its decision still needs the authenticated principal, token audience, tenant, and relevant arguments.

Authentication is only the first gate

An HTTP MCP server acts as an OAuth resource server. It should accept access tokens issued for that resource and must not forward a client token to an unrelated API as a shortcut. Token passthrough turns the MCP server into a confused deputy because the upstream service sees a token that was never scoped to the server's authority.

The resource must also track identity through the complete request. A bearer-token check in middleware is useful, but the tool handler still needs enough context to make a resource-level decision. For a document tool, that means checking whether the user can read the document identifier in the arguments. For an email tool, it means checking the mailbox and operation. For a deployment tool, it means checking the environment and the action.

That is why tool names alone make a weak policy language. read_document can be benign for one identifier and sensitive for another. run_command is almost never useful as a single allow-or-deny unit. A policy that says "authenticated users may call every advertised tool" simply moves the authorization problem into the tool implementation, where it is easy to omit from one handler.

Use a per-tool decision record

A workable design records five facts for every call:

The verified user or workload identity.
The token issuer, audience, scopes, and expiry.
The MCP method and exact tool name.
The resource or tenant named by the arguments.
The policy version and decision, including a reason for denial.

Those facts can be logged without storing sensitive arguments in full. Resource identifiers, a coarse argument digest, and a policy decision are usually enough for review. The record supports incident response and gives operators a way to find tools whose authorization rules have never been exercised.

Per-tool controls can live in the server or at a gateway, but they need one source of truth. Duplicate policy in both places will drift when a tool is renamed or a new resource type is added. A gateway rule that matches Mcp-Name should be generated from the same catalog that describes each tool's required scopes and resource checks. A newly published tool without a policy entry should fail closed.

Token audience and consent limit the blast radius

OAuth protected-resource metadata helps clients discover the authorization server for an MCP resource. The metadata does not prove that any token presented later is valid for that resource. The server must validate the token's issuer and audience against its own configuration. RFC 9728 recommends audience-restricted access tokens and Resource Indicators when dynamic clients are involved.

User consent is a separate control for actions with side effects. Consent obtained once during client registration should not automatically authorize every tool added later. A remote write, privilege change, purchase, or external message should have a confirmation step that names the action and target. The host should not treat model-generated text as the user's consent.

Tool descriptions and outputs are also untrusted input. A result can contain instructions that try to influence the next call. The server cannot prevent every downstream prompt injection, but it can constrain the consequence by avoiding broad credentials, enforcing resource scope, and requiring explicit approval for high-impact actions.

Test the decision, not the login page

Authorization tests should cover more than a valid and invalid token. Create users in two tenants and attempt to read each other's resources. Use a valid token with the wrong audience. Call a tool with an identifier from another project. Rename a tool in the catalog and confirm that the old policy no longer grants access. Send conflicting Mcp-Name and JSON-RPC name values and verify rejection.

The operational goal is simple to state. Every call should be attributable, every tool should have a policy, and every policy should have evidence that it denies the cases it is supposed to deny. MCP's new routing headers make the boundary visible. The server still has to make the decision correctly.