# Set connector and tool restrictions

> Source: https://elaichi.ai/docs/guides/governance/set-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).

```mermaid title="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.

:::callout{type="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.

## Related

- [Roles and permissions](/guides/members/roles)
- [Read the audit log](/guides/governance/read-the-audit-log)
- [Connect an account](/guides/connections/connecting-an-account)