Files

T

retoor 251c3dc2ba research: mcp-client-support subject (106 sources, 3 conclusions)

- wire spec: lifecycle, stdio + Streamable HTTP transports, tools,
  utilities, legacy SSE, versioning, changelog (14 Tier 1)
- client ecosystem: Claude Code/VS Code/Cursor/Codex configs,
  mcp-remote, Smithery, registries, Glama (12 Tier 1)
- security/ops: authorization draft, trust model, poisoning,
  rug pulls, production hardening (12 Tier 1) + 68 Tier 2 cards
- conclusions: minimal stdlib client on 2025-11-25, normalizer +
  resolver agent for pasted configs/GitHub URLs, untrusted-until-
  consent trust model; nothing built yet
- audit PASS (14 subjects, 797 sources, 32 conclusions)

2026-10-18 19:23:02 +02:00

4.1 KiB

Raw Blame History

Security Best Practices

Metadata

Field	Value
Institute	Molodetz Institute - Research & Retrieval Division
Subject	mcp-client-support
Document type	Source Dossier
Tier	1
Source title	Security Best Practices
Source URL	https://modelcontextprotocol.io/specification/2025-11-25/basic/security_best_practices
Source publisher / author	MCP specification authors
Source type	standard
Source date (published)	2025-11-25 (version date; no separate publish date stated)
Date researched	2026-10-18
Researched by	tai (agent), model: Claude Sonnet 5, on behalf of retoor
Research method	gather-subagent direct page fetch, parent synthesis from evidence pack
Confidence	High
Status	Active

Summary

The version-dated companion to the spec gives the authoritative client-side control list: per-client consent through a server-owned consent page showing scopes and redirect URI, a ban on token passthrough, client-owned SSRF and authorization-URL validation, one-click local-server spawn consent with sandboxing, and least-privilege scope discipline. It also forbids session-based authentication for servers and requires secure, non-deterministic session IDs.

Key findings

Confused-deputy via proxy: when a proxy uses one static client ID upstream plus DCR downstream plus consent cookies, an attacker can skip consent; mitigation requires "per-client consent" with an "MCP server-owned consent page" that MUST "Display the specific third-party API scopes" and "Show the registered redirect_uri", with consent "Bind to the specific client_id".
"Token passthrough is explicitly forbidden": "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server."
SSRF is a client duty: "MCP clients deployed to a server MUST consider SSRF risks" when fetching resource_metadata, authorization_servers, and token/authorization endpoints; SHOULD enforce HTTPS, block private ranges (10/8, 172.16/12, 192.168/16, 169.254/16 including cloud metadata), validate redirect targets, and consider egress proxies.
Authorization-URL validation: clients "MUST only allow http:// and https:// schemes", "MUST reject javascript:, data:, file:, vbscript:", and "MUST NOT use shell commands... to open URLs".
Local-server consent: "If an MCP client supports one-click local MCP server configuration, it MUST implement proper consent mechanisms": "Show the exact command... without truncation", flag sudo/rm -rf/network operations, "Warn that MCP servers run with the same privileges as the client", and sandbox with minimal privileges.
Scope minimization: "Minimal initial scope set... Incremental elevation via targeted WWW-Authenticate scope challenges"; common mistakes include "Using wildcard or omnibus scopes (*, all, full-access)" and "Treating claimed scopes in token as sufficient without server-side authorization logic".
"MCP Servers MUST NOT use sessions for authentication" and "MUST use secure, non-deterministic session IDs".

Pros / strengths

Most actionable spec-adjacent source: concrete UX content rules, exact blocked IP ranges and URL schemes, exact spawn-consent content.
Correctly assigns SSRF and spawn consent to the client, closing the "somebody else's problem" gap.
The wildcard-scope anti-pattern list gives scope design a reviewable checklist.

Cons / limitations / caveats

Companion guidance, not the normative spec itself; version-dated 2025-11-25 with no separate publish date, so its standing relative to draft revisions needs tracking.
Server-directed rules (no token passthrough, no session auth) are things the client cannot verify, only assume.
Sandboxing is required in principle ("minimal privileges") but no mechanism or platform guidance is given.

Relevance to tai

The authoritative client-side control list for tai: consent UX content rules, SSRF/URL validation, stdio spawn consent plus sandboxing, least-privilege scopes.

Changelog

Date	Change
2026-10-18	Initial dossier created.

4.1 KiB Raw Blame History