How Enterprise IT Should Govern MCP Servers and Agents

Model Context Protocol gives enterprise IT something integrations never had: an inventory. Every capability an agent can use passes through a server that can be registered, classified, and permissioned. That inventory only exists if someone governs it, and governance only works if it is split correctly between the platform team, the system owners, and security. This guide gives the model. It applies the architecture in the Model Context Protocol for the enterprise whitepaper and the organizational frame of the AI governance framework.

Who owns what?

Responsibility	Platform team	System owners	Security
Gateway, registry, test harness, versions	Owns	Uses	Reviews
Server build and operation	Supports with templates	Owns	Reviews consequential tools
Identity, credentials, delegation	Implements	Configures per server	Owns policy
Tool classification	Defines the scheme	Classifies each tool	Approves consequential
Third-party vetting	Runs the process	Requests	Owns criteria
Incident response	Operates kill switches	Fixes servers	Leads investigation
Reporting	Produces metrics	Contributes	Reviews

No single team can govern MCP alone: the platform team does not know the systems, system owners do not own security policy, and security cannot build.

What is the server lifecycle?

Stage	Gate	Proportionality
Proposal	Named owner; system identified; tool list with classifications	Same for all
Build	Thin over existing API; schemas reviewed; scoped principals per tool	Lighter for read-only
Test	Contract tests; injection tests; abuse cases and end-state tests for writes	Deeper for consequential
Publish	Registry entry; gateway permissions; documentation; on-call owner	Security sign-off for consequential
Operate	Monitoring; version currency; access reviews	Ongoing
Retire	Identity revoked; credentials invalidated; history archived	Same for all

Read-only servers should move through the lifecycle quickly, because slow governance for low-risk servers is how teams end up bypassing it. Consequential tools deserve the rigor.

What does the registry contain?

For each server: owner and on-call path; the system wrapped; each tool with its classification, principal, and gate; agents permitted to use it; protocol and library versions; test status; and publication and review dates. The registry is the security inventory, the audit evidence, and the source the gateway routes from. A server not in the registry cannot be reached through the gateway, which is the enforcement mechanism.

What is the classification policy?

Class	Definition	Permission	Gate	Testing
Read	Returns data; changes nothing	Read-only principal	None	Contract
Reversible write	Creates or updates correctable records	Scoped writer	Sampling; confirmation for new agents	Contract, abuse cases
Consequential write	Irreversible, high-value, or regulated	Separate principal, withheld by default	Human approval	Contract, abuse, injection, end-state

Classification is decided by the system owner and approved by security for consequential tools. Design guidance is in how to design tool permissions for AI agents.

How should review gates work?

Review should be proportionate and fast. A read-only server over a documented API needs a checklist review by the platform team, usually same week. A server with reversible writes adds a security look at principals and sampling. A server with consequential tools gets a security review of permissions, gates, and tests, and an end-state test demonstration. Publishing the criteria in advance lets teams self-assess and shortens the queue.

How do you make the sanctioned path the easy path?

1. Provide server templates that embed the design standard.
2. Provide the test harness so contract and injection tests are a command, not a project.
3. Make registry entry self-service with review triggered automatically.
4. Route only registered servers through the gateway.
5. Scan periodically for servers reachable outside the gateway.
6. Publish review turnaround targets and meet them.

Teams bypass governance when it is slower than doing it themselves; they comply when it is faster.

What should be reported?

Family	Metrics
Coverage	Systems exposed by class; share of agent-to-system calls through the gateway; bespoke integrations remaining
Control	Servers outside the registry (target zero); consequential tools without gates (target zero); overdue access reviews
Health	Tool-call success and latency per server; incidents; version currency
Velocity	Time from proposal to publication by class; review backlog

Report quarterly to the AI governance body and roll up to the board-level reporting described in the AI oversight for boards whitepaper.

What are the failure modes?

1. Platform team tries to build every server and becomes the bottleneck.
2. Uniform review that treats a read-only knowledge server like a payments tool.
3. Registry as documentation rather than enforcement.
4. No retirement process, so dead servers keep live credentials.
5. Metrics on server counts instead of coverage and control.

How does FISTA Solutions help?

FISTA Solutions is an official Anthropic partner and helps enterprise IT install this governance model as part of its AI enablement practice: the ownership split, lifecycle, registry, classification policy, templates, and test harness, with forward deployed engineers building the first servers to the standard alongside your system owners. Every AI agent FISTA delivers is registered and permissioned through it. FISTA has delivered 150+ projects for 50+ companies across 12+ countries.

To set up governance before the estate grows, message FISTA on WhatsApp, or work through the MCP adoption checklist first.