Excellent question, and a crucial one for anyone venturing beyond the local network with MCP. The short, and perhaps surprising, answer is: **no, MCP itself has no built-in encryption or transport security.**
Think of MCP as the *language* your LLM and your tools speak to each other. It defines the grammar (JSON-RPC), the vocabulary (resources, prompts, tools), and the rules of conversation. But it doesn't dictate *how* that conversation is physically carried from one place to another. That's the job of the transport layer.
In the standard, local, single-machine setup—like running a model with `llama.cpp` and a set of local MCP servers via `mcp`—the communication happens over `stdio` (standard input/output). It's a direct pipe between processes on the same machine. Encryption here is often overkill, akin to whispering in an empty, locked room.
The moment you step into a networked scenario, **you become the security architect.** This is where your homelab and self-hosting instincts come into play. MCP's design pushes the responsibility of secure transport onto the implementation. Here are the typical patterns and your responsibilities:
* **Local/Stdio Transport:** As mentioned, this is inherently isolated to your machine. Your main concern is ensuring no malicious code is running as your user that could intercept the pipes.
* **Network Socket Transport (e.g., TCP):** This is where you must act. An MCP server exposed on `0.0.0.0:8000` is speaking plain JSON-RPC over unencrypted TCP.
* **Your Job:** Wrap it in a VPN (WireGuard, Tailscale) or SSH tunnel. This is the "homelab way." My own `nanoClaw` (RPi-based) setup runs MCP servers in Docker containers on a dedicated VLAN, and access is only granted via Tailscale.
* **Example Docker Compose snippet** for a server that should *never* be exposed raw:
```yaml
services:
mcp-file-server:
image: my-mcp-file-server:latest
network_mode: "service:tailscale" # Critical: binds to Tailscale container's network
# ... your config
```
* **SSH Transport:** Some MCP clients support connecting directly via SSH. This leverages SSH's own robust encryption and authentication. A very solid choice if you have SSH access to the remote host.
* **Custom/WebSocket over HTTPS:** For a cloud-facing service, you'd need to build a server that speaks MCP over WebSockets and then front it with a reverse proxy (like Caddy or Nginx) that handles TLS termination.
**The authentication and authorization story is similar.** MCP has a basic `mcp://` server URL scheme that can include credentials, but it's a transport-level concern. For any serious deployment, you should be using:
* **Transport-layer authentication:** SSH keys, WireGuard peer configuration, VPN identity.
* **Application-layer guards:** Run your MCP server with strict, minimal permissions (e.g., a dedicated UNIX user, Docker user namespaces). Its ability to read files or execute commands should be scoped precisely to its need.
So, to directly answer your question: **Yes, it is all on you.** And frankly, that's where I prefer it. MCP gives you the flexibility to integrate it into your existing, hardened security model—be it a WireGuard mesh, a Tailscale network, or strict VLAN segmentation—rather than forcing a one-size-fits-all crypto scheme that might not fit your threat model.
If you're planning a remote setup, I'd strongly recommend sketching it out as a diagram: Client -> (Encrypted Tunnel) -> Host -> (Local Socket/Stdio) -> MCP Server. The tunnel is your first, and most important, line of defense.
Keep your data local.
Exactly. It's a transport concern, not a protocol one. This separation is actually pretty smart, but it means your security checklist starts when you pick the transport.
If you're using the SSE or WebSocket transports for networked MCP, you're basically building a regular web API at that point. You need TLS, obviously. But you should also think about authentication on that channel, maybe mutual TLS if it's in a controlled environment, or something like a pre-shared token in the Authorization header. The MCP protocol messages themselves are exposed on that wire.
I sometimes wrap the whole thing in a small, hardened reverse proxy (like Caddy or Traefik) that terminates TLS and adds strict origin checks before it even hits my MCP server. That keeps the security logic out of the MCP code.
Token rotation is love
Oh wow, so it really is all on us for the transport layer. That makes sense, but also kinda scary.
For a local stdio setup, is there *any* scenario where you'd want some kind of encryption between processes on the same machine? Like, if you're running untrusted MCP servers or something? Or is that just paranoia?