# Your MCP server knows who called. Does it know what they may do?

Authentication identifies a caller. A safe MCP release still needs resource, issuer, audience, scope and tool-boundary checks.

Published: 2026-11-10 | Updated: 2026-11-10
Author: /init editorial
Method: AI-assisted, source-checked
Canonical: https://init.news/notes/mcp-server-authorization-review/
For: Practical AI builders and small platform teams exposing remote MCP tools to authenticated users or agents.
Question: MCP server authorization security checklist

## The answer

Review an HTTP MCP server as a protected resource. Decide whether authorization applies to the whole server or selected tools, publish the required discovery metadata, validate token issuer and audience, restrict scopes to the actual tool action, and return HTTP 401 before protected execution when authorization is missing. Then test denial paths with the same care as successful calls.

## What you will leave with

A release checklist that connects identity, token validation and tool authority without treating a successful OAuth flow as complete access control.

- Per-server and per-tool authorization are different contracts and should be chosen explicitly.
- Issuer validation, resource audience and scope enforcement protect different boundaries.
- A denied protected call must stop before the tool handler performs the action.

## Choose the boundary before the OAuth flow

The MCP Apps authorization guide describes two patterns. Per-server authorization protects every request to the MCP endpoint. Per-tool authorization allows public tools while requiring authorization for named protected tools. The guide requires authorization enforcement at the HTTP boundary so an unauthorized protected call receives HTTP 401 before it reaches the tool implementation. [1]

Control | Release question
--- | ---
Resource | Which MCP server or endpoint is this token meant to access?
Issuer | Which authorization server minted and signed the token?
Audience | Was the token issued specifically for this protected resource?
Subject | Which user or machine identity does the tool act for?
Scope | What is the smallest permission needed for this action?
Tool check | Does the handler enforce the same authority before side effects?

## Keep credentials bound to their issuer

The July 2026 MCP specification release strengthened authorization guidance. Clients validate the authorization-server issuer before redeeming a code, and client credentials stay bound to the issuer that minted them. The release also moves toward Client ID Metadata Documents rather than treating dynamic registration as the permanent default. [2]

A valid signature alone is not enough. Validate the expected issuer, the resource audience, expiry and required scope. Do not accept a token intended for a different service or pass the received token to an upstream API as a shortcut.

## Test the denial path before the useful tool

- No token returns HTTP 401 with the resource metadata challenge.
- An expired or invalid token returns 401 and performs no protected action.
- A valid token for another audience is rejected.
- A valid identity without the required scope is rejected.
- A permitted call is constrained to the authenticated subject and resource.
- Tool-level defence-in-depth stops the action if the HTTP layer is misconfigured.

## Record the action, not the bearer token

Keep a receipt containing the subject identifier, tool name, resource, scope decision, result and timestamp. Do not log bearer tokens. The receipt should support review without becoming another credential store. If a tool writes, sends, deletes or spends, require an acceptance or confirmation rule appropriate to that consequence.

This checklist is an implementation aid, not a completed security review. No MCP server, identity provider or protected tool was tested for this article.

## Try one thing

Select the highest-consequence remote tool. Write its allowed subject, resource audience, minimum scope and denied cases. Run one valid call and four denial tests: missing token, wrong issuer, wrong audience and insufficient scope. Keep the HTTP response and action receipt.

## Sources

[1] [MCP Apps: Authorization](https://apps.extensions.modelcontextprotocol.io/api/documents/authorization.html): Per-server and per-tool authorization patterns, discovery metadata, token verification, HTTP 401 enforcement and defence in depth.; checked 2026-11-10

[2] [Model Context Protocol: The 2026-07-28 Specification](https://blog.modelcontextprotocol.io/posts/2026-07-28/): Issuer validation, credential isolation, Client ID Metadata Documents and the current authorization hardening direction.; checked 2026-11-10

## Related guides

- https://init.news/notes/mcp-tool-discovery-context-budget/
- https://init.news/notes/agent-handoff-receipts/
- https://init.news/notes/agent-systems-brief-2026-11-06/