The MCP server sprawl problem
Two years after the Model Context Protocol shipped, every mid-sized engineering org we work with has the same problem. There is a public MCP registry, a vendor-provided MCP server, an internal MCP server some platform team built last quarter, and a handful of MCP servers that individual engineers spun up because their IDE assistant kept asking for them. Each one of these servers is a small, network-attached process that exposes tools to a language model. Each tool is a function the model can call. Each call can read data, write data, or trigger an external action.
Security teams have noticed. Some of them have responded by trying to ban MCP servers outright. That approach lasts about three weeks. Engineers who can ship a feature in a day with a well-connected agent are not going back to manual context gathering, and the productivity gap between teams that have MCP access and teams that do not has become impossible to ignore in performance reviews. The realistic question is no longer whether MCP servers belong inside the perimeter. The question is how to keep them under control once they are there.
Why traditional appsec patterns do not fit
The instinct of most security programs is to treat an MCP server like any other internal service. Run a SAST scan, do a pen test, write a threat model, ship it. That works for the server itself but misses the actual risk surface. The dangerous part of an MCP server is not the HTTP layer. It is the set of tools the server exposes, the credentials those tools use, and the prompts that decide when to call them.
Three properties make MCP governance unusually hard. First, tool surfaces drift. A server that exposed five read-only tools last week can quietly add a sixth that writes to a customer database, and the agent will happily call it. Second, the calling identity collapses. By the time a tool runs, the action looks like the MCP server, not the human who triggered the agent or the agent itself. Third, the trust boundary is fuzzy. A model that ingests a malicious document can be coerced into calling a tool with arguments the user never approved. None of these problems are addressed by a one-time security review.
A governance model that respects velocity
The pattern that has worked for the orgs we advise is built around three controls. Each of them adds friction in exactly one place and removes it everywhere else.
The first control is a registry. Every MCP server an engineer wants to use, internal or third-party, has to be registered before an agent can connect to it. Registration is cheap. It captures the server's manifest, the tools it exposes, the categories of data those tools touch, and the team that owns the server. It does not require a long review for low-risk servers. A read-only documentation server can be approved in minutes by a tech lead. A server that touches customer data goes through a heavier review. The point of the registry is not to block work, it is to make the inventory real and queryable.
The second control is scoped credentials. Every registered server gets its own credential, scoped to exactly the resources its declared tools need. A linting MCP server does not get a write-capable token. A deployment MCP server does not get a token that can read the customer database. The scoping is enforced upstream of the server, in the identity provider, so a misbehaving server cannot escalate even if it is compromised. We covered this pattern in detail in scoped-credentials-per-mcp-server-pattern, but the short version is that the blast radius of a single MCP server should be a function of its declared scope, not a function of how much trust the operator decided to give it.
The third control is observability. Every tool call goes through a thin proxy that records who triggered the agent, which model decided to call the tool, what arguments were passed, what was returned, and whether the call was approved or rejected by policy. This log is the difference between an incident you can reconstruct in an hour and an incident that becomes a six-week investigation. Most teams already have the infrastructure for this. What is missing is the discipline to put the proxy in front of every MCP server, including the ones developers spin up locally.
The friction tax, and where to spend it
Security controls have a friction tax. The mistake teams make is paying that tax in the wrong place. If you make every tool call go through a manual approval, agents become useless and engineers route around you. If you let everything through, you have no defense at all. The middle path is to spend the friction at registration time, where it happens once per server, and at policy authoring time, where it happens once per category of action. Runtime stays fast.
Concretely, that means a developer who wants to use a new third-party MCP server fills out a short form, the security team reviews it within a day, and from then on the server is available across the org with the right scope. Adding a new tool to an existing server triggers a smaller drift review, which we cover in mcp-server-capability-drift-detection. Calling a tool at runtime is instant unless policy says otherwise.
The same logic applies to write actions. Most write tools should run without a human in the loop. A small set of irreversible or high-blast-radius actions should require an out-of-band confirmation, the pattern we describe in out-of-band-confirmation-for-irreversible-tool-calls. The trick is to keep that set small. If everything requires confirmation, nothing does, because users learn to click through.
What to measure
A governance model that you cannot measure is a governance model you cannot defend. The four numbers that matter are the count of registered servers versus the count of servers actually being called, the median time from registration request to approval, the percentage of tool calls that have a complete audit record, and the number of policy denials per week. The first number tells you whether your registry is real or theatrical. The second tells you whether the friction tax is acceptable. The third tells you whether your observability layer has gaps. The fourth tells you whether your policies are doing anything.
When all four numbers are healthy, you have something that is rare in this space. You have an MCP program that engineers actually use, that security can defend in front of an auditor, and that does not require a heroic effort to keep running. That is the goal. Not zero risk, but a known and bounded risk that the org can live with.
How Safeguard Helps
Safeguard treats MCP governance as a first-class workflow rather than a bolt-on. The platform discovers MCP servers across your environment, inventories every tool they expose, and tracks capability changes over time so drift is caught before it reaches production. Scoped credentials, runtime policy gates, and a complete tool-call audit log are wired in by default, and the same policies that gate your supply chain also gate your agents. Engineering teams keep the velocity that makes MCP worth using, and security teams get a defensible record of every action an agent has taken.