> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Enterprise Strategy & Lockdown
> Where MCP Manager fits in an enterprise AI control stack and the levers admins use to lock it down: funneling all MCP usage through the gateway with client-side connector allowlists, MDM/EDR, and static egress IPs; what MCP Manager governs versus what the endpoint layer controls on the device; the in-platform controls; and a recommended rollout sequence.
**MCP Manager** is the control point for MCP in your organization โ but it is one layer of a defense-in-depth strategy, not the whole thing. A [gateway](/mcp-gateway-concepts/mcp-gateways) governs everything that flows *through* it: identity, which tools are exposed, what data may pass, and a complete audit trail. The job of an enterprise rollout is to make sure MCP traffic actually goes *through* the gateway โ and then to use the controls inside MCP Manager to lock down what happens there. This page covers both halves: where MCP Manager fits in your stack, and the levers admins have.
The in-platform controls below are gated by capabilities (for example **Disable and enable hosts**, **Basic gateway management**, **Manage feature provisioning settings**, **Manage integrations**). Access depends on the capability granted to your role, not on any fixed role name. See the [capabilities reference](/deployment/rbac-and-roles/capabilities).
## Where MCP Manager fits: defense in depth
Think of MCP governance as a stack. MCP Manager is the enforcement and visibility layer in the middle; the layers around it exist to ensure clients can only reach servers *by going through it*.
```mermaid theme={null}
%%{init: {'theme':'base','themeVariables':{'fontFamily':'Lato, sans-serif','lineColor':'#6a6b76','primaryColor':'#e0e2e8','primaryTextColor':'#12141d','primaryBorderColor':'#6a6b76','edgeLabelBackground':'#ffffff','textColor':'#12141d'}}}%%
flowchart TB
subgraph Device["Managed device โ MDM / EDR"]
direction TB
Client["๐ค
AI client (Claude, ChatGPT, Cursor)
admin connector allowlist"]
end
Client -->|"only the MCP Manager gateway URL is allowed"| GW["๐ก๏ธ
MCP Manager gateway
identity ยท tool provisioning ยท rules ยท logging"]
GW -->|"brokered identity, over TLS"| Servers["๐ฅ๏ธ
Your MCP servers"]
classDef gateway fill:#0086ff,color:#ffffff,stroke:#062b4c,stroke-width:2px;
classDef client fill:#80cbc4,color:#062b4c,stroke:#00796b,stroke-width:1.5px;
classDef server fill:#aed8ff,color:#062b4c,stroke:#0b4880,stroke-width:1.5px;
class GW gateway;
class Client client;
class Servers server;
style Device fill:transparent,stroke:#9ca1ab,stroke-dasharray:4 3,color:#6a6b76;
```
* **Endpoint layer (MDM / EDR).** Your device-management and endpoint-protection tooling controls which apps run on managed machines and can allowlist MCP Manager's network traffic.
* **AI client layer (connector allowlists).** Enterprise and team tiers of the major AI clients let an admin restrict which connectors users may add.
* **MCP Manager (the gateway).** The single governed path where identity, tool exposure, content rules, and logging are enforced.
* **Your servers.** Reachable only through the gateway when the layers above are configured to funnel traffic to it.
## Funneling all MCP usage through the gateway
The most common enterprise question is: *what stops a user from just adding their own MCP server directly in their AI client and bypassing the gateway entirely?* MCP Manager governs what passes through it, so the answer is to ensure clients can only reach the gateway. This is done at the layers around MCP Manager:
* **Client-side connector allowlists.** The team and enterprise tiers of clients like Claude, ChatGPT, and Cursor let administrators control which connectors users can add. Allow **only** your MCP Manager gateway URL, and a user can no longer wire up an arbitrary MCP server in that client. (This is how Usercentrics runs internally โ MCP Manager is the only permitted Claude connector.)
* **Endpoint management (MDM / EDR).** Manage which AI clients and configurations are present on company devices, and use EDR allowlisting so only MCP Manager's egress traffic is permitted.
* **Network controls and static egress IPs.** MCP Manager can present **static egress IP addresses**, so you can allowlist its traffic at the firewall and have sensitive upstreams accept connections only from the gateway. [Managed servers](/mcp-gateway-concepts/mcp-servers/managed) can be locked to that static IP directly.
MCP Manager cannot, on its own, stop someone from running an MCP client on an **unmanaged personal device** outside your control โ no gateway product can. That is precisely why the surrounding endpoint and client-allowlist layers matter: together they ensure that on the devices and clients you *do* manage, the gateway is the only path. Treat MCP Manager as the enforcement point, and the client/endpoint controls as what funnels traffic to it.
## What MCP Manager governs on the device โ and what it doesn't
MCP Manager governs the **MCP connection**: which servers and tools an app or agent can reach through the gateway, as whose identity, with what data allowed to pass, and a log of every call. It does **not** control what an AI client does locally on the machine it runs on. When the client is a desktop app โ Claude Desktop, for example โ local behavior such as reading files on disk, accessing the clipboard, or taking screenshots happens on the device, outside any MCP server, so it never traverses the gateway and is not something MCP Manager can see or stop.
Those local behaviors belong to the **endpoint layer** โ your MDM/EDR and OS-level policy, which decide what an app may do on a managed device. The two are complementary: MCP Manager governs everything that flows through MCP, and your device tooling governs what runs on the machine. (Local MCP servers are the exception that proves the rule โ when a tool *is* an MCP server running on the workstation, routing it through a [workstation server](/mcp-gateway-concepts/mcp-servers/workstation) brings it back under the gateway's governance.)
## Lockdown levers inside MCP Manager
Once traffic flows through the gateway, these are the controls admins own directly:
| Lever | What it locks down | Where |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------- |
| **Allowed apps & agents** | Standardize on some clients and block others โ e.g. allow Claude org-wide, block ChatGPT โ and cut off any single agent. | [Apps & Agents](/mcp-gateway-concepts/apps-and-agents) |
| **Teams & roles** | Who can reach which gateway, and what each person is allowed to *do* with it. | [Roles](/deployment/rbac-and-roles/overview) ยท [Teams](/deployment/teams) |
| **Feature provisioning** | Which tools, resources, and prompts a gateway exposes at all โ fail-closed, so only allowlisted capabilities pass. | [Feature Provisioning](/features/feature-provisioning) |
| **Identity scheme per server** | Whether each server uses each user's own identity or a shared service account. | [Identity Controls](/features/identity-controls) |
| **Gateway rules** | What data may flow โ PII redaction, secret blocking, prompt-injection defense. | [Gateway Rules](/features/gateway-rules/overview) |
| **SSO & SCIM** | Centralized sign-in and automatic provisioning/deprovisioning from your IdP. | [SSO](/enterprise/sso) ยท [SCIM](/enterprise/scim) |
| **Break-glass toggles** | Instantly disable an identity, connection, host, server, or gateway during an incident or offboarding. | [Runtime Protections](/security/runtime-protections#break-glass-instant-kill-switches) |
| **Log export to SIEM** | Stream every call to your own observability/SIEM for retention and monitoring. | [Export to SIEM](/enterprise/export-to-siem) |
Together these answer the governance questions an enterprise security review asks: *who* can use *which* tools, as *whose* identity, with *what* data allowed to pass, *provably* logged, and *instantly* revocable.
## A recommended rollout sequence
Stand up one [gateway](/mcp-gateway-concepts/mcp-gateways) with a small set of servers and a pilot team. Start with the picker URL and a simple topology โ see [Gateway Deployment Strategies](/deployment/gateway-deployment-strategies).
In your AI clients' admin settings, restrict connectors to the MCP Manager gateway URL. Reinforce with MDM/EDR on managed devices so the gateway is the only reachable path.
Connect [SSO](/enterprise/sso) so everyone signs in through your IdP, and turn on [SCIM](/enterprise/scim) so team membership โ and deprovisioning โ sync automatically.
Use [feature provisioning](/features/feature-provisioning) to expose only the tools each gateway needs, and add [gateway rules](/features/gateway-rules/overview) for PII and injection on the gateways that handle sensitive data.
Forward logs to your [SIEM](/enterprise/export-to-siem), confirm the audit trail meets your requirements, then expand to more teams โ splitting into per-team or per-use-case gateways as needs diverge.
## Further reading
Choosing a gateway topology โ organization-wide, per team, per server, or per use case.
Allowing some clients and blocking others, and disabling a specific app or agent.
Delegating sign-in to your organization's identity provider.
Automatic user provisioning and deprovisioning from your IdP.
How the gateway path is secured โ encryption, isolation, and static egress IPs.
The permissions behind every lockdown lever on this page.