There's a moment coming in your company, if it hasn't arrived already.

A developer wires up an AI agent — Claude, Cursor, whatever your team uses — to a Model Context Protocol server. Suddenly the agent can query your production database, read your private repos, hit internal APIs, trigger deployments. Not suggest doing those things. Do them. Autonomously, in response to natural language, often without a human approving each action.

On a laptop, that's a productivity miracle. In production, it's a question nobody in the room can answer: who is allowed to do what, and how would we ever know what happened?

That question is the one this piece is about. Because the answer, for most companies adopting MCP today, is: we have no idea.

The pattern we've seen before

If you've been in infrastructure long enough, this rhymes with something.

A decade ago, microservices arrived the same way. Teams split monoliths apart, called the pieces "services," and shipped. The architecture was exciting; the governance was an afterthought. We spent the next five years retrofitting service meshes, API gateways, identity, and observability onto systems that were never designed to be governed. The cleanup cost more than the migration.

MCP is at the exact same stage microservices were in 2014 — explosive adoption, no governance layer, and a collective decision to worry about security later.

"Later" has a way of arriving as an incident.

The gap, stated plainly

Here is what MCP adoption actually looks like inside most teams right now:

Every developer installs their own MCP servers, with their own credentials, on their own machine. Security has no approved list and no visibility into what's connected. Many of those servers run as local processes — meaning they can't be centrally monitored, shared, revoked, or audited. And when an agent does something — queries a customer table, posts to a channel, runs a command — there is no record of who initiated it, through which identity, or whether it should have been allowed.

This isn't hypothetical. Security researchers recently found roughly 1,800 MCP servers exposed to the public internet. Of the sample they analyzed, every single one accepted unauthenticated requests. Some of those servers connect directly to internal systems that would otherwise never be reachable from outside.

Read that again: tools that can act on internal infrastructure, reachable by anyone, authenticating no one.

Why this is worse than a normal security gap

A normal vulnerability is a door someone might pick. This is different, and worse, in two specific ways.

First, the agent is unpredictable by design. A traditional application does what it was coded to do. An AI agent does what it's persuaded to do. If a developer points an agent at an untrusted web page or an unvetted codebase, an attacker can embed instructions in that content — and the agent, trying to be helpful, may call a real tool with real credentials. The infrastructure did nothing wrong. The agent was simply talked into it. Your firewall has no concept of "the model was tricked."

Second, there's no chain of custody. When the incident review happens — and at scale, it always eventually happens — the question will be: which agent, acting for which person, called which tool, against which system, and was that permitted? If your MCP setup is a pile of local configs, you cannot answer that. Not because you didn't log enough. Because the activity never passed through anywhere that could log it.

This is the part that turns a quiet adoption decision into a board-level risk: by the time you need the audit trail, it's too late to have started keeping one.

What governing this actually requires

Strip away the noise and the requirements are not exotic. They're the same disciplines identity providers brought to applications fifteen years ago — applied, now, to tool calls made by AI.

You need a single point every tool call passes through, instead of dozens of direct, ungoverned connections. You need per-person identity, so every action is attributable and individually revocable — not a shared token that gives everyone the same keys. You need tool-level permissions, so a support engineer's agent can read a ticket but not delete a database. And you need an audit trail of every call — who, what, when, outcome — that exists by default, not as something you scramble to bolt on after the first scare.

Notice what governs this can't be the individual server, and can't be the client. A local server can harden itself but can't prove custody across a team. The client can't reason about what other members are doing. The governance has to live at the layer all the traffic passes through. That's not a feature you add to MCP. It's a layer you put in front of it.

Where this goes

The companies that get this right won't be the ones with the most AI agents. They'll be the ones who can answer, on any given Tuesday, exactly what their agents did and whether it was allowed. That capability is about to separate the teams that scale AI safely from the ones that quietly accumulate risk until it surfaces.

This is the layer we build at mcpnest.io — a governed gateway for MCP, with per-member access, tool-level permissions, hosted infrastructure, and a protocol-level audit log that stores metadata, never payloads, so it's EU-resident and clean by construction. One endpoint your team connects through. Everything attributable. Everything revocable. Everything recorded.

If you're adopting MCP and the questions in this piece made you slightly uncomfortable, that discomfort is the signal. You can scan your own MCP configuration for these exact risks, free and entirely in your browser, at mcpnest.io/scan — nothing leaves your machine.

The microservices generation learned the cost of governing too late. The MCP generation doesn't have to.