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 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).
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:
- Connect time — you can’t create a connection to a blocked connector.
- Save time — you can’t save a synthetic-tool step or a toolbox entry that names a blocked tool.
- 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 MCPtools/list. Toolbox views hide both the same way. - 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:
- 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.
- 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.
- Anyone with Manage members (
member:manage) sees the whole queue and can approve or decline, with an optional note. - 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
- Open Governance → Restrictions.
- Create a new restriction.
- Under Applies to, choose Role or Member, then pick the specific role or person.
- Choose Allow list or Block list.
- Select connectors (or leave them empty for a broad rule).
- Optionally open Restrict specific tools and pick individual tools.
- 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.
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:manageandrestriction: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.