Permissions & Consent

Consent principles from the specification

The MCP spec establishes these key principles:

User consent and control

Users must explicitly consent to and understand all data access and operations, and retain control over what data is shared and what actions are taken.

Data privacy

Hosts must obtain explicit consent before exposing user data to servers; resource data must not be transmitted elsewhere without user consent.

Tool safety

Tools represent arbitrary code execution; hosts must obtain explicit user consent before invoking any tool. Tool descriptions are untrusted unless they come from a trusted server.

LLM sampling controls

Users must explicitly approve sampling requests and control what the server can see. (Listed in spec revisions up to 2025-11-25; removed from the 2026-07-28 principles list alongside the deprecation of the Sampling feature.)

Note

The protocol cannot enforce these principles itself — implementors (hosts in particular) SHOULD build robust consent and authorization flows into their applications.

Where consent is enforced

• The host presents consent UIs and enforces decisions — never the server
• Consent should be informed: show which tool, which server, and which arguments
• Typical models: per-call approval, per-session grants, allowlists/denylists, “always allow” for read-only tools

Authorization for remote servers

Authorization is optional in MCP. HTTP-based transports SHOULD use the authorization spec; stdio servers SHOULD NOT — they get credentials from the environment instead.

• HTTP-transported servers use OAuth 2.1 flows
• The MCP server acts as a resource server and the MCP client as an OAuth client; tokens must be issued for that server specifically (audience-bound via RFC 8707 Resource Indicators — the client sends a resource parameter identifying the server)
• Servers must not accept tokens issued for other services and must never forward the client’s token upstream (the token passthrough anti-pattern)
• Discovery uses Protected Resource Metadata (RFC 9728) plus Authorization Server Metadata (RFC 8414) or OpenID Connect Discovery
• Client registration: Client ID Metadata Documents are the preferred mechanism in the current spec; Dynamic Client Registration (RFC 7591) is deprecated but retained for backwards compatibility

sequenceDiagram
participant C as MCP Client
participant AS as Authorization Server
participant S as MCP Server (resource server)
C->>S: Request without token
S-->>C: 401 + WWW-Authenticate (resource_metadata URL)
C->>AS: Authorization + token request (resource = server URI, PKCE)
AS-->>C: Access token (audience = MCP server)
C->>S: Request with Authorization: Bearer token
S->>S: Validate token audience
S-->>C: Result

Audience-bound token flow

Caution

An MCP server must validate that each token was issued for it as the audience — and reject everything else. Accepting and forwarding foreign tokens breaks audit trails and trust boundaries.

Principle of least privilege

• Grant servers only the scopes/credentials they need; use step-up (incremental) scope consent rather than requesting everything upfront
• Prefer read-only credentials when tools only read
• Time-limit and audience-limit tokens (short-lived access tokens; rotated refresh tokens for public clients)
• Scope filesystem access to relevant directories — via tool parameters or server configuration (the older roots primitive served this purpose but is deprecated in the 2026-07-28 revision, and roots were always informational guidance, not an enforced access control)

Key exam points

• Tool invocation always requires host-mediated consent (human-in-the-loop is the recommended default)
• Sampling requires explicit user approval — servers can’t silently use the user’s model
• Audience-bound tokens: an MCP server must reject tokens not issued for it

Check your knowledge

📝 Check your knowledge

1. Which participant is responsible for obtaining user consent?

AThe MCP serverBThe host applicationCThe authorization serverDThe LLM

2. In MCP authorization, which OAuth 2.1 role does the MCP server play?

AAuthorization serverBOAuth clientCResource serverDResource owner

3. Why must an MCP server reject a token that was issued for a different service?

ATokens for other services are always expiredBAccepting foreign tokens enables token passthrough, breaking audit trails and trust boundariesCOAuth 2.1 forbids more than one token per userDThe token would be too large for the Authorization header

4. How does an MCP client ensure a token is audience-bound to a specific server?

ABy including the resource parameter (RFC 8707) with the server's canonical URI in authorization and token requestsBBy hashing the token with the server nameCBy registering the token in the MCP RegistryDBy sending the token in the URL query string

5. How should a stdio-transported MCP server obtain credentials?

AVia the OAuth 2.1 authorization flowBFrom the environment — stdio transports SHOULD NOT use the HTTP authorization specCBy eliciting the user's password through form-mode elicitationDBy reusing the host's tokens

6. Which statement about the roots primitive and least privilege is accurate?

ARoots cryptographically enforce filesystem boundariesBRoots are mandatory for all serversCRoots are informational guidance, not an enforced access control, and are deprecated in the 2026-07-28 revisionDRoots replace OAuth scopes for remote servers