“It is behind the VPN” often ends an architecture discussion. For an MCP service, that should start a more specific one.
Imagine an internal reporting server. Employees connect through a private network, and the server holds credentials for a production database. A developer's compromised laptop can reach the same address as the reporting agent.
The firewall sees an allowed connection. The application still needs to distinguish the laptop from the authorized workload.
What each layer actually knows
| Control | What it can establish | What still needs a decision |
|---|---|---|
| Private address or VPN | A caller has a route into the network | Which caller is using the service |
| Network allowlist | A source may establish a connection | Which tool it may invoke |
| Mutual TLS or workload identity | A particular workload connected | Which user it acts for and which actions are allowed |
| Tool authorization | A principal may perform a scoped action | How much damage the service itself can cause if compromised |
A service mesh can authenticate a gateway correctly while all users behind it still collapse into one service account. Preserve workload identity and delegated user identity when both matter to the action.
The Grafana MCP chain and LiteLLM findings show how a service's network position can become a route to more sensitive systems. The linked advisories describe the specific prerequisites; private placement alone does not resolve them.
A short exercise for the team
Choose one sensitive operation, such as reading a report or registering a tool. Try it from an unexpected internal test workload using no application credential.
Then try it with a valid identity that has no permission for that operation. Those are separate tests: the first checks authentication, and the second checks authorization.
Observe downstream requests and changes as well as the response code. An endpoint should not contact a database or start a process before rejecting the caller.
Keep local and shared deployments distinct
A process launched over local stdio may rely on operating-system permissions and its parent process as the access boundary. Moving that service to a shared HTTP listener changes the boundary.
Define who may connect, how each caller is authenticated, and which tools each identity can use. Keep management operations behind stricter controls and make broader interface binding an explicit deployment choice.
A private network remains useful. It narrows reachability and limits lateral movement. Application identity and scoped permissions make that reachable service accountable for the actions it accepts.