Field note 07
Connecting Private MCP Servers Without Publishing Them
The Secure MCP Tunnel offers a practical pattern for connecting private tools while keeping the server behind existing network controls.
MCP becomes most interesting when it can reach the tools a team already uses: internal search, build systems, asset catalogs, issue trackers, and data services. Those are also the systems that should not be casually placed on the public internet.
On June 26, OpenAI published a practical answer to that tension. The Secure MCP Tunnel connects a private MCP server to OpenAI products through an outbound connection from infrastructure the customer controls.
What is confirmed
The tunnel client runs inside the customer's environment. It establishes an outbound HTTPS connection and forwards traffic only to an approved local MCP server. The private server remains behind its existing network controls rather than accepting a new public inbound route.
OpenAI's design notes emphasize four principles: outbound connections only, explicit destination configuration, compatibility with MCP streaming and notifications, and an inspectable client that the customer runs. That is a useful security posture because the network boundary stays legible.
The broader MCP security guidance still applies. The protocol's official recommendations warn about confused-deputy problems, token passthrough, server-side request forgery, excessive scopes, and compromised local servers. For local servers, the guidance recommends showing the exact command, asking for explicit consent, sandboxing where possible, and restricting filesystem and network access.
In other words, “private” describes where a server is reachable. It does not make every tool exposed by that server safe.
A simple threat review
Before connecting an MCP server, write down answers to these questions:
- What data can each tool read?
- What can each tool change?
- Which user identity does the server act as?
- Can tool arguments contain URLs or file paths?
- Where are tokens stored, and are they passed to any downstream service?
- Which calls require a human approval?
- What appears in audit logs?
- How can access be revoked quickly?
The answers should be specific. “It can access GitHub” is too broad. “It can read issues in these three repositories and cannot merge or change settings” is reviewable.
My take
MCP servers should be designed like small applications, not like bags of powerful functions. Give tools narrow names. Separate reads from writes. Keep dangerous operations out of generic “run” endpoints. Return enough context that a person can understand an approval without opening another system.
It is also worth starting with a read-only deployment. A search connector can prove its value before it gains permission to create tickets. An asset browser can help people discover files before it gains permission to overwrite them. This makes the first security review smaller and produces real usage evidence for the next one.
The Secure MCP Tunnel solves an important transport problem. Good tool design, minimal permissions, and meaningful approvals solve the trust problem around it.
A rule worth copying
Every MCP tool gets the smallest useful scope, a clear read or write label, and an approval policy before it reaches users.
Sources and further reading
- OpenAI's guide to connecting private MCP servers
- Official MCP security best practices
- Official guidance for building MCP clients
- The MCP server registry