Skip to content

Set connector and tool restrictions

Restrictions are allow or block rules over connectors and individual tools. They apply everywhere those tools appear — the catalog, toolboxes, and anything an AI client reaches through MCP.

Where to find it: Governance → Restrictions

You need the Manage restrictions permission (restriction:manage) to create or edit rules. Creating a member-level override also needs Override restrictions (restriction:override).

They’re the safety net for agent access: even if a tool is already in a toolbox, a block keeps it out of tools/list and fails a direct call.

Targets and precedence

Rules apply to a role or a member (user). There is no separate “organization” target in the UI — the org default is simply no restriction, which means everything is allowed until a role or member rule says otherwise.

Target Who it covers Permission to write
Role Everyone who holds that role restriction:manage
Member One person — replaces their role-level rules entirely restriction:manage and restriction:override

Precedence: member override → role rules → org default (allow all).

Restriction precedence 
flowchart TD
  Check["Tool or connector access check"] --> Member{"Member override<br/>exists?"}
  Member -->|Yes| UseMember["Use that member's rules only"]
  Member -->|No| Role{"Role rules<br/>exist?"}
  Role -->|Yes| UseRole["Merge role allow/block rules"]
  Role -->|No| Default["Org default<br/>allow all"]
  UseMember --> Block{"Blocked?"}
  UseRole --> Block
  Default --> Block
  Block -->|Yes| Deny["Hidden from tools/list<br/>and refused at call time"]
  Block -->|No| Allow["Available"]

A member-level restriction is the escape hatch: it fully replaces role-targeted rules for that person (it doesn’t layer on top). Within the winning layer, multiple rules merge as:

  • Allow rules: union (anything allowed by any allow rule passes the allowlist stage).
  • Block rules: union (anything blocked by any block rule is blocked). Blocks always win over allows.
  • If the winning layer has no allow-mode rule, there is no allowlist stage — everything passes it, then blocks still apply.

Modes

Mode Meaning
Allow list Allow only the selected connectors and/or tools.
Block list Block the selected connectors and/or tools; everything else remains available (subject to other rules).

What you can restrict

Scope How you set it Effect
Whole connectors Search and tick connectors on the rule Connector-level allow or block.
Specific tools Expand Restrict specific tools, pick a connector, tick tools Tool-level allow or block (shown as connector_slug/tool_name).
Every connector Leave all connectors unselected The rule’s mode applies broadly (with any tool picks you add).

Leave connectors unselected when you intend the rule to apply across the catalog, then optionally narrow with specific tools.

Where enforcement happens

Restrictions are checked in three places:

  1. Connect time — you can’t create a connection to a blocked connector.
  2. Advertisement — blocked tools never appear in MCP tools/list (or equivalent toolbox views).
  3. Execution — a direct call to a blocked tool fails.

This applies to both public catalog connectors and your organization’s custom connectors. Restrictions hide or refuse access — they don’t delete existing connections.

Create a restriction

  1. Open Governance → Restrictions.
  2. Create a new restriction.
  3. Under Applies to, choose Role or Member, then pick the specific role or person.
  4. Choose Allow list or Block list.
  5. Select connectors (or leave them empty for a broad rule).
  6. Optionally open Restrict specific tools and pick individual tools.
  7. Save. The rule takes effect immediately.

You'll know it worked when: For people covered by the rule, blocked connectors can’t be connected and blocked tools disappear from toolboxes and MCP servers — even where they were already added.

Edit or delete

Open a rule from the list to change its target, mode, or selections. Delete rules you no longer need — removal is immediate.

How this fits with roles and sharing

Layer Controls
Roles Which actions someone may take (invite, create MCP servers, manage SSO, …).
Restrictions Which connectors/tools they may see or call, even if they have connector:read.
Sharing Whether they can view, use, or edit a particular toolbox or custom connector.

Someone needs the permission and any required share and to clear restrictions before a tool is usable through MCP.

Tip

Start with role-level block lists for sensitive write tools (delete, send, export). Use member overrides sparingly — they replace the role layer for that person, so they need restriction:override on purpose.

Good to know

  • Built-in Org Owner and Org Admin include both restriction:manage and restriction:override. Team Admin, Member, and Viewer do not.
  • Empty connector selection means “apply this restriction broadly,” not “do nothing.”
  • Changing a role’s restriction affects everyone who holds that role right away.