MCP tool allowlist vs blocklist: which does a role need?
An allowlist suits a role that should reach a short list of apps you can name. A blocklist suits a role that should keep broad reach, minus a few tools you can name. The MCP tool allowlist vs blocklist choice is the first one an admin makes after turning restrictions on in Elaichi, and the two modes are not mirror images.
A restriction in Elaichi is a rule saying which connectors and tools a role or one member may reach. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Each rule has a mode, allow or block, and names whole connectors, single tools, or both, up to 1,000 connectors and 1,000 tools in one rule. All of a role's allow rules merge into one allowlist and all of its block rules into one blocklist. A block always beats an allow.
What an allow rule that names nothing does
It blocks everything. An allow rule turns the allowlist on for its target just by existing, whatever it names. A rule saved with no connectors and no tools therefore denies every connector and every tool to whoever it targets. Elaichi says so in the rule's own summary: "Allows nothing. Every connector and tool is blocked."
This is easy to hit twice. The first way is the placeholder: an admin creates the rule, means to fill in the apps later, and locks the role out in the meantime. The second is the edit: removing the last connector from a working allow rule does the same thing as saving an empty one.
Two things make it survivable. A restriction change takes effect within about two minutes, so the lockout and the fix land on the same clock. And restriction.created, restriction.updated and restriction.deleted go to the audit log, the organization's record of who did what, so a lockout has an author and a time. On what each log shape actually keeps, see what an audit log records.
Why one allow rule reaches further than you meant
An allowlist is not scoped to the apps it mentions. Once a role carries any allow rule, everything its allow rules do not name is blocked for that role. That covers the whole catalog, not only the connectors a rule touches. An allow rule written to hold support to three Zendesk read tools also cuts that role off from Slack, from Notion, from every other app.
The fix is to name the rest. An allow rule naming a connector whole admits every tool on it, and allow rules can be separate rules, because a layer's allow rules merge into one list. So a support role held to three Zendesk tools needs two kinds of rule. One allow rule names those three tools. Further allow rules name, whole, each other app support uses.
One shape is refused outright. A rule cannot name the same connector both whole and in its tool list. Creating such a rule fails with a 400, and so does an edit that introduces the overlap.
Where a blocklist leaves gaps
A layer with only block rules has no allowlist, so everything the blocks do not name passes. Blocking some of an app's write tools leaves every write tool you did not name reachable.
Microsoft Intune makes the gap concrete. On Elaichi's msintune connector, msintune_managed_devices_execute_action stays reachable unless a rule names it, however many wipe and retire tools you blocked one by one. Microsoft's own documentation puts those actions behind one Graph permission: DeviceManagementManagedDevices.PrivilegedOperations.All permits retire, wipe, remote lock and passcode reset on a managed device (Microsoft Learn, checked October 2026). Holding a role to an app's read tools with blocks alone means naming every tool on that app that is not a read. It also means naming the new ones each time the connector grows.
Blocks do have one reach allows lack. A block on a connector also blocks every fork that declares descent from it, walking the lineage toward its root for up to 8 hops. An allow rule naming a connector does not admit its forks; a fork has to be named on the allowlist itself. Lineage only ever adds blocks.
Two layers, and which one your rule lands on
Every member is governed by two sets of rules at once: the rules on their role, and the rules aimed at them personally. A connector or tool is reachable only when both layers admit it. A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule.
There is no third layer: restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. To keep a team off a tool, write the rule on the role its members hold, or on each member in turn.
The permissions follow the same split. Reading restrictions needs restriction:view. Creating, editing or deleting one needs restriction:manage and a plan that includes restrictions, which Gold and Black both do. A rule aimed at a single member also needs restriction:override. Among the built-in roles, Org Owner and Org Admin hold all three, and Auditor holds the view permission alone.
Two guard rails sit on top of that. An admin cannot create, edit or delete a rule aimed at themselves while someone else's rule restricts them. An admin also cannot write a rule aimed at a role whose permissions exactly match their own. Both are refused, with a message asking another admin to make the change.
Which strategy fits which role
Choose per role, not per company. The two modes differ on six questions:
| Question | Allowlist (allow rules) | Blocklist (block rules) |
|---|---|---|
| A tool no rule names | Blocked | Reachable |
| Reach of one rule | The whole catalog, not only the apps it names | Only the connectors and tools it names |
| A tool the connector gains later | Blocked until an allow rule names it | Reachable until a block names it |
| Forks of a named connector | Not admitted; each fork is named separately | Blocked too, up to 8 hops of lineage |
| A rule that names nothing | Blocks every connector and tool for its target | Blocks nothing |
| Holding a role to one app's read tools | Those reads, plus each other app named whole | Every tool on that app that is not a read |
Four common cases follow from that:
- A narrow persona. A contractor, a reviewer, an agency user. Write an allowlist naming the two or three connectors they need. Everything else being blocked is the point, not a side effect.
- A broad persona. Most Members already work across many apps, and the goal is stopping a handful of destructive tools. Block rules naming those tools leave the rest of their work alone.
- Read-only for one app on a role that uses several. Allow the read tools on that app, then allow each other app whole. Blocks alone leave the gap Intune shows.
- One tool, one role, obvious risk. A single block rule naming that tool, on that role.
Mixing modes in one layer is legal and often right. An allowlist naming the role's apps, plus block rules naming a few tools inside them, works because a block beats an allow. For the narrower question of naming a tool against naming the app it belongs to, restrict one AI tool walks six cases.
What neither strategy covers
Restrictions bind what a connector is, not where it points. For restriction purposes a connector's identity is its own slug plus its declared fork lineage; the host it calls is deliberately not part of it. A connector built from scratch against the same API as a blocked connector is not caught by that block. That is why connector:create is the one permission Elaichi flags as high trust, and why it sits with Org Owner and Org Admin alone.
Client-side tool permissions do not stand in for a rule either. Anthropic's support page says a Claude connector's tool permissions take one of three settings, Always allow, Needs approval or Blocked (Anthropic, checked October 2026), and Cursor's docs say Cursor asks for approval before using MCP tools by default (Cursor, checked October 2026). Neither setting can tell one connected app from another through Elaichi, because Elaichi never lists a connected tool by name. The client sees execute_tool, run_code and two Elaichi operations instead, so per-app and per-tool control is set in Elaichi, as restrictions.
Restrictions also do not hide. A tool blocked for someone still appears in their search results by name, flagged restricted, with no description, no schema and no way to call it, alongside a count of how many matches were withheld. A refused call tells the caller whether the block comes from their role or their own account, and that an admin can lift it through an access request. It does not name the rule, its author, or what else the rule covers.
And they are not the lever for everything. Locking a value into a tool call is frozen parameters on a toolbox entry, where a toolbox is a named list of tools pinned to connections. Limiting which apps one AI client may reach is the toolbox choice on that client's OAuth grant, the per-person approval behind its token. Approving an access request creates a grant that lifts one connector or tool out of that person's role rules; it never lifts a rule written for them personally, and no route or screen revokes or lists grants. On why a block catches a renamed tool and an allow does not, read blocks match tool names.
When a role needs no restriction at all
When no rule reaches a member, through their role or aimed at them, nothing is restricted for them. Every connector and tool passes the restriction check. For a small team where everyone already holds the same access in the underlying apps, that is often the honest answer.
Two cheaper controls come first. A person's own permissions in each app still apply, because a tool call runs on the account behind the connection it was made through. And at consent each person picks whether their AI client reaches all their tools or only chosen toolboxes, which narrows a client without any rule being written. Every call that reaches execution is written to the audit log either way, with the person, the connector, the connection and the MCP client.
If the question is still whether to govern at all, when you don't need an MCP gateway yet is the shorter read. The wider picture of roles, rules and evidence sits in MCP governance, and the trade-off between tight rules and automations that keep working is in least privilege for AI agents. To see the apps your rules would be naming, browse the connector catalog of 650+ connectors or the governance use case.
