MCP by Default Hold

mcpsecuritygovernanceagent-identitytool-boundariesprompt-injectioncredential-exposureprotocol-governanceagentic-security

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 export, batch job, webhook, or human approval workflow would be safer and easier to govern. MCP itself is no longer speculative infrastructure: it moved to vendor-neutral foundation governance in December 2025, is adopted across major model providers, and now carries the security scrutiny that comes with being the default way agents touch real systems (MCP security landscape). The 2026-07-28 specification went further, replacing the stateful handshake and protocol-level session with a stateless core, header-based routing, cacheable list results, authorization hardening, and tasks (MCP 2026-07-28 specification).

The hold is not generic protocol caution any more. It is specifically about deploying MCP without identity, governance, and tool-boundary controls. The maintainers made a conscious decision that the protocol does not enforce security for you, and the July 28 changes mean the session is no longer the unit of control, pushing enforcement to the request level and to the endpoint (VentureBeat on the new spec). OWASP maps risk across LLM applications, agentic systems, and MCP servers while the spec declines to enforce any of it by design, which leaves enterprises to build the enforcement layer themselves: an inventory that survives constant change, identity lineage from human to tool, authorization checked at every call, and an audit trail that can reconstruct what happened (OWASP MCP risk mapping).

The concrete harm pattern is now documented in CVE records, not just research. In CVE-2026-75130, unsanitized content injected through a Custom AI Instructions feature served via an MCP server let attackers poison instructions, exfiltrate credentials from environment files to an attacker-controlled service, and perform destructive file deletion when the agent made a routine library documentation request (CVE-2026-75130). MCP remains a legitimate integration choice where reusable agent-tool access is worth the identity, governance, and lifecycle burden. It is on hold as an architectural default.

Adoption Signals

  • Adoption is broad and still accelerating: Tier 1 SDKs are seeing close to half a billion downloads a month, with TypeScript and Python each crossing a billion total downloads (MCP 2026-07-28 specification).
  • Production use is real but narrower than headline numbers suggest. The strongest survey source shows 41 percent of software organizations in limited or broad production with MCP servers, replacing an earlier unsourced 78 percent claim (MCP adoption statistics), and other trackers put production use near 45 percent (MCP adoption statistics 2026).
  • Default-by-policy is becoming explicit: 67 percent of surveyed CTOs named MCP their default integration standard for the next 12 months, even though fewer than half of production deployments touch mission-critical customer data (CTO survey data).
  • Governance, not capability, is the bottleneck. Only 11 to 14 percent of enterprise pilots reach production, with identity management, auditability, and vendor lock-in cited as the blockers (Enterprise MCP Guide 2026).
  • Compliance frameworks now name MCP directly. The AIUC-1 Q2 2026 release, effective April 15, 2026, modified 14 requirements and added 23 controls with MCP and A2A protocol security, agent identity and access management, and third-party risk monitoring as its three focus areas, including mandatory controls for MCP and A2A protocol authentication (AIUC-1 Q2 refresh).
  • Standards bodies have published implementation baselines: OWASP GenAI released a practical guide for secure MCP server development (OWASP GenAI MCP baseline), OWASP maintains an MCP governance and risk framework (OWASP MCP Governance and Risk Project), and the NSA published design considerations warning that MCP shipped with a flexible, underspecified design (NSA MCP security design considerations).
  • The ecosystem lags its own spec. A black-box probe of every remote server in the official registry found only 1 of 4,356 reachable servers ready for the 2026-07-28 changes (MCP spec readiness probe).

Risks

  • The protocol does not enforce security, by design. MCP defines how hosts, clients, and servers communicate and how supported HTTP deployments authorize, but protocol compliance alone does not make a deployment secure (MCP security), and the original specification shipped without a mandatory authentication framework under an implicit trust model that assumed servers were benign (MCP security risks and best practices).
  • Agent identity is the missing control plane. The MCP specification provides only a minimal authorization model and lacks guidance on integrating enterprise identity and access control systems (enterprise identity integration for MCP), so enterprises must construct identity lineage from human to tool and check authorization at every call themselves (OWASP MCP risk mapping).
  • Planted prompts become stolen credentials. Poisoned instructions delivered through an MCP server exfiltrated environment-file credentials and deleted files during an ordinary agent request in CVE-2026-75130, classified as improper neutralization of input used for LLM prompting (CVE-2026-75130); the July 28 spec changes shift where those risks compound because the session is no longer the unit of control (VentureBeat on the new spec).
  • Unauthenticated exposure is still the norm at the edge. Roughly four in ten internet-facing MCP servers ship with zero authentication (MCP adoption statistics 2026).
  • Tool surfaces multiply the blast radius. Unit 42 measured a 78.3 percent attack success rate when five MCP servers were connected to a single AI agent, and more than 30 CVEs were filed against MCP servers, clients, and infrastructure between January and February 2026 (OWASP MCP Top 10).
  • The interaction pattern inverts familiar assumptions. MCP often expects servers to query and sometimes execute actions for connected clients, an inversion that makes safe usage ambiguous in an underspecified design (NSA MCP security design considerations).
  • Agent-builder platforms are an active target. CVE-2025-59528, a CVSS 10.0 code injection flaw in the Flowise agent builder, allowed command execution and unrestricted file system access with 12,000 to 15,000 internet-exposed instances, and was the third exploited Flowise vulnerability inside twelve months (Flowise CVSS 10.0 RCE).
  • Existing AI governance frameworks do not cover this yet. MCP replaces static, developer-controlled API integrations with dynamic, user-driven agent systems, producing threats that frameworks such as NIST AI RMF and ISO/IEC 42001 do not address in detail (securing MCP).
  • Upgrade drift creates a mixed-security estate. With almost no registered remote servers ready for the 2026-07-28 spec, organizations will run old and new authorization and routing models side by side for some time (MCP spec readiness probe).

Pros & Cons

Advantages

  • MCP is now genuinely shared infrastructure rather than one vendor's integration format: it moved to vendor-neutral foundation governance in December 2025 and is supported by every major model provider, so a well-built server can serve many agent clients instead of one.
  • The 2026-07-28 specification made MCP far more deployable at enterprise scale, replacing the stateful handshake and protocol-level session with a stateless request/response core, header-based routing, cacheable list results, and authorization hardening, which removes the session-pinning problems that broke cloud-native scaling.
  • Governance material has caught up enough that a disciplined MCP rollout no longer has to be invented from scratch, with OWASP's MCP Top 10, its secure MCP server development guide and governance framework, NSA design considerations, and AIUC-1's dedicated MCP/A2A and agent identity controls all available as review baselines.

Disadvantages

  • Deploying MCP without an identity and authorization layer is now the dominant failure mode: the specification deliberately does not enforce security, its authorization model is minimal and silent on enterprise SSO integration, and roughly four in ten internet-facing MCP servers still ship with no authentication at all.
  • Planted prompts turn directly into credential loss once tool boundaries are loose, as in CVE-2026-75130, where poisoned custom instructions served through the Context7 MCP server exfiltrated credentials from environment files and deleted files during a routine documentation request.
  • Tool surfaces compound rather than add: Unit 42 measured a 78.3 percent attack success rate when five MCP servers were connected to a single agent, and more than 30 CVEs were filed against MCP servers, clients, and infrastructure in January and February 2026 alone.

Recommendation

Hold MCP-first architecture decisions until identity, authorization, and tool boundaries are in place before the first server ships. Start with the smallest interface that works: a read-only export, a constrained API endpoint, a CLI command, a scheduled batch, or an approval-gated workflow is usually easier to secure and observe than a general-purpose MCP server. If the answer is MCP, treat it as a security transition rather than an integration convenience, moving enforcement to the request level and putting controls at the endpoint now that the session is no longer the unit of control (VentureBeat on the new spec).

Build the enforcement layer the protocol declines to provide: a server inventory that survives constant change, identity lineage from the human principal through the agent to the tool call, authorization checked on every call, and an audit trail that can reconstruct what happened (OWASP MCP risk mapping). Integrate MCP servers with existing enterprise identity and access control rather than relying on the spec's minimal authorization model (enterprise identity integration for MCP), and map controls against the OWASP secure MCP server development guide (OWASP GenAI MCP baseline), the OWASP MCP governance framework (OWASP MCP Governance and Risk Project), the OWASP MCP Top 10 (OWASP MCP Top 10), NSA design considerations (NSA MCP security design considerations), and, where relevant to customers, the AIUC-1 MCP/A2A authentication and agent identity controls (AIUC-1 Q2 refresh).

Practically: prefer read-only tools first and gate write actions behind explicit approval; keep the number of servers attached to any one agent small, given the measured success rate when five servers share an agent (OWASP MCP Top 10); never expose a server to the internet without authentication (MCP adoption statistics 2026); treat any tool that reads local files, environment variables, or agent instructions as a credential-exposure path after CVE-2026-75130 (CVE-2026-75130); patch agent-builder platforms as P0 when maximum-severity issues land (Flowise CVSS 10.0 RCE); and plan the 2026-07-28 migration deliberately given how few servers are ready (MCP spec readiness probe). Move off hold only when MCP is a governed platform capability with named owners, not a reflex because agents support it.

Sources

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).

Pros & Cons

Advantages

  • Can accelerate agent integrations when multiple clients need a reusable, standardized way to access the same tools, data sources, or developer systems.
  • Reduces bespoke connector work for legitimate agent-tool use cases by exposing resources and tools through a common protocol with growing ecosystem support.
  • Works well when the integration has a clear threat model, scoped tools, explicit user consent, auditable authorization, and a lifecycle owner for the MCP server.

Disadvantages

  • Exposes tool and data surfaces to model-driven systems, increasing risk from prompt injection, tool poisoning, confused deputy flows, SSRF, session hijacking, and data exfiltration.
  • Adds identity, authorization, consent, scope design, token handling, transport, observability, and supply-chain responsibilities that simpler CLI, API, batch, or human approval flows may avoid.
  • Encourages over-integration when teams publish broad tool catalogs by default instead of applying least privilege, progressive elevation, user approval, and risk-based tool exposure.

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