MCP by Default Hold

Overview

MCP by default is the anti-pattern of exposing tools and data through the Model Context Protocol simply because an agent can consume MCP, even when a narrower CLI command, internal API, read-only data export, batch job, webhook, or human approval workflow would be safer. MCP exists for a real reason: Anthropic introduced it as an open standard for connecting AI assistants to systems where data lives, replacing fragmented integrations with a single protocol for data sources and AI tools (Anthropic MCP announcement).

The danger is turning that integration convenience into the default architecture. MCP servers can expose sensitive resources, executable tools, local commands, OAuth flows, and third-party APIs to model-mediated workflows. Official MCP security guidance covers risks including confused deputy attacks, token passthrough, SSRF, session hijacking, local server command execution, transport restrictions, and least-privilege scope design (MCP security best practices). Microsoft also calls out MCP-specific prompt injection and tool poisoning risks, where malicious external content or tool metadata can manipulate an AI system into unintended tool calls or data exfiltration (Microsoft MCP indirect injection guidance).

The reason to classify MCP by default as Hold is that MCP should be an explicit integration decision, not a reflex. Use MCP where reusable agent-tool integration is worth the added security and lifecycle burden. Do not use it as the first answer for every data access, automation, or internal tool exposure problem.

Adoption Signals

• MCP has strong ecosystem momentum because it addresses a common integration problem: AI assistants are constrained when isolated from data sources, and every new data source otherwise requires custom implementation (Anthropic MCP announcement).
• Anthropic positioned MCP as an open standard for secure, two-way connections between data sources and AI-powered tools, with SDKs, Claude Desktop support, and early prebuilt servers for systems such as Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer (Anthropic MCP announcement).
• Official MCP documentation treats authorization as optional in the protocol but strongly recommended when servers access user-specific data, administrative actions, auditable operations, enterprise-controlled resources, rate limits, or user-consent-protected APIs (MCP authorization guidance).
• The security guidance has matured into detailed requirements and mitigations, including per-client consent, exact redirect URI validation, OAuth state validation, token audience validation, HTTPS, secure token storage, and progressive least-privilege scopes (MCP security best practices, MCP authorization guidance).
• Security researchers and vendors are documenting MCP-specific risk patterns such as prompt injection, tool poisoning, mutable tool descriptions, rug-pull attacks, cross-server tool shadowing, and dangerous combinations of private data, untrusted instructions, and exfiltration tools (Microsoft MCP indirect injection guidance, Simon Willison MCP analysis).
• The official best-practices page explicitly calls out local MCP servers as a special risk because they can run commands on a user's machine and may be accessible to other local processes, requiring consent, exact command display, sandboxing, and restricted transports such as stdio or IPC (MCP security best practices).

Risks

• Tool surfaces expand the blast radius. MCP servers expose tools and resources that models can invoke, so publishing broad tool catalogs by default creates more paths for malicious prompts, compromised tool metadata, confused users, or mis-scoped agents to cause harm.
• Prompt injection becomes operational risk. Microsoft describes indirect prompt injection as malicious instructions embedded in external content such as documents, web pages, and emails that can lead to unintended actions including data exfiltration, harmful output, and manipulation of later interactions (Microsoft MCP indirect injection guidance).
• Tool poisoning and rug pulls are hard to see. Tool metadata helps LLMs decide which tools to invoke, and malicious instructions embedded in tool descriptions can manipulate model behavior while remaining invisible to users; tool descriptions can also change after approval in a rug-pull pattern (Microsoft MCP indirect injection guidance, Simon Willison MCP analysis).
• Authorization is non-trivial. Official MCP guidance recommends authorization when handling user data, administrative actions, audit requirements, enterprise access controls, consent-protected APIs, rate limits, or usage tracking, and it calls for short-lived tokens, token validation, HTTPS, least-privilege scopes, secure token storage, and session ID hardening (MCP authorization guidance).
• Confused deputy and token passthrough risks are real. MCP proxy servers must implement per-client consent and avoid accepting tokens not explicitly issued for the MCP server; token passthrough is described as an anti-pattern and explicitly forbidden in the authorization specification (MCP security best practices).
• SSRF can enter through OAuth metadata discovery. MCP clients deployed to servers must consider SSRF when fetching OAuth-related URLs, including risks from internal IP access, cloud metadata endpoints, localhost services, DNS rebinding, and redirect chains (MCP security best practices).
• Local MCP server installation can execute arbitrary commands. If a client supports one-click local MCP server configuration, official guidance says it must show the exact command, clearly identify code execution risk, require explicit approval, and allow cancellation before executing commands (MCP security best practices).
• Human approval must be meaningful. Simon Willison argues MCP clients should treat human-in-the-loop tool denial as mandatory in practice, should show users tool descriptions and tool invocations clearly, and should alert users when tool descriptions change (Simon Willison MCP analysis).
• Supply-chain controls extend to AI integrations. Microsoft recommends verifying all AI components before integration, including models and context providers, maintaining secure deployment pipelines, and implementing continuous application and security monitoring (Microsoft MCP indirect injection guidance).

Recommendation

Hold on MCP-first architecture decisions until the integration need, user journey, threat model, identity model, and governance requirements justify the protocol. Start with the smallest interface that works: a read-only export, constrained API endpoint, CLI command, scheduled batch, webhook, or approval-based workflow may be easier to secure and observe than a general-purpose MCP server.

Use MCP when the benefits are specific and measurable: multiple agent clients need the same integration, the tool surface is stable, authorization and scopes are well-defined, human approval is feasible, and the server has an owner responsible for updates, logging, monitoring, incident response, and deprecation. Prefer read-only tools first, add write actions only with explicit approval and idempotency, and avoid exposing raw admin APIs or broad filesystem, network, database, or messaging capabilities.

Before putting an MCP server into production, require a security review covering tool inventory, consent UI, token audience validation, OAuth flow, redirect URI matching, SSRF controls, local execution model, transport restrictions, least-privilege scopes, prompt-injection handling, tool-description change detection, logging, rate limiting, package provenance, and rollback. Move from Hold only when MCP is the right integration abstraction rather than a default because agents support it.

Sources

• Anthropic MCP announcement
• MCP security best practices
• MCP authorization guidance
• Microsoft MCP indirect injection guidance
• Simon Willison MCP analysis