Enterprise MCP Gateway Deployment Checklist
Deploy an enterprise MCP gateway with phased server admission, tenant isolation, OAuth validation, exact tool policy, bypass tests, rollback and evidence.
An enterprise MCP gateway rollout should begin with inventory and enforced routing, not a company-wide server marketplace. Admit a small set of low-risk read tools, prove tenant and credential isolation, then add consequential actions only after exact-request authorization, replay safety, evidence and rollback tests pass.
The MCP gateway guide defines the platform. This checklist turns it into deployment gates.
Phase 1: inventory and ownership
- Record every MCP host, client, server, endpoint, transport and owner.
- Classify tools as public read, sensitive read, reversible write or material write.
- Identify tokens and secrets currently exposed to hosts, clients or model context.
- Find direct server routes and local STDIO processes that cannot be mediated remotely.
- Create tenant-specific admission records and expiry dates.
Authorization in the MCP specification applies to HTTP transports and is optional across MCP implementations. Do not assume STDIO follows the same control path.
Phase 2: enforced access
- Publish or consume protected-resource metadata under a controlled issuer policy.
- Validate token issuer, audience, expiry and scope at gateway and upstream server.
- Strip caller-provided identity headers and send authenticated upstream context.
- Broker upstream credentials outside model context.
- Block direct network and service routes around the gateway.
- Partition caches, credentials, policy and evidence by tenant.
pilot_policy:
server: finance-readonly
tools: [invoice_lookup, supplier_status]
writes: deny
max_metadata_age: 15m
direct_route: deny
evidence: required
Phase 3: consequential tools
- Validate strict input schemas and reject ambiguous values.
- Bind policy decisions to canonical tool arguments.
- Resolve delegated authority and current business state.
- Bind human approval to the same request digest.
- Claim replay, usage and idempotency records atomically.
- Separate provider acceptance from final outcome.
Run the mutation and bypass cases from MCP gateway security controls. A feature demonstration is not a release test.
Phase 4: failure and rollback
| Failure | Required rehearsal |
|---|---|
| policy bundle unavailable | risk-class behavior matches configuration |
| authorization server unavailable | active sessions and new grants behave as designed |
| replay store loses quorum | material writes stop |
| server metadata changes | admission quarantines or re-review starts |
| evidence exporter fails | local queue or deny rule activates |
| gateway release fails | rollback preserves policy and evidence continuity |
Keep a break-glass path for operators, not an undocumented bypass for agents. Break-glass use needs strong identity, narrow duration, explicit action limits and separate evidence.
Define pilot exit evidence
The pilot should graduate only when the team can show:
- all traffic for in-scope servers uses the gateway;
- wrong-audience and cross-tenant tests fail safely;
- every material tool has an action-specific policy;
- duplicate and timeout behavior is understood;
- an investigator can reconstruct one call across gateway and upstream;
- rollback and revocation complete inside agreed targets.
NIST's AI Risk Management Framework can connect these technical gates to organizational ownership. RFC 9700 supplies OAuth security practices.
Use the open source MCP gateway evaluation before product selection. For a scoped architecture review, contact Intelliger with the first servers, tools and required failure behavior.
Intelliger's public gateway paths are developer-preview references. A production deployment needs independent security review, load testing, operational ownership and environment-specific acceptance.
Deployment review questions
Which servers belong in the first pilot?
Choose a small set with named owners, stable schemas and reversible or read-only operations. Include enough identity and data sensitivity to exercise real controls, but keep irreversible writes out until routing, credential isolation and evidence are proven. A toy weather server may verify connectivity while revealing almost nothing about enterprise readiness.
How should legacy direct access be removed?
Inventory DNS names, load balancers, service accounts, firewall paths and local configuration. Block direct routes using service identity and network policy, then test from the same runtime and subnet as the agent. Monitor attempts after cutover. Keep a human-operated break-glass route if required, with separate credentials, expiry and evidence.
What is the rollback unit?
Define whether you can roll back gateway code, policy bundle, registry snapshot and server admission independently. Preserve compatibility across the rollback window and test it with active sessions. A rollback that restores traffic but loses authorization evidence or accepts an old revoked credential is not safe.
How should teams train operators?
Train them to distinguish access failure, business denial, approval requirement, upstream rejection and uncertain execution. Give each state a runbook and correlation path. If every error looks like "MCP server unavailable," operators will widen scopes or route around the gateway during pressure.
What belongs in the service-level objective?
Measure authorized request latency and availability, but also revocation propagation, policy freshness, evidence export lag and uncertain-action recovery. A highly available proxy with stale authority is not meeting the security objective. Set separate targets by action class so public reads do not mask material-write failures.
When is the pilot complete?
Complete it when acceptance evidence is signed off by business, service, security and operations owners. Require direct-route denial, tenant isolation, protocol fixtures, outage drills, incident reconstruction and a bounded plan for the next action class. Traffic volume alone does not demonstrate that controls work.
Before opening the next server, review what operators changed during the pilot. Temporary scope expansions, disabled response logging, manual registry edits and local credentials often appear while teams debug integration. Either remove them or turn them into reviewed configuration with an owner and expiry. The deployment record should describe the system that will remain after the pilot team leaves, not the cleaner architecture shown at the kickoff.
Freeze that record for the acceptance test, then generate it again from production after cutover. Differences in routes, issuers, scopes, tools and logging settings should be reviewed rather than dismissed as deployment detail.