# How to roll out Claude and ChatGPT to employees

> Roll out Claude and ChatGPT to employees in order: approve apps, connect them once, build team toolboxes, map roles, pilot, onboard and offboard.

**TL;DR** To roll out Claude and ChatGPT to employees with company tools, connect each approved app once in Elaichi and point every client at one organization-wide endpoint. Teams decide what each department uses, roles and restrictions decide what it may reach, and a role or restriction change takes effect within about two minutes. Pilot one team, read the audit log, then onboard everyone through invites, domain auto-join, SCIM or just-in-time SSO.

The usual starting point is a pile of tickets. Sales pastes pipeline notes into ChatGPT. An engineer runs a Jira server on a laptop for Cursor. HR asks whether Claude can read Rippling. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. The job is to replace that pile with one path the company owns.

## How do you roll out Claude and ChatGPT to employees without a server per person?

Connect each approved app once, behind one organization-wide endpoint, and let each person sign in to it from their own client. Then decide reach with team sharing, roles and restrictions, and check the result in the audit log.

Elaichi is built for that path. Claude, ChatGPT, Cursor, any MCP client and the Elaichi Agent all reach the same address, `https://api.elaichi.ai/mcp`. There are no per-person URLs, tokens or servers. Each member still connects once and signs in with their own OAuth grant, the revocable permission a client receives at sign-in. For the engineering case, see [what happens when engineers already have ChatGPT](/blog/shadow-ai-cto-engineers-already-have-chatgpt/).

## How does a head of IT approve which apps employees can connect to Claude?

Write an allow rule for each role that names the approved connectors. In Elaichi, a connector the rule does not name is then refused at browse, connect, advertise and execute, plus a final check on the fully substituted outbound URL. A member cannot find it, connect it or call it, from any client.

Start with a list of the apps people already use with AI. Mark each one approved for everyone, approved for one department, or not yet. The [connector catalog](/connectors/) holds 500+ connectors, authored and served by Elaichi.

Then turn the list into restrictions. A restriction decides which connectors and which individual tools a target may reach. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. That default matters here. The Member role holds `connection:create`, so with no rule a member can connect any app in the catalog with their own account.

One trap: the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. Save the allow rule with its connectors already in it.

A member who meets a restricted connector can file an access request. Approving a request opens that connector or tool for that one person only, and the role's other rules keep binding them. An administrator cannot decide their own request, so a second person signs off.

## Which IT admin controls do Claude, ChatGPT and Cursor give you for MCP?

Each client controls how a server reaches its own users. Elaichi controls what is behind the server. You add the one address in each client, and the rules on roles, apps and tools live in one place behind it.

Here is what each vendor documents:

- **Claude.** On Team plans, only Owners and Primary Owners add a custom connector, under Organization settings > Connectors > Add > Custom > Web. Members then connect it themselves under Customize > Connectors ([Anthropic's help center](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp), checked October 2026).
- **ChatGPT.** Full MCP support, including write actions, is a beta on Business, Enterprise and Edu. An admin creates the app under Workspace settings > Apps > Create and publishes it. It then appears in users' Apps settings labeled custom, and OpenAI says functionality, UI and permissions may change ([OpenAI's help center](https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt), checked October 2026).
- **Cursor.** Enterprise admins can allowlist MCP servers, but the allowlist does not push a server to anyone's machine. Team admins can instead distribute a server through a team marketplace, where teammates install and configure it themselves ([Cursor's enterprise docs](https://cursor.com/docs/enterprise/model-and-integration-management) and [MCP docs](https://cursor.com/docs/mcp), checked October 2026).

Those are distribution controls, one per client. Elaichi's restrictions sit behind the endpoint, so one rule holds for every client. The per-client steps are in [the Claude setup guide](/blog/connect-elaichi-to-claude/), the [ChatGPT walkthrough](/blog/connect-elaichi-to-chatgpt/) and [Cursor for a whole team](/blog/cursor-mcp-one-endpoint-vs-per-developer/).

## How does a platform team centrally manage MCP servers for the whole company?

By not running any. Elaichi serves the connectors from its own infrastructure, so the platform team manages connections, sharing and rules instead of servers, versions and tokens.

Connect each company account once. Connector credentials do not live in Elaichi. A separate credential service holds them in the organization's region, encrypted at rest with AES-256-GCM, and owns token refresh. A failed refresh marks the connection Needs sign-in rather than failing silently.

Ownership is the next decision. A connection can stay private to one person, or be shared at `use` with a team or the whole organization. A shared connection runs on its owner's credential, so every call through it reaches the app as that account. Share one team-wide only when the whole team is meant to act as that account. For per-person access, share a template and let each person stamp it against their own account. A member sees only what they own or what was shared with them, admins included. Treat `connector:create` as high trust, because a custom connector can be pointed at any destination.

## How do you give sales, engineering and HR different AI tool access?

Use teams for what each department uses, and roles with restrictions for what each department may reach. In Elaichi, a team is a named group you share connections, toolboxes and templates with.

A toolbox is a saved set of tool entries, each pairing one tool with one connected account. A template is the same tool list with no accounts in it, carrying tool renames, defaults and frozen arguments. Teammates with `use` on a template stamp their own toolbox from it and pick their own connections. Stamping copies the template once, so a later edit leaves stamped toolboxes alone.

A workable split for three departments:

- **Sales.** Build a [Salesforce](/connectors/salesforce/) template and share it with Sales at `use`. Each rep stamps a toolbox against their own Salesforce account, so Salesforce's own permissions still apply per rep. The [sales playbook](/blog/sales-team-chatgpt-salesforce-accounts/) covers which tools to restrict.
- **Engineering.** Build a [Jira](/connectors/jira/) template with the issue tools engineers use, renamed in the team's own words. Share it with Engineering, and each engineer stamps a toolbox against their own Jira account.
- **HR.** Connect [Rippling](/connectors/rippling/) as a private connection, pin it into a toolbox with frozen arguments, and share only the toolbox with HR. Every call runs on the owner's Rippling account, so choose an owner whose access fits the whole team and who will stay. One condition: a freeze binds only calls made through its toolbox entry, so share the toolbox with the people it governs, not the connection itself. The [HR team's setup](/blog/hr-team-claude-rippling-employees/) works through it.

Teams carry shares, not rules. Restrictions target roles and users, never teams. Where two departments need different restrictions, give each its own custom role. Each person can also narrow a client at consent, from the default All my tools to Only the ones I pick, up to 50 toolboxes.

## Which roles and restrictions should each department start with?

Start every working seat on Member, and add a custom role only where a department's restrictions must differ. Each member holds exactly one role, so a department role has to describe a whole job.

Member is the working seat. Team Admin adds managing teams, and People Admin adds managing members. Guest, Billing Admin and Auditor lack `tool:execute`, so they cannot call a tool at all. Auditor is a free, read-only seat. [Designing one role per person](/blog/designing-roles-for-ai-agents/) covers the reasoning.

If your directory is the source of truth, map groups to roles. SCIM is how a directory pushes users and groups into an app, and in Elaichi each group mapping confers exactly one role. The Sales group lands on the sales role, Engineering on the engineering role. [Where SCIM provisioning stops](/blog/identity-provider-scim-vs-mcp-grants/) explains what a group cannot express.

Then write the rules for each role. Allow the approved connectors, and restrict the destructive tools a role does not need. A rule on a user replaces the role rules for that user rather than adding to them. Within the winning layer, blocks always beat allows. [Tool rules versus app rules](/blog/per-tool-vs-per-app-restrictions/) works through six cases.

A role or restriction change takes effect within about two minutes, on MCP, the console and REST alike.

## What should a one-team pilot prove before the company-wide rollout?

It should prove that the rules match the calls people actually make. Pick one team with a clear need, run it for two weeks, and read the audit log instead of collecting opinions.

Sales makes a good pilot, with one main app and clear read and write tools. Before day one, give one reviewer the Auditor seat, so the record has a reader who cannot act.

The audit log is the chronological record of who did what. Elaichi writes one entry per tool-call attempt, succeeded or failed, and each entry names the account the call actually reached. A call from Claude, ChatGPT or Cursor is recorded under the employee who signed in, with the client it came through. The trail logs argument names and counts, and never argument values.

Read the log for three things. Tools nobody called can leave the toolbox. Refusals show a rule that is too tight. Calls to an unexpected account show a sharing gap. [What an AI audit log must capture](/blog/what-an-ai-audit-log-must-capture/) lists the fields to check.

The pricing page shows what each plan includes and how the 14-day trial works, so you can run the pilot before anyone buys a seat.

[See plans and the free trial](/pricing/)

## How does a new hire's assistant get the right app access automatically?

Through the role and the shares they arrive with. Elaichi has four ways in, and each one sets a role on day one.

| Path | Role on arrival | Teams on arrival |
|---|---|---|
| Emailed single-use invite | Preset by the inviter | Preset by the inviter |
| Verified-domain auto-join | The domain's default role | Added afterward |
| Just-in-time SSO | The SSO connection's default role | Added afterward |
| SCIM provisioning | The role mapped to the person's group | Added afterward |

Where no default role is configured, an automatic join lands on Member. Anything shared with the whole organization reaches the new hire at once. A team share reaches them within about two minutes of being added to the team. SCIM and group mapping set the role, not team membership, so a Team Admin or above adds the person to their team. Keep that step in the joiner checklist.

The new hire then connects each client once and signs in. The default consent choice, All my tools, also picks up connections shared with the person later, so team shares arrive without reconnecting.

## How do you close AI access when an employee leaves?

Suspend or remove the member, and their very next call is refused. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change, and the grant is re-read on every call with no cache.

A SCIM deprovision suspends the member and never removes them. Removal is a separate step in Elaichi, and it runs a preflight. Personal connections that a toolbox entry depends on must go to the organization, a team or a colleague, or be deleted. A private connection is never transferable. One pinned by a toolbox its owner shared blocks removal until an administrator decides. So the person who connects HR's private Rippling account should be someone who will stay.

Removal ends access through Elaichi, nothing more. The person's account inside each app still exists, and it is closed there or through the identity provider. [The offboarding runbook](/blog/offboarding-when-the-agent-holds-access/) walks through a contractor case. Then check the audit log, where a removed member's past calls stay, labeled Former member.

## When do you not need a control plane for this rollout?

When one team uses one app and that app's own MCP server already does the job. Several vendors now host one, and it runs under the app's own permissions with no second vendor.

Notion is a fair example. Notion describes its server as "a remote MCP server hosted by Notion", where the client can read and update content the person can access. Workspace owners manage client access under Settings > Connections ([Notion's docs](https://developers.notion.com/docs/mcp), checked October 2026). For a product team living in Notion alone, that may be enough.

The case changes at the second app or the second team. Then you want one address across vendors, rules written once per role, and one audit trail. If no assistant can write to a company system yet, read [the case for waiting](/blog/when-you-dont-need-an-mcp-gateway/) first. Know one limit as well. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call.

As of October 2026, SSO, SCIM, group-to-role mapping and custom roles are on Gold, and the 14-day trial unlocks all of them. Gold lists at $15 per user per month in USD, and [pricing](/pricing/) shows your local price and the trial terms. More governance posts sit under [governance](/blog/category/governance/), and team-by-team starting points are on the [use cases page](/use-cases/).

## FAQ

### As head of IT, how do I approve which apps employees can connect to Claude?

In Elaichi, write an allow rule for each role that names the approved connectors. A connector the rule does not name is then refused when a member browses for it, connects it or calls it, from Claude, ChatGPT, Cursor or any other MCP client. Save the rule with its connectors in it, because an allow rule that names nothing denies everything. A member who needs an app that is not approved can file an access request, and an administrator approves or denies it.

### What IT admin controls exist for MCP connectors across Claude, ChatGPT and Cursor?

Each client's admin console decides how an MCP server reaches that client's users. Elaichi decides what is behind the server. Point all three clients at the one Elaichi endpoint, and the same roles, restrictions and audit log apply whichever client makes the call. A restriction can name a whole connector or single tools, and it targets a role or one user.

### How does a platform team centrally manage MCP servers for the whole company?

With Elaichi, a platform team runs no MCP servers. Elaichi authors and serves the connectors, every client uses one organization-wide endpoint, and the team manages connections, sharing, roles and restrictions in one console. Connector credentials sit in a separate credential service that owns token refresh, and a failed refresh shows the connection as needing sign-in instead of failing silently.

### How do I onboard a new hire so their AI assistant gets the right app access automatically?

In Elaichi, every onboarding path sets a role on day one. An emailed invite can preset both the role and the teams. Verified-domain auto-join and just-in-time SSO apply a configured default role, and SCIM applies the role mapped to the person's directory group. Anything shared with the whole organization reaches the new hire at once. A team share reaches them within about two minutes of being added to the team, and SCIM does not set team membership, so keep that step in the joiner checklist.

### How long does a role or restriction change take in Elaichi?

A role or restriction change in Elaichi takes effect within about two minutes, on MCP, the console and the REST API alike. Removing or suspending a member is faster: the grant is re-read on every call, so the person's next call is refused. Revoking a share and disconnecting an account also take effect on the next call.

## Read next

- [Designing roles for AI agents: one role each](/blog/designing-roles-for-ai-agents/) — Design roles for AI agents as one complete job per person: Elaichi gives each member exactly one role and leaves which tools they reach to restrictions.
- [SCIM and AI agents: where provisioning stops](/blog/identity-provider-scim-vs-mcp-grants/) — SCIM and AI agents meet at the user account: SCIM creates, updates and deactivates it, but it never decides which tools an agent may call.
- [Offboarding AI access, contractors included](/blog/offboarding-when-the-agent-holds-access/) — Offboarding AI access in Elaichi takes effect on the next call. Here is what the removal preflight checks, and the order that works.