Private and public MCP servers carry fundamentally different threat models. Choosing between them without understanding that distinction is how you end up with sensitive internal tools reachable from the public internet, or with unnecessary operational complexity on top of data that never needed to be isolated in the first place.
This guide breaks down the security architecture of each deployment model, maps the real threats, and explains when each approach fits.
What Private and Public MCP Servers Actually Mean
An MCP server (Model Context Protocol server) is a program that gives an AI agent access to tools, data, and actions. The protocol itself is transport-agnostic. What changes between deployment models is where the server runs, who can reach it, and how clients authenticate.
A public MCP server is reachable over the internet. Any authenticated client can discover and call it. The official Anthropic MCP specification describes remote servers using Streamable HTTP transport, which supports standard bearer token and OAuth authentication. Public deployments include things like the Sentry MCP server, which runs on Sentry’s infrastructure and is accessible to any authorized Sentry user.
A private MCP server runs inside a controlled perimeter. It might be inside a corporate VPC, behind a zero trust overlay, or on-premise. It is not internet-routable. Agents reach it through controlled paths only, typically over outbound-only tunnels or an identity-governed overlay network.
The difference is not just network topology. It determines your entire threat surface.
Threat Model: Public MCP Servers
Public MCP servers face the same threat categories as any internet-facing API, plus several specific to agentic workloads.
Unauthenticated discovery
The MCP architecture specification includes a server/discover method that exposes server capabilities, supported versions, and tool lists. If a public server doesn’t enforce authentication before responding to discovery requests, any actor who finds the endpoint can enumerate every available tool.
This is not a theoretical risk. Public registries of MCP server endpoints already exist, and the protocol’s structured discovery makes automated enumeration straightforward.
Excessive tool scope per token
Public MCP servers often authenticate with a single bearer token or OAuth grant per client. When that token is stolen or an agent is compromised, the attacker inherits everything that token can call. There’s no per-tool authorization layer by default. The OWASP API Security Top 10 flags this pattern explicitly: broken object-level authorization is the leading API vulnerability class.
Prompt injection through tool responses
A compromised or malicious tool on a public server can return content that redirects an AI agent’s behavior. Because agents act on tool output as trusted context, a crafted response can instruct the agent to exfiltrate data, call other tools, or bypass its instructions. Public servers expand this attack surface to any actor who can reach an endpoint.
Lateral movement via tool chaining
Agentic workloads call multiple tools in sequence. On a public server, if the authorization model doesn’t enforce that each step is explicitly permitted, a compromised agent can use one legitimate tool call to escalate access to others on the same server.
Threat Model: Private MCP Servers
Private deployment addresses most of the network-level threats above. But it introduces its own attack surface.
Overprivileged service accounts
Private MCP servers sitting inside a VPC are often reached via shared API keys or service account credentials distributed across multiple agents and pipelines. When any one of those credentials is compromised, the entire server’s tool set is exposed. This is the same problem as public servers, just with a smaller blast radius.
The right answer isn’t a private network. It’s workload identity. Each agent should carry its own cryptographic credential, not a shared secret.
No-auth assumptions inside the perimeter
Teams deploying private servers inside a VPC frequently skip authentication entirely because “it’s only internal.” That logic doesn’t survive a single compromised workload. Once an attacker or a misconfigured agent is inside the network, they can call any unauthenticated internal MCP server without restriction.
NIST SP 800-207, the foundational zero trust standard, is explicit: network location is not authorization. Every request requires authentication and authorization regardless of whether it originates from inside or outside the perimeter.
Inbound ports as persistent exposure
Most private MCP server deployments listen on inbound TCP ports within the VPC. Every listening port is a discoverable service. Lateral movement within a compromised environment means scanning for those ports. The 2026 Verizon Data Breach Investigations Report found that exploitation of reachable internal services accounted for the largest share of post-breach lateral movement.
Operational blind spots
Private servers rarely have request-level logging tied to agent identity. When something goes wrong, you know a tool was called. You don’t know which agent called it, from what context, or what it did next. Auditability is a compliance requirement under PCI-DSS v4.0 and DORA, not a nice-to-have.
The Architecture Decision: When to Use Each Model
Neither model is universally correct. The right answer depends on what the server exposes and who needs access.
| Factor | Public MCP Server | Private MCP Server |
|---|---|---|
| Callers | External users, third-party agents | Internal agents and pipelines only |
| Data sensitivity | Low-sensitivity or pre-scoped context | Internal databases, credentials, regulated data |
| Authentication model | OAuth / bearer token per client | Workload identity (SPIFFE/mTLS preferred) |
| Authorization granularity | Per-client scope | Per-agent, per-tool policy |
| Network exposure | Internet-facing endpoint | No inbound ports; outbound-only tunnel |
| Compliance scope | Standard API security controls | PCI-DSS, HIPAA, DORA, FIPS depending on data |
| Lateral movement risk | Lower (isolated from internal systems) | Higher if auth is skipped or perimeter is flat |
| Operational overhead | Lower (hosted, no tunnel management) | Higher without infrastructure for zero trust overlay |
What Zero Trust Architecture Changes
The cleanest private deployment isn’t a private server behind a VPN. It’s a server with no listening ports at all.
NetFoundry’s Zero Trust AI Enclave approach assigns each MCP server and each calling agent its own cryptographic identity, then uses outbound-only connections through a private overlay. The server never listens for inbound traffic. It dials out to the overlay fabric and waits for authorized agents to connect. From the internet, it’s invisible. From inside your network, it’s unreachable by anything that isn’t explicitly authorized in policy.
This architecture eliminates the core vulnerabilities of both models:
- No listening ports means no discoverable attack surface
- Per-agent identity means a compromised agent can’t impersonate another
- Authenticate-before-connect means no connection is established before authorization completes
- Every tool call is logged by workload identity, not IP address
That last point matters for AI agents specifically. An AI agent’s IP address is typically the address of a cloud region or a shared runner. It tells you nothing. Workload identity tells you exactly which agent instance made the call, from what deployment context, and what it was authorized to do.
For a detailed walkthrough of the tools available to implement this at the cloud workload level, see Zero Trust Tools for Cloud Workloads: A How-To Guide.
Applying This to Real Deployment Decisions
You should use a public MCP server when: the server exposes tools that operate on non-sensitive, externally scoped context; the calling agents are third parties you don’t control; and you can enforce fine-grained OAuth scopes that limit each client to exactly what it needs. Public MCP servers for things like weather data, public search indexes, or documentation retrieval fit this model.
You should use a private MCP server when: the tools access internal databases, credentials, business logic, or anything regulated. The server should also be private if you’re building multi-agent pipelines where one agent’s output feeds another’s inputs, because the blast radius of a compromised agent is harder to contain in a flat network.
The non-negotiables for private deployment:
- Every agent gets a distinct workload identity, not a shared API key
- No listening inbound ports, even inside the VPC
- Authenticate-before-connect enforced at the connection layer, not just the application layer
- Tool-call logging tied to workload identity with timestamps
If you’re evaluating CWPP controls alongside MCP security architecture, the comparison in CWPP vs. Zero Trust Workload Connectivity is a useful frame for understanding where each control fits.
FAQ
What is the difference between a private and public MCP server?
A public MCP server is internet-reachable and serves external agents using standard HTTP authentication (OAuth or bearer tokens). A private MCP server runs inside a controlled network and is accessible only to authorized internal workloads. The key security difference is exposure: public servers face internet-scale threats; private servers face internal lateral movement and overprivilege risks.
Do private MCP servers still need authentication?
Yes. Network location is not authorization. A private server without per-request authentication is fully exposed to any agent or attacker that gains internal network access. Every MCP server, public or private, should require authentication before responding to discovery or tool calls. For private deployments, workload identity (SPIFFE SVIDs or mTLS certificates) is more secure than shared API keys.
What is the MCP architecture?
MCP (Model Context Protocol) follows a client-server architecture where an MCP host (an AI application like Claude Desktop or a custom agent runtime) creates one MCP client per server. Each client maintains a connection to an MCP server that exposes tools, resources, and prompts. Communication uses JSON-RPC 2.0 over either stdio transport (for local servers) or Streamable HTTP (for remote servers). The transport layer handles authentication; the data layer handles the actual tool calls.
Can an AI agent call both public and private MCP servers?
Yes, and this is a common pattern in production agentic systems. An agent might use a public MCP server for external data retrieval (weather, search) while calling a private MCP server for internal business logic. The security challenge is ensuring the agent’s credentials for each server are distinct and scoped, so a compromise of the external path doesn’t expose the internal one.
What authentication does the MCP specification require?
The MCP specification recommends OAuth for remote (HTTP transport) servers and supports bearer tokens and custom headers. For stdio (local) transport, authentication is handled by operating system process isolation. The spec does not mandate a specific implementation, which means deployments range from fully authenticated with scoped tokens to completely unauthenticated, depending on the deployer’s choices.
How does zero trust apply to MCP server security?
Zero trust applied to MCP servers means: every connection is authenticated before any path exists (not just before the tool call is executed), every agent has a unique workload identity rather than sharing credentials, and every tool call is logged with that identity. The zero trust model eliminates the assumption that internal network location implies trust, which is the most common security gap in private MCP deployments.
What is the biggest security risk with public MCP servers?
The biggest risk is overly broad token scope. When a single OAuth token grants access to all tools on a server, theft or misuse of that token gives an attacker everything. The second-largest risk is unauthenticated discovery: servers that respond to server/discover without authentication expose their entire tool surface to enumeration. Mitigating both requires per-client scoped tokens and authentication enforcement before any response.
Sources & References
- MCP Architecture Overview — client-server model, transport types, and protocol primitives
- NIST SP 800-207: Zero Trust Architecture — foundational zero trust principles including the network-location-is-not-authorization requirement
- OWASP API Security Top 10 — broken object-level authorization as the leading API vulnerability class
- MCP Specification: Streamable HTTP Transport and Authorization — authentication requirements for remote MCP servers
- Cloudflare Remote MCP Server Guide — public MCP server deployment patterns and OAuth integration
- NetFoundry Zero Trust AI Enclave — workload identity and outbound-only architecture for private MCP deployments
