Permit MCP Gateway enterprise deployment

Compare the three deployment models for Permit MCP Gateway and choose where the gateway, the policy decision point (PDP), and the control plane run. This page is for security, platform, and compliance leads who decide whether Model Context Protocol (MCP) traffic can pass through Permit's hosted infrastructure or must stay inside their own network.

Permit MCP Gateway runs in three deployment models:

• Hosted (SaaS): Permit runs the whole stack on *.agent.security.
• Customer-controlled: the gateway and a local PDP run in your network. Permit.io in the cloud stays the control plane.
• Fully on-premises: the whole stack, including the control plane, runs in your environment, with no dependency on Permit's cloud.

Plans

The customer-controlled and fully on-premises models are available on Enterprise plans. Start your evaluation with the hosted gateway. Permit can help you move to a customer-controlled or fully on-premises deployment later.

Deployment models

Aspect	Hosted (SaaS)	Customer-controlled	Fully on-premises
Gateway location	Managed by Permit at *.agent.security	Your virtual private cloud (VPC), data center, or private cloud	Your environment
MCP traffic path	Through Permit's managed infrastructure	Stays in your network	Stays in your network
Authorization decisions	Permit.io Cloud PDP	Local PDP in your environment	Local PDP in your environment
Policy management (control plane)	Permit.io cloud	Permit.io cloud	Control plane in your environment
Audit logs	Permit.io cloud	Your infrastructure and Permit.io (configurable)	Your environment only
TLS certificates	Managed by Permit	Your certificates and PKI	Your certificates and PKI
Private MCP servers	Must be reachable from the internet	Reachable over your private network	Reachable over your private network
Internet connectivity	Required	Required for control plane sync	Not required: supports air-gapped environments
Uptime depends on	Permit infrastructure	Your infrastructure, plus Permit.io for policy updates	Your infrastructure only
Best for	Fast adoption, SaaS workloads, evaluation	Data residency, private MCP servers, local PDP	Air-gapped, classified, and zero-trust environments

How to choose a deployment model

If your requirement is	Choose
Evaluate the gateway, or your MCP servers are SaaS services on the internet	Hosted
Tool call parameters and upstream responses must not pass through a third party	Customer-controlled or fully on-premises
The gateway must reach internal MCP servers that aren't exposed to the internet	Customer-controlled or fully on-premises
Authorization must keep working during an internet outage	Customer-controlled (with cached policy) or fully on-premises
No component may connect outside your network, including policy management	Fully on-premises

What stays the same across all models

All three models run the same gateway software, the same policy engine, and the same authorization logic. The models differ only in where components run and where traffic flows.

• The same relationship-based access control (ReBAC) policy model, with trust levels, consent, and the trust ceiling.
• The same MCP client setup. Users point their MCP client at your gateway URL instead of a *.agent.security URL.
• The same admin dashboard for managing hosts, MCP servers, humans, and agents.
• The same policy inspection and audit log features.

To move policies and users between deployment models, contact your Permit team.

Data residency and compliance

In the hosted deployment, MCP traffic, including tool call parameters and upstream server responses, passes through Permit's managed infrastructure. A self-hosted model fits when you have requirements such as:

• Regulated industries: healthcare, financial services, and government environments where data must not leave approved network boundaries.
• Data residency laws: GDPR, data sovereignty regulations, or contracts that restrict where data is processed.
• Internal policy: a requirement that production traffic stays inside corporate infrastructure.

In the customer-controlled and fully on-premises models, the gateway runs inside your VPC or data center and proxies tool calls directly to upstream MCP servers. MCP traffic doesn't pass through infrastructure outside your network.

Permit.io is HIPAA compliant and SOC 2 Type II attested. The deployment model you choose decides where MCP traffic and audit data live, so review the model with your compliance team against your own requirements.

Network control in self-hosted deployments

When you run the gateway in your own environment, you control the network layer:

• Private MCP servers: proxy tool calls to internal MCP servers that aren't exposed to the internet.
• Network segmentation: place the gateway in a dedicated security zone with controlled ingress and egress.
• VPC peering: reach upstream services over private links instead of the public internet.
• Custom TLS: use your own certificates and public key infrastructure (PKI).
• IP allow-listing: limit which networks can reach the gateway, in addition to application-level authentication.

Local PDP for authorization

The hosted gateway sends each authorization check to the Permit.io Cloud PDP. In customer-controlled and fully on-premises deployments, a PDP runs next to the gateway:

• No round trip to the cloud: the local PDP evaluates each permit.check() call inside your network.
• Resilience: the local PDP keeps its last synced policy, so authorization continues if the connection to Permit.io is interrupted. Policy changes made during the interruption apply after the connection returns.
• Predictable latency: decision latency depends on your local compute, not on calls across regions.

In the customer-controlled model, Permit.io stays the control plane. Open Policy Administration Layer (OPAL) pushes policy changes to your local PDP, so you don't sync policies by hand. In the fully on-premises model, the control plane also runs in your environment. For PDP deployment options, see Deploy a PDP in an on-premises cluster.

Fully on-premises deployment

The fully on-premises deployment runs the entire Permit MCP Gateway stack, including the control plane, in your environment. No component needs to connect to Permit's cloud.

Components in the on-premises package

Component	What it does
Gateway	MCP proxy that enforces authentication and authorization
Consent service	OAuth 2.1 authorization server and consent screens for users
Policy decision point (PDP)	Evaluates permit.check() calls locally
Control plane	Policy management, resource schemas, role assignments, and audit log storage, provided by your self-hosted Permit Platform
Admin dashboard	The gateway management UI, served from your infrastructure
Policy dashboard	Policy inspection, audit logs, and configuration in your self-hosted Permit Platform

To install the gateway on Kubernetes next to your Permit Platform, follow On-prem installation. The installation guide lists each outbound connection the gateway makes.

Air-gapped environments

The fully on-premises deployment runs in air-gapped environments without internet access:

• No required outbound connections: the gateway, PDP, control plane, and supporting services run inside your network boundary. For the full network dependency list for your deployment, contact your Permit team.
• Offline policy management: you create, change, and evaluate policies locally. The on-premises control plane sends changes to the local PDP.
• Offline updates: Permit delivers updates as versioned artifacts, such as container images, that you move into the air-gapped environment through your secure media process. The installer package includes the container images, so the cluster doesn't pull images from the internet.
• Local storage: audit logs, consent records, and session data stay in your infrastructure.

When to choose fully on-premises

• Defense and intelligence: classified environments where systems run in secure enclaves without internet access.
• Critical infrastructure: energy, utilities, and industrial control environments with strict network isolation.
• Government and public sector: agencies that require all components to run inside approved boundaries.
• Healthcare with strict data isolation: environments where policy metadata must also stay inside the compliance boundary.
• Financial institutions with zero-trust mandates: organizations that require every component, including policy management, to run inside their security perimeter.

Enterprise security controls

Enterprise plans add security controls on top of the core gateway features. Availability differs by control, so check the feature availability table before you plan around one.

Control	What it does	Details
Agent Interrogation	Identifies the connecting agent and its declared purpose through the MCP protocol before tools unlock, and detects changes across sessions	Agent Interrogation
Human-in-the-loop approvals	Pauses sensitive tool calls until an admin approves or rejects them	Human-in-the-loop approvals
Time-limited consent	Sets consent windows that expire, such as two weeks for a contractor's agent	Time-limited consent
Agent verification	Compares a connecting agent with its identity and behavior baseline	Agent verification
Session monitoring	Compares an agent's declared intent with its tool calls in a session	Session monitoring
Permission receipts	Exportable audit records of each permission grant	Permission receipts
Intent-based access control	Evaluates an agent's declared purpose against policy before work starts	Intent-based access control

Get started

Permit scopes each enterprise deployment with your team to match your compliance, network, and operations requirements.

• Book a demo to see an enterprise deployment and discuss your architecture.
• Email support@permit.io with compliance or deployment questions.
• Ask questions in the Permit Slack community.

To evaluate before you decide, follow the Permit MCP Gateway quickstart to create a hosted gateway host and connect an MCP client.

Next steps

• Architecture: components, data flows, and authorization sequences.
• On-prem installation: install the gateway in your Kubernetes cluster.
• Advanced features: what each enterprise security control does.