/ Enterprise MCP Gateway

Managed vs Self-Hosted: Same Governance, Different Boundary

Governance shouldn't change when your deployment does.

This guide shows how managed and self-hosted deployments keep the same control model while the operating boundary moves to match your trust requirements.

12 chapters · ~4 min read

01

Same Governance, Different Boundary

Managed and self-hosted options differ by operating boundary, not by governance intent.

Same Governance Different Boundary

Why it mattersTeams can reason about deployment without relearning the control model.

02

Same Governance Kit

Identity, policy, credentials, sessions, and audit remain the core kit.

Same Governance Kit

Why it mattersThe same primitives should govern agent access wherever the gateway runs.

03

Managed Runtime, Approved Endpoint

The managed option runs DAC-hosted control plane and runtime paths for approved customer HTTPS endpoints.

Managed Runtime Approved Endpoint

Why it mattersTeams can try governed calls quickly while keeping endpoint registration, policy, credentials, and audit explicit.

04

Customer Endpoint Allowlist

Managed access starts with a customer-owned HTTPS API or HTTPS MCP endpoint that allowlists DAC egress.

Customer Endpoint Allowlist

Why it mattersThe first managed path is deliberate endpoint access, not broad private-network reachability.

05

Managed Scope Boundary

Managed does not mean arbitrary managed MCP server hosting or generic proxying.

Managed Scope Boundary

Why it mattersScope clarity keeps V1 claims credible and helps security teams know exactly what traffic can run.

06

Self-Hosted Everything Inside

In self-hosted mode, control plane, data plane, registry, policy, and audit all live inside the customer boundary.

Self Hosted Everything Inside

Why it mattersSome customers need operational ownership more than managed convenience.

07

Customer-Owned Substrate

Self-hosted deployment can attach to customer-owned Postgres, cache, IdP, secrets, and SIEM systems.

Customer Owned Substrate

Why it mattersEnterprise adoption often depends on fitting into existing platform responsibilities.

08

No Outbound Runtime Dependency

Normal operation can stay local, with telemetry and export under customer control.

No Outbound Runtime Dependency

Why it mattersTrust-boundary decisions are often about runtime dependency, not only data location.

09

The Call Still Gets Governed

Calls still authenticate, evaluate policy, broker credentials, route privately, and emit audit evidence.

The Call Still Gets Governed

Why it mattersDeployment option should not weaken the runtime governance path.

10

API Adapter Stays Bounded

The adapter still exposes selected operations through local checks and upstream status receipts.

API Adapter Stays Bounded

Why it mattersAPI-to-MCP conversion remains bounded even when the gateway is deployed differently.

11

Sessions And Revocation Match

Session ID, affinity, drain, revoke, and audit behavior should match across modes.

Sessions And Revocation Match

Why it mattersOperators need predictable controls when they move from pilot to production.

12

Choose By Operating Boundary

The deployment decision starts with speed, endpoint exposure, operational ownership, and runtime dependency.

Choose By Operating Boundary

Why it mattersManaged and self-hosted are choices about where work runs and who owns the boundary.

Deployment model

Prove governed MCP inside your trust boundary

We are looking for teams who want to prove governed MCP inside their real trust boundary.

The first pilot should choose the boundary deliberately: managed where DAC-hosted runtime and allowlisted endpoints are acceptable, self-hosted where customer-owned runtime and control plane are required. Then connect one approved endpoint or server, run one policy test, and inspect one audit proof.

The goal is not to debate deployment in abstract. It is to test the boundary with a real workflow.

Discuss your deployment
Prove governed MCP inside your trust boundary