Treat MCP as a protocol boundary, not a security conclusion

[
  {
    "id": "transport",
    "check": "Choose the authorization model by transport",
    "evidence": "HTTP authorization conforms to the current MCP authorization specification; STDIO credentials remain environment-scoped rather than copied into the protocol."
  },
  {
    "id": "issuer",
    "check": "Validate the authorization server relationship",
    "evidence": "Approved issuer metadata, exact HTTPS endpoints, key rotation, and failure behavior."
  },
  {
    "id": "audience",
    "check": "Require audience-bound access tokens",
    "evidence": "Server rejects tokens not intended for that MCP server and does not accept upstream API tokens as its own."
  },
  {
    "id": "passthrough",
    "check": "Prohibit token passthrough",
    "evidence": "Separate downstream authorization flow or service credential; adverse test confirms client tokens cannot be relayed to an upstream API."
  },
  {
    "id": "scope",
    "check": "Use progressive least-privilege scopes",
    "evidence": "Initial scope is minimal; step-up is explicit; denied calls are observable; unused privilege can be revoked."
  },
  {
    "id": "client",
    "check": "Bind client identity and redirect behavior",
    "evidence": "Registered client metadata, exact redirects, PKCE/state where applicable, and no open redirect."
  },
  {
    "id": "tool",
    "check": "Authorize the resource and operation, not only the server session",
    "evidence": "Per-tool/resource policy checks include tenant, purpose, amount, environment, and consequence limits."
  },
  {
    "id": "consent",
    "check": "Keep user consent and control explicit",
    "evidence": "User sees the requested capability, scope, destination, and consequence before delegation; revocation remains available."
  },
  {
    "id": "metadata",
    "check": "Treat tool metadata and remote descriptions as untrusted",
    "evidence": "Schema validation, reviewed registry, version pinning, and no policy decisions derived solely from descriptive text."
  },
  {
    "id": "audit",
    "check": "Correlate authorization to effects",
    "evidence": "Trace links principal, client, MCP server, policy decision, tool call, effect verification, expiry, and revocation."
  }
]

Choose the model by transport

MCP authorization is optional at the protocol level. When supported over HTTP, implementations should conform to the current authorization specification. STDIO implementations should obtain credentials from the environment rather than applying the HTTP flow inside the protocol. [S3]

Document the actual deployment: local process, desktop client, remote server, gateway, multi-tenant service, or managed enterprise integration. A copied reference architecture is not a substitute for that boundary.

Validate issuer, client, and audience

Approve exact HTTPS issuer and metadata endpoints, validate signatures and key rotation, bind the client and redirect behavior, and require tokens intended for the specific MCP server. Reject a token whose audience does not identify the server.

If the MCP server calls an upstream API, obtain a separate token or credential appropriate for that upstream resource. Do not forward the client token as a convenience. The current security considerations explicitly prohibit token passthrough and require audience validation. [S4]

Use progressive least privilege

Request the minimum initial scope. Require explicit step-up when a task needs a more sensitive resource or effect. Bind authorization to user or service, tenant, resource, operation, purpose, environment, amount or consequence, and expiry.

A broad server-level session is not enough when one tool reads public metadata and another changes production access or transfers value.

Keep consent understandable and revocable

Before delegation, show which server, tools or resources, scopes, data categories, destination, duration, and consequences are requested. Preserve revocation and make loss of authorization a safe, observable task state.

MCP's core principles emphasize explicit consent, data privacy, tool safety, and user control. Those principles still require a product-specific user experience and policy. [S2]

Treat tool descriptions as untrusted metadata

A remote server describes tool names, schemas, and behavior, but descriptive text is not an authorization policy or assurance. Use an approved registry, version pinning, schema validation, content limits, consequence classification, and change review.

Do not let model reasoning choose a broader scope or higher-consequence tool merely because the remote description says it is necessary.

Authorize and verify each effect

At invocation time, evaluate principal, workload, task, resource, operation, tenant, purpose, amount, environment, and current policy. Record the decision and the exact tool version.

Separate request accepted, operation completed, and business effect verified. Use idempotency and status reconciliation when timeouts or retries create an unknown result.

Protect against confused-deputy paths

Model the MCP client, MCP server, authorization server, upstream APIs, browser or desktop redirect handler, and user as separate actors. Test attacker-controlled endpoints, malicious authorization metadata, open redirects, consent confusion, and a server using one user's authority for another task.

Correlate authorization with operations

The trace should connect principal, client, MCP server, authorization issuer, token audience and scope, policy decision, tool request, response, effect verification, state transition, user or reviewer action, revocation, and stop reason.

Retain minimum structured evidence; do not log access tokens, secrets, or confidential payloads by default.

Reopen review on material change

Reevaluate when the MCP specification, server ownership, issuer, transport, tool, schema, scope, effect class, upstream dependency, data category, or retention behavior changes. The 2026-07-28 specification is current at this page's review date and should be rechecked before consequential deployment. [S1]

This article is implementation guidance, not an authorization-server configuration, security assessment, certification, or legal opinion.