Approved AI tools per team, set by role

Why does every team reach the whole catalog by default?

Because the absence of a rule means allow-all. A head of IT connects Elaichi and points Claude, ChatGPT and Cursor at one address. Sales, support, engineering and finance all sign in to the same place. With no restriction written, a member can connect any catalog app with their own account. Approved AI tools per team is therefore something you write down, not something you inherit.

MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Elaichi serves every connected account through one organization-wide MCP endpoint, and each member signs in there with their own OAuth grant. OAuth is the browser sign-in that issues a scoped token instead of handing over a password. The catalog behind that endpoint holds 600+ connectors. No team needs all of them. Four teams typically need four different slices of them. Sales needs CRM and email. Finance needs the accounting suite and nothing with write access to it. Engineering needs the issue tracker and source control. Support needs the helpdesk and nothing else.

The problem is not specific to Elaichi. Any shared endpoint that several teams sign in to needs a written rule before those teams reach different things. The rest of this post sets out the general framework, then how Elaichi implements it.

The general framework: enforcement and curation are two different jobs

This distinction holds regardless of which platform you're on:

• Enforcement is a restriction bound to an identity (a role or a user). It determines what is reachable at all.
• Curation is what a person picks from whatever enforcement left reachable. It determines what is convenient, not what is possible.

A restriction decides which connectors and which individual tools a target may reach. In Elaichi it is checked against the same resolver at four points. Those points are browse, connect, advertise and execute, plus a final check on the fully substituted outbound URL. A tool a role cannot reach is never advertised over MCP and never enters the search index, so the model does not learn it exists. That holds whichever client the person is using: Claude, ChatGPT, Cursor, or a custom agent.

Curation is softer by design. A template is a tool list someone assembled for a team. The consent-screen choice between "All my tools" and "Only the ones I pick" is the person's own scoping. Neither stops anybody from reaching something else they are already allowed to reach. Treat a curated toolbox as a control and the approved-apps plan stops being one. A toolbox changes what shows up in a menu, not what the model can call.

How to write approved AI tools per team as allow rules

A role's approved-apps list is its allow rules, and naming whole connectors is fine. Allow rules on the same role union, so one allow rule per app works. The role's allowlist is all of its allow rules together.

The trap: an allow rule is the target's whole allowlist, across every connector, not an incremental grant layered on top of some implicit baseline. Once the sales role holds an allow rule naming Salesforce, every connector and tool that role's rules do not name is denied for that role. That is the behavior you want from an approved-apps list, as long as you name every app the team uses. Miss one and the team loses it silently, with no error, because "not listed" and "denied" are the same state.

Worked example. Say the sales role needs Salesforce, Gmail, and Slack, and nothing else:

Three allow rules, unioned, form the complete list. Add a fourth app later and sales gains it within about two minutes of the rule being saved. Forget to add it and sales never sees it, with no visible error on either side.

Two more mechanics decide how the first rule behaves:

• An allow rule naming connector X whole, plus some of X's tools, reaches all of X. The tool entries grant nothing extra. The API refuses that overlap on new rules, so you can't accidentally create a rule that looks more specific than it is.
• An allow rule naming nothing denies everything. It is the strictest rule you can express.

Holding one app to its read tools is a different move once the role already has an approved-apps list. Allow rules on one role union. So if finance's allow rules name QuickBooks whole, a second allow rule naming only its read tools changes nothing. The union still reaches all of QuickBooks. To hold QuickBooks to reads, name its read tools in place of the whole connector, or keep the whole-connector allow and put blocks on its write tools. Blocks union with each other, and blocks always beat allows regardless of which rule was written first. Which writes to block is a question a pilot's own call record answers, and narrowing to the tools people actually used keeps that list honest.

The two rule types also match differently. A block matches on the tool name or on the operation pinned against the catalog at write time. An allow matches on the pinned operation only. Whoever edits a connector's documentation can change an advertised tool name. So allows bind the operation rather than the label, and a rename cannot widen what an allow reaches. Why blocks match tool names but allows do not covers that asymmetry, and restricting one tool against restricting the whole app works through six cases.

A rule on a user replaces the role rules for that user rather than adding to them.

Which identity-provider group maps to which role?

Map each team's group to its own role. The reason is that restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A SCIM group mapping grants exactly one role, and a member holds exactly one role, enforced by a unique index. SCIM (System for Cross-domain Identity Management) is the provisioning standard your identity provider uses to push users and groups into an application.

So the shape is one role per team persona: a sales role, a support role, an engineering role, a finance role. Each is a complete persona rather than a bolt-on, which is the point of the one-role-per-member rule. It is also the main design constraint to plan around. Custom roles are a Gold-tier feature, so check pricing before planning a role structure that depends on them.

Verified domains and SSO connections each carry a configurable default role, and domain, SSO and SCIM joins fall back to Member when none is set.

Team membership is set separately from role. SCIM and group mapping never set team membership. People who join by SCIM, domain or SSO are added to teams afterward, and invites can preset teams. Teams matter for sharing (templates, toolboxes), not for enforcement (allow/block rules). A SCIM deprovision suspends the member rather than removing them, which revokes every live grant immediately. Removal is a separate step an admin takes in Elaichi afterward. SCIM and AI agents covers where provisioning stops and manual admin action starts.

How does each person get a curated list on their own accounts?

Share a template with the team at use, and let each member stamp it. Stamping creates that person's own toolbox. Each entry is bound to a connection that person can use, with them recorded as the delegator. An entry with no usable connection is left as "needs connection" rather than failing silently.

Worked example. The sales lead builds a template called "Sales Outreach" with five Salesforce tools, three Gmail tools, and two Slack tools, each with sensible defaults. The lead shares it with the Sales team. Each rep stamps it:

1. Rep A has already connected their own Salesforce and Gmail accounts, so all ten entries bind to Rep A's own connections.
2. Rep B has connected Gmail but not Salesforce yet, so the five Salesforce entries sit as "needs connection" until Rep B connects.
3. The template itself never holds a connection; only each stamped copy does.

A template holds a tool list with renames, defaults and frozen parameters, and it never holds a connection itself. Stamping copies the list once, so editing the template later does not change a toolbox already stamped. Re-share and re-stamp when the list changes.

Do not pair "each person connects their own account" with "share one toolbox." A toolbox shared at use is the opposite arrangement. Every grantee's call runs on the connection pinned in its entries, which is the owner's account, not the grantee's. That's correct when one account should serve a whole team (a shared support inbox, a shared CRM user). It is wrong when each rep should reach only their own records.

A frozen argument inside a stamped toolbox is not a control over the person who stamped it. A freeze holds only on the path that runs through that entry. Anyone holding direct "use" on the underlying connection can call the same tool unfrozen. Locking an argument for a team requires an unshared connection, pinned into a toolbox by its owner and shared at use. Locking AI agent tool arguments sets out the mechanism, such as freezing a wire-transfer receiver account number so no rep can redirect funds.

On the consent screen, a member who ticks "Run your connected tools" gets a second step. "All my tools" is the default. It picks up accounts they connect later and connections shared with them later, so it is a live, expanding grant rather than a snapshot. "Only the ones I pick" narrows the grant to chosen toolboxes, up to 50. If none of those toolboxes resolves any more, say because the underlying connection was revoked, the client sees no connected tools. There is never a silent fallback to everything.

The consent checkboxes do not make a connected app read-only. For a connected app's tools, "run your connected tools" covers reads and writes alike; only a delete action costs an extra destructive-action scope. Read-only access to an app is achieved through a restriction (a block on write tools), not through consent-screen choices.

What happens when finance asks for an app outside the list?

It becomes an access request. Any member can file one with no permission needed; resolving one needs member:manage, the permission that covers managing people.

Approving a request that a restriction caused opens that connector or tool for that one requester only. A requester restricted through their role gets a lasting except rule layered on top. The role's other rules still bind them, and the rest of the team is unaffected. An admin cannot approve their own request. Restriction-caused requests are read-only on the AI surfaces. The Elaichi Agent and MCP clients can deny one, but approving it happens outside them, in the console.

Human approval for AI agent actions sets out the other approval layers, such as per-call approval for destructive actions, independent of access requests.

Time it accordingly: an approval, like any restriction change, takes effect within about two minutes. A team membership change sits in the same bucket. Removal is faster. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.

When are Claude and ChatGPT approval lists enough on their own?

When you run exactly one AI client and its own approval settings give the granularity you need. Both vendors ship that natively, and it is less setup than a separate control plane. The trade-off is granularity and cross-client consistency.

Sources: Claude tool permissions (support.claude.com, checked October 2026); ChatGPT role-based access control (help.openai.com, checked October 2026); ChatGPT per-app read and write actions (help.openai.com, checked October 2026).

Two things change the moment a second AI client appears in the organization. First, approvals don't transfer. The same person reaches the same underlying data under two independently-configured lists, one per client. Keeping them in sync is manual. Second, to ChatGPT, a control plane like Elaichi looks like one custom app. Its tools are search_tools, execute_tool, and its own operations. So ChatGPT's per-action switches can toggle the control plane on or off as a whole. They cannot distinguish which catalog app behind it a call is targeting. Per-app and per-tool approval for the apps behind that single connector has to be written in the control plane itself, not in ChatGPT's admin panel.

For the client-side path on its own, without a control plane, there are standalone guides for approving apps in Claude and restricting ChatGPT Enterprise connectors.

The honest part: the role binds, not the team

Restrictions bind a role or a single user. They do not bind a team. A team is a sharing construct, which is why templates go to teams and allow rules go to roles.

That split has a practical consequence. If two people sit on the same team but hold different roles, they reach different apps. A shared template then stamps differently for each. One person's stamped entries might resolve to real connections, while the other's sit at "needs connection" because their role never granted that app. If one person needs a wider list than their role allows, the clean answer is an approved access request, which adds one except rule. A user-targeted rule also works, but it replaces the role's rules for that person entirely. A second role is not an option, since a member holds exactly one role. Design the four roles first and the four teams second. Retrofitting roles after teams are already full of mixed-permission members is the harder order to untangle.

From here: the MCP control plane overview explains the endpoint these rules sit on. Designing roles for AI agents covers the one-role constraint in depth. The connector catalog is where you check that the apps a team wants are ones Elaichi already serves.