What this looks like in practice
The problem
Internal developer platforms let any team stand up a new MCP (Model Context Protocol) server in minutes — and nothing about that speed forces a registration step, a tool-level review, or a logging plan before agents start calling it. The result is dozens of MCP servers running with no central inventory, no consistent authentication pattern, and no way to answer "which agents can reach production data" without asking every team individually.
Internal developer platforms exist to remove friction: a team requests a service, a pipeline provisions it, and within minutes it is reachable. Applied to MCP servers, that same friction removal creates a governance gap. Any team can expose a new set of tools to AI agents — a database query tool, an internal API wrapper, a file-write tool — without a corresponding step that registers who is allowed to call it, which tools within it are safe to expose, or how the calls will be logged. Security and platform teams end up governing only what they can see, and an MCP server stood up outside the standard pipeline is, by definition, not visible. The MCP server security checklist catalogs the specific gaps this pattern tends to leave open.
What good looks like
Good MCP governance on a platform team's terms is a platform-level default, not a manual review queue: every server that comes up through the platform is registered with an identity, scoped to specific tools, and logged the same way regardless of which team built it. Platform teams do not want to review every MCP server by hand, and with the right default, they don't have to.
Enforcement lives at the boundary between agents and servers — where identity is checked and tool calls are authorized — not inside each team's server code, so teams keep shipping without adopting a new framework. This mirrors how authenticating apps and agents against MCP servers already frames the identity half of the problem; the outcome described here is that same boundary enforced consistently across every server on the platform, not configured server by server.
Authorization should be granular enough to separate a server's read tools from its write or destructive tools, because a single MCP server commonly exposes both, and an agent that only needs to search documents should never inherit the ability to modify them — the practice covered in depth in scoping MCP tool permissions. Audit logging should attribute every call to the requesting agent, the team that owns it, and the workflow it ran in, so an incident review does not start with "we don't know which agent did this." And discovery has to run continuously, not just at onboarding, because a server stood up outside the standard pipeline is exactly what shadow MCP server detection exists to catch.
How Praesidia helps
Praesidia provides connection-layer identity, authorization, and audit for MCP servers running behind an internal developer platform, so governance scales with the platform instead of trailing behind it. In practice, that breaks down into five capabilities:
- Non-human identity issued to every MCP server and agent connection, independent of the humans who deployed them.
- Per-tool authorization so a server can expose a read tool without also granting write or destructive tool access.
- Centralized audit logging of every tool call, correlated back to the requesting agent, team, and workflow.
- Policy enforcement at connection time, so a newly registered MCP server inherits guardrails instead of starting ungoverned.
- Cost and rate visibility per server and per agent, independent of which team owns the underlying service.
None of this requires teams to change how they build MCP servers themselves — the controls sit at the connection layer between agents and servers, which is also why they apply retroactively to servers deployed before governance existed.
Getting started
- Inventory what's already running. Discover every MCP server currently reachable by an agent on the platform, including ones stood up outside the standard provisioning pipeline.
- Register each server with its own identity. Move away from shared or implicit trust between agents and servers toward a distinct, attributable identity per server.
- Scope tools, not servers. Split each server's tool set into read versus write/destructive categories and grant access per tool, not per server.
- Apply guardrails and rate limits at the connection. Set policy once at the platform level so it applies automatically to every new connection rather than being configured per team.
- Turn on audit logging before the first incident, not after. Every tool call should be attributable to an agent, a team, and a workflow from day one.
The MCP server governance guide covers the full control set — identity, authorization, and audit — this getting-started path builds toward.
FAQ
Does every team need to change how they build MCP servers? No. Governance is applied at the connection layer between agents and servers, not inside each server's implementation, so teams keep their existing MCP server code and add identity, authorization, and audit at the boundary.
What happens to MCP servers that were deployed before governance was in place? They can be registered and brought under the same identity, authorization, and audit controls retroactively, without redeploying the server itself.
How do we handle an MCP server that exposes both read and destructive tools? Scope authorization per tool, not per server, so an agent granted the read tools does not automatically inherit the destructive ones — the two live under separate grants even though both ship from the same server.