Skip to content

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 what an AI client can find 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 what a client can find<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 four places:

  1. Connect time — you can’t create a connection to a blocked connector.
  2. Save time — you can’t save a synthetic-tool step or a toolbox entry that names a blocked tool.
  3. Advertisement — a blocked tool is never offered. A blocked connected tool does not come back from search_tools, which is the only way an MCP client finds a connected tool. A blocked Elaichi catalog operation does not appear in MCP tools/list. Toolbox views hide both the same way.
  4. Execution — a direct call to a blocked tool fails, down to the outbound request Elaichi would have dialled.

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

When someone hits a block

A person stopped by a restriction can ask for access instead of hunting for an admin:

  1. They file a request from the blocked connector card — in the console, or in the card their AI client shows. A short note is optional.
  2. The request lands under Governance → Access requests. Every member sees that tab and their own requests; no permission is needed to file one or to read it back.
  3. Anyone with Manage members (member:manage) sees the whole queue and can approve or decline, with an optional note.
  4. Approving a connector restriction request lifts the restriction it names — for that requester only. Approving any other shape records a decision and grants nothing on its own.

An admin cannot decide their own request. They can withdraw it instead.

See Access requests for the full walkthrough.

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 from what AI clients can reach through MCP — 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, share toolboxes, manage SSO, …).
Restrictions Which connectors/tools they may see or call, even if they have connector:view.
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. People Admin, Team Admin, Member, and Guest 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.