The trap: an allow rule that blocks all tools
An admin opens restrictions, creates a rule, sets the mode to allow, and saves it before picking any connectors. The intent was a placeholder: a rule to fill in later. The effect is the opposite. In Elaichi, an allow rule that blocks all tools is the normal consequence of naming nothing. The allowlist stage engages on the rule's presence, not on its contents.
The rule's own summary says so. It reads "Allows nothing. Every connector and tool is blocked." Nobody reads a summary on a rule they consider empty.
The reports arrive an hour or two later, and they do not look like a restriction problem. A support lead says Claude lost its tools. A finance analyst says ChatGPT answers but cannot do anything. Nobody mentions the governance screen, because nobody outside the admin group has seen it. One definition before the recovery steps: a restriction is a rule that says which connectors and tools a role or one member may reach.
Why the allowlist engages on presence, not contents
Elaichi evaluates restrictions in two stages per layer. All allow rules in a layer merge into one allowlist. All block rules merge into one blocklist. A block always beats an allow.
The allowlist stage is conditional on existence. When a layer has no allow rule at all, there is no allowlist, so everything the blocklist does not name passes through. The moment a layer carries any allow rule, the allowlist switches on. From then on, every connector and tool that none of that layer's allow rules names is blocked for the target. The switch does not care how many connectors the rule names. Zero is a valid count.
That design is what makes an approved-apps list possible at all. A role that should reach Jira, Slack and Zendesk and nothing else gets three whole-connector allow rules. The rest of the catalog falls away without anyone writing a block for each connector. The cost of that convenience is the empty case: the same switch that closes the catalog around three named apps closes it around zero named apps.
Who is affected, and who is not
A restriction targets either a role, applying to every member who holds it, or one member. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. So the blast radius of an empty allow rule is exactly its target.
If the rule targets a role, every member holding that role loses every connector and tool. A member holds exactly one role in an organization, so there is no second role to fall back on. If the rule targets one member, only that person is affected, and their colleagues on the same role keep working. That is why the first reports often look like one person's broken setup rather than a policy change.
Two layers run at once: the rules on a member's role and the rules aimed at them personally. A connector or tool is reachable only when both layers admit it. An empty allow rule on either layer closes that layer, and a closed layer is enough to refuse everything. A personal rule can only narrow what the role allows. No personal rule rescues a member from an empty allow rule on their role.
What the affected person sees
A person hit by this does not get an error that names a rule. Elaichi deliberately does not tell the caller which rule refused them, who wrote it, why, or what else it covers.
What they get is a tool list that looks almost empty and a refusal in the chat. Their client still lists Elaichi's own elaichi__ operations, those their role and the grant's scopes allow. search_tools and execute_tool are still listed too. Elaichi offers both to a person whose every connected tool is restricted, so they can find out what to ask for. Searching returns their tools by name, flagged restricted, with no description and no schema, plus a restricted_count. A connector blocked whole shows as one row for the connector.
Calling one of those names returns a refusal in-band, on an HTTP 200. It says the tool is restricted for their role by an organization policy, or for their account, and that an admin can lift it through an access request. The refusal is deliberately vague about the cause, which is correct for the caller and unhelpful for triage. The cause is on the governance screen, not in the chat.
If the symptom is an empty tool list rather than restricted rows, the cause is probably somewhere else. Work through the tool-listing checklist before you go rule hunting.
How to recover
There are two fixes, and the right one depends on what the rule was meant to be.
If the rule was a placeholder, delete it. Deleting the only allow rule in that layer switches the allowlist off again, and the layer falls back to allowing everything its block rules do not name. Deleting needs the restriction:manage permission, which among the system roles only Org Owner and Org Admin hold. A rule aimed at a single member also needs restriction:override.
If the rule was meant to be an approved-apps list, finish it. Add a whole-connector allow rule for every app that role actually uses. An allow rule naming a connector whole admits every tool on it. They can be separate rules, because a layer's allow rules merge into one allowlist. Walk the role's real work before you save. A support role on an allowlist that names Zendesk but not Slack cannot reach Slack any more, even though no rule ever mentioned Slack.
Two refusals to expect while you work. An admin cannot create, edit or delete a restriction aimed at themselves while someone else's rule restricts them. Nor can they write one aimed at a role whose permissions exactly match their own. Both come back as 403 with a message asking another admin to make the change.
One thing the fix will not do is take effect at once. A role, team, restriction or access-grant change reaches every surface in about two minutes. Tell the affected team that before they refresh three times and file a second ticket.
Verify by listing tools as the affected role
The only check worth trusting runs as somebody who holds the role, because restrictions are evaluated for the person calling.
Use an account that holds the targeted role, with a connected MCP client. Have the client list tools, then call search_tools with a word from one of the role's real tools. Use something like "create ticket" rather than a sentence, because the search is lexical. Read the result:
- Rows with descriptions and input schemas mean the tool is callable for that person.
- Rows flagged restricted, with no schema, plus a restricted_count above zero, mean the rule still refuses them.
- A connector blocked whole shows as one row for the connector rather than a row per tool.
Then run one real call through execute_tool, because a listing proves advertising and a call proves authorization. Every connected-tool call passes one restriction clamp evaluated for the member the call acts as.
The console gives a second read without borrowing an account. The connector and connection tool lists return every tool with restricted, restricted_by and restricted_scope flags to anyone who can read the connector. The restricted_by value says whether the role's rules or the member's own did it. On a connector, restricted: true means a rule refuses the person the connector as a whole. Confirming that a single tool is restricted for you needs no restriction:view permission at all. The console cannot give you an organization-wide view of every toolbox. For the member's lived experience, the client is the instrument.
One count not to compute: a connector's tool_count counts what the provider offers, not what the caller may run. Subtracting the visible tools from it does not give the number of restricted tools. The AI catalog operations report restricted_count directly.
How to avoid writing the rule in the first place
Three habits keep this from recurring.
Write the allow rules for a role in one sitting, from a list of the apps that role uses. Save nothing until the list is complete. There is no draft state for a restriction, so a half-written allowlist is a live lockout.
Prefer block rules when the goal is to remove a few tools. A layer with only block rules has no allowlist, so everything it does not block passes. Blocking some of an app's write tools leaves the write tools you did not name reachable. That is the trade-off: blocks are safe to write incrementally and leak by default, allows are tight and lock out by default. The difference in how each one matches matters as much as the difference in default.
Read the rule's summary before saving. It is one sentence, it is generated from the rule's actual contents, and in this case it names the outcome precisely.
The AI client's own controls are a different lever, not a second copy of this one. Claude sets connector tool permissions to Always allow, Needs approval or Blocked. The setting applies to a whole connector, a category of its tools, or a single tool (Anthropic's own article, checked October 2026). Cursor's MCP Allowlist is an Enterprise-only feature, configured in the team dashboard (Cursor's docs, checked October 2026). ChatGPT's plugin permission options are Always ask, Allow read actions, Allow low-risk actions and Allow all actions (OpenAI's help article, checked October 2026). None of those can single out one connected app behind Elaichi, because per-tool client permissions see Elaichi's connected tools as one execute_tool. Per-app and per-tool control is set in Elaichi, as restrictions.
There is also a case where none of this applies. A role that should reach everything in the catalog needs no allow rule at all. When no restriction rule reaches a member, through their role or aimed at them, nothing is restricted for them. If your plan for a role is "everything," write nothing. The empty allow rule is only ever reachable by an admin who started writing a policy and stopped halfway.
For the wider model of how roles, restrictions and grants fit together, see who may do what, in which app. For the question of whether a restriction belongs on one tool or the whole connector, read the six cases. The catalog itself is at /connectors/.
