Skip to main content
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. 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 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 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 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 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 page is a public resource that requires no login and answers the questions those teams typically ask.

Further reading

Gateway Deployment Strategies

Topology decisions that precede sequencing — one gateway versus per-team, per-server, or per-use-case.

Gateway Rules

How rules govern what passes through a gateway and how to configure them.

Teams

How provisioning a gateway to a team grants access, and how access resolves across teams.

Connection experience

What users see when they connect — including the message shown to unprovisioned users.