> ## 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. # Safe Rollout Sequence > The recommended order for configuring a gateway in MCP Manager before any user connects — so governance is in place before data can move. Security reviewers ask a reasonable question before approving a gateway deployment: at what point does an AI client actually get access to our data, and is there a window where it has more access than we intended? The answer is yes — if you skip ahead — and the sequence below is what closes that window. Configure governance first, then open access. ## What each step exposes Not every setup action opens a data path. This table shows exactly what becomes reachable at each point. | Setup action | What becomes reachable | | ------------------------------------------- | ----------------------------------------------------------- | | Add an MCP server | Nothing — registration only; no connection is made | | Add an identity | Credentials are stored encrypted; no data moves | | Create a gateway | Nothing — until a server is assigned and a client connects | | Assign a server to the gateway | Nothing — until rules are applied and a client connects | | Apply gateway rules | Governance is now in the path of any future connection | | Provision the gateway to a team | Team members *may* now connect — but only after authorizing | | A user connects their client and authorizes | First point at which data can move | ## The recommended order Configure rules **before** you provision the gateway to anyone, including yourself. 1. Add your MCP server(s). 2. Add identities. 3. Create the gateway and assign servers to it. 4. Apply rules to the gateway. 5. Provision the gateway to a small pilot team (see below). 6. Test rule behavior against real tool calls. 7. Widen access when you're satisfied. ## Two clarifications that come up every time **Creating an identity does not move data.** Authorizing a server stores a credential in MCP Manager — nothing is read from the source system until a tool call is made through a gateway. The authorization step is credential storage, not data access. **A gateway appearing in an AI client's connector list does not mean a user can use it.** If a user has not been provisioned — they're not on a team the gateway is assigned to — they'll see a message telling them they don't have access when they try to connect. Appearing in the list and having access are not the same thing. See [Connection experience](/features/connection-experience) for what that flow looks like. ## Pilot before you publish Before sharing the gateway URL broadly: 1. Create a team with two or three admins. See [Teams](/deployment/teams) for how provisioning works. 2. Provision the gateway only to that team. 3. Connect and send real tool calls — ones that should pass and ones that should be blocked. 4. Confirm rule verdicts appear in [Logs](/features/viewing-logs) with the expected outcome and comment. 5. Adjust rules if anything behaves unexpectedly. 6. Add the wider team once the behavior is confirmed. The [Build a team gateway](/tutorials/team-gateway) tutorial walks through this end to end. ## Pre-flight checklist Before sharing the gateway URL with anyone: * [ ] Rules are attached to this gateway — not just created in the rules engine * [ ] Tool allowlist has been reviewed; write-capable tools are intentional * [ ] Identity scheme is chosen per server (per-user or shared) * [ ] At least one real tool call has been made through the gateway and logged * [ ] Logs show rule activity (a verdict was applied, not bypassed) ## For security and procurement reviewers If you need to share a compliance and security reference with InfoSec, Legal, or procurement, the [Security and compliance](/enterprise/security-and-compliance) page is a public resource that requires no login and answers the questions those teams typically ask. ## Further reading Topology decisions that precede sequencing — one gateway versus per-team, per-server, or per-use-case. How rules govern what passes through a gateway and how to configure them. How provisioning a gateway to a team grants access, and how access resolves across teams. What users see when they connect — including the message shown to unprovisioned users.