Skip to content

Set connector and tool restrictions

A restriction is an allow rule or a block rule over connectors and individual tools. It applies everywhere those tools appear: the connector catalog, toolboxes, and anything an AI client reaches through MCP. Restrictions are your safety net for agent access. Even when a tool is already in a toolbox, a block keeps it out of what an AI client can find and makes a direct call fail.

Where to find it: Governance → Restrictions

The video shows the whole flow with Stripe and Claude as the example: open New restriction, apply it to the Member role, choose Block list, add Stripe, tick only Create a coupon, and see a teammate's Claude refused with a button to ask an admin for access (checked October 2026).

Before you start

Requirement Detail
Plan Your plan must include restrictions (Gold or Black). Without it, the form says restrictions are not in your plan.
restriction:view See the list of restrictions.
restriction:manage Create, edit and delete a rule that targets a role.
restriction:override Also needed, together with restriction:manage, to create or change a rule that targets a member.

Built-in Org Owner and Org Admin include all three permissions. Auditor includes restriction:view only. People Admin, Team Admin, Member and Guest include none of them.

How restrictions combine

A rule applies to a role or to a member. There is no separate "organization" target. The organization default is simply no restriction, so everything is allowed until a role rule or a member rule says otherwise.

Target Who it covers Permission to write it
Role Everyone who holds that role. restriction:manage
Member One person. restriction:manage and restriction:override

Each member is governed by two layers at the same time: the rules for their role, and the rules written for them personally. A connector or tool is available only when both layers allow it.

Two layers: both must allow 
flowchart TD
  Check["Tool or connector access check"] --> RoleLayer{"Role layer<br/>allows it?"}
  RoleLayer -->|No| Deny["Hidden from what a client can find<br/>and refused at call time"]
  RoleLayer -->|Yes| MemberLayer{"Member layer<br/>allows it?"}
  MemberLayer -->|No| Deny
  MemberLayer -->|Yes| Allow["Available"]

In words: Elaichi checks the member's role rules, then the member's own rules. A block in either layer stops access. A layer with no rules allows everything.

A member's own rules can only narrow what their role allows. They never lift a role rule. If a member has their own allow list, that list is a second allow list, and the member must pass both lists.

Inside one layer, several rules combine like this:

  • Allow rules add together. Anything that any allow rule allows passes the allow-list stage.
  • Block rules add together. Anything that any block rule blocks is blocked. A block always beats an allow.
  • A layer with no allow rule has no allow-list stage. Everything passes that stage, and the block rules still apply.
Info

Older member rules may show a Legacy override badge. Before role and member rules combined, any rule for a member replaced all of their role's rules. Elaichi kept such rules working that way, so converting them would not change anyone's access. Open the rule and choose Apply role restrictions to this member to move that member onto the two-layer model. You cannot undo that choice, but it only narrows access.

Modes

Mode What it means
Allow list Only the connectors and tools you choose can be used. Everything else is blocked.
Block list The connectors and tools you choose cannot be used. Everything else stays available, subject to other rules.

An existing Exception rule may appear in the list. Earlier versions of Elaichi used exceptions to lift one role rule for one member. You can view or delete an exception, but you can no longer create or edit one. Approving an access request now does that job (see Access requests).

What you can restrict

What How you choose it Effect
A whole connector Add the connector and keep its scope as All tools. The mode applies to every tool on the connector.
Specific tools Add the connector, set its scope to Specific tools…, then tick the tools. The mode applies to those tools only. They appear as connector_slug/tool_name.

A rule can name up to 1,000 connectors.

A rule that names no connector and no tool does not apply "broadly":

  • An empty block list rule has no effect. Elaichi asks you to pick at least one connector.
  • An empty allow list rule allows nothing, so it blocks every connector and tool for its target. Elaichi asks you to confirm before it saves.

Create a restriction

  1. Open Governance → Restrictions and choose New restriction.
  2. Under Applies to, choose Role or Member, then pick the role or the person.
  3. Choose Allow list or Block list.
  4. Under Add connectors, search for connectors and add them.
  5. For each connector, keep All tools, or choose Specific tools… and tick the tools.
  6. Check the What this rule does summary, then choose Create restriction.

The rule takes effect within about a minute. You will know it worked when blocked connectors cannot be connected for the people the rule covers, and blocked tools disappear from toolboxes and from what AI clients can reach, even where they were already added.

Edit or delete a restriction

  1. Open Governance → Restrictions.
  2. Open a rule, or use its row menu.
  3. To change the rule, edit the target, mode or selections, then choose Save changes. To remove it, choose Delete.

A change or a deletion takes effect within about a minute. Deleting a rule does not delete any connection. It removes only the limit. You can create the rule again if you change your mind.

Changing a rule for a role affects everyone who holds that role.

Where Elaichi enforces restrictions

Elaichi checks restrictions in four places:

  1. Connect time. You cannot create a connection to a blocked connector.
  2. Save time. You cannot save a synthetic tool step or a toolbox entry that names a blocked tool.
  3. Advertisement. Elaichi never offers a blocked tool. 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 the MCP tools/list. Toolbox views hide both the same way.
  4. Execution. A direct call to a blocked tool fails, even at the point where Elaichi would send the outbound request.

Restrictions apply to both public catalog connectors and your organization's custom connectors. They hide or refuse access. They do not delete existing connections.

What happens when someone hits a block

A person who a restriction stops can ask for access instead of searching for an administrator.

  1. They file a request from the blocked connector, in the console or in the card their AI client shows. A short note is optional.
  2. The request appears under Governance → Access requests. Every member sees that tab with their own requests, and filing or reading a request needs no permission.
  3. Anyone with Manage members (member:manage) sees the whole queue and can approve or deny a request, with an optional note.
  4. Approving a request about a connector restriction lifts the restriction it names for that requester only. Approving any other kind of request records a decision and grants nothing on its own.

An administrator cannot decide their own request, but they can withdraw it. See Access requests.

How restrictions fit with roles and sharing

Layer What it controls
Roles Which actions someone may take, such as inviting people, sharing toolboxes or managing SSO.
Restrictions Which connectors and tools someone may see or call, even if they have connector:view.
Sharing Whether someone can view, use or edit a particular toolbox or custom connector.

A tool is usable through MCP only when the person has the permission, and any share it needs, and passes the restrictions.

Tip

Start with role-level block lists for sensitive write tools, such as delete, send and export. Use member rules sparingly. Each one needs restriction:override on purpose.

What to know

  • You cannot create, edit or delete a rule that targets you, if another person's rule currently limits you. Ask another administrator with restriction:manage to make the change.
  • You cannot create, edit or delete a rule that targets a role whose permissions match your own exactly. Ask another administrator whose permissions differ, or the Org Owner.
  • A rule changes access for everyone it covers within about a minute.