The Model Context Protocol (MCP) has quickly become the standard way to connect AI assistants to enterprise systems. Every major platform vendor now ships MCP support in some form, and every developer on your team can build a server in an afternoon. That speed is the point. It is also why CIOs need a governance model before the connections outnumber the people who understand them.
This playbook distills what we have learned building and reviewing MCP integrations on enterprise platforms, including ServiceNow. It is written for technology leaders who need a practical framework, not a theoretical one.
Part 1: Understand the Three Decisions That Define Risk
Every MCP connection is defined by three architectural choices. Get these right and most of the risk is managed by design.
Where the server runs. Native servers run inside the platform and are typically visible to its governance tooling. External servers run on infrastructure you or a vendor control, and are often invisible to the platform. Neither is wrong, but they require different controls.
Whose identity it uses. A server that acts as the authenticated end user inherits their permissions and produces an audit trail tied to a real person. A server that runs as a shared service account acts with that account's permissions for everyone who uses it. The second pattern is far riskier and should be the exception.
What tools it exposes. The tool list is the contract. A server exposing "query incidents" is a different risk than one exposing "update any record in any table." Tools should be explicit, narrow, and separated into read and write.
Part 2: The Minimum Control Set
We recommend every organization adopt these controls before scaling MCP beyond a pilot:
- Registration. Every MCP server, native or external, is recorded with a named owner, purpose, hosting location, and identity model.
- Explicit allowlists. Tables, endpoints, and operations are enumerated in code or configuration. No wildcards in production.
- Least-privilege credentials. Integration accounts are scoped to exactly the allowlist, never borrowed from another integration and never granted administrative roles.
- Code review for external servers. Changes to tool definitions or allowlists go through a pull request with a named approver. For external servers, this review is your primary governance boundary.
- Environment separation. Development servers never hold production credentials. Promotion follows the same path as any other integration.
- Logging and review. Agent actions are logged with enough context to reconstruct who asked for what. Someone actually reviews those logs on a schedule.
- Decommissioning. Every server has an end condition. Pilots expire. Vendor connections are removed at engagement close.
If you cannot answer who owns an AI connection, what it can touch, and who approved it, you do not govern it. You just hope.
Part 3: Choosing Native or External
Default to native patterns when the platform offers them and they meet the need. You gain automatic inventory, identity inheritance, and alignment with vendor support. Choose external patterns deliberately when you need capabilities the native path cannot provide, such as specific client compatibility, cross-platform tools, or precise code-level control. When you do, compensate with stricter registration and mandatory code review, because the platform will not watch it for you.
Part 4: Ten Questions to Ask Any Vendor
Before a vendor connects AI to your environment, ask:
- Is the MCP server native to our platform or externally hosted? Where?
- Does it act as the end user, or as a service account?
- What is the exact list of tools, tables, and operations it exposes?
- Which of those tools can write, update, or delete data?
- How are credentials stored, rotated, and revoked?
- Will this connection appear in our platform's AI inventory? If not, how will we track it?
- What is logged, where, and for how long?
- Who on your team can change the tool list, and how are we notified?
- What data leaves our environment, and to which model provider?
- How and when will this connection be removed?
A vendor who answers these clearly is a vendor who has thought about governance. A vendor who is surprised by them is a vendor you should slow down.
Part 5: A 90-Day Rollout
Days 1 to 30: Discover. Inventory existing AI connections by reviewing OAuth clients, API keys, and integration users. Interview development teams and vendors. Expect to find more than you thought.
Days 31 to 60: Standardize. Publish the minimum control set, a registration intake, and approved reference patterns for native and external servers. Make the governed path faster than the ungoverned one.
Days 61 to 90: Enforce. Bring discovered connections into compliance or retire them. Add AI connection clauses to vendor contracts. Establish a recurring review cadence.
The Bottom Line
MCP is not a risk to be avoided. It is a capability to be governed. The enterprises that move fastest with AI over the next two years will be the ones that built the guardrails early enough that nobody had to slow down later.
Nya Akoma. Take Heart.