# ChatGPT connectors alternative: per-user vs org-wide

> A ChatGPT connectors alternative is a decision about shape: per-user sign-ins inside the client, or one org-wide endpoint behind OAuth with a single audit trail.

**TL;DR** If each person signs in to each app inside ChatGPT, the unit of control is the person, and nobody holds a central list. Elaichi is a ChatGPT connectors alternative that connects each SaaS account once and serves it through one organization-wide MCP endpoint behind OAuth, with roles, restrictions and one audit trail that names the account actually reached. Grant revocation is effective on the next call, . Role and restriction changes take about two minutes.

## Where per-user connectors run out

They run out at the first question about an account that is not your own. An IT lead usually starts looking for a ChatGPT connectors alternative right after being asked one of those questions in a meeting and having nothing to say.

The shape matters more than the brand. When each person signs in to each app inside their own client session, the unit of control is the person. That works for one person. At twelve people and five apps you have sixty connections, each created inside a session you cannot see. No central list exists. No central revoke exists. A record changes, the owner says an assistant did it, and finding out which account wrote it means asking people one by one.

MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps

Per-user sign-in is not a defect. It is the right default for a product sold to individuals, where one person's assistant reaches one person's accounts. A company is a different reader with different questions.

## Why an IT lead looks for a ChatGPT connectors alternative

| Axis | ChatGPT native connectors | Elaichi |
| --- | --- | --- |
| Rollout unit | Per-user, inside each person's client session; the simplest setup for one person | Per organization; the app is connected once and every AI client points at the same address |
| Admin visibility | No central list of who connected which third-party account, unless the enterprise admin surfaces it | Full inventory of connections, grants, roles and restrictions in one console |
| Restrictions per tool | Whatever the third-party app or ChatGPT itself enforces on the call | Block or allow rules on role or user, matched by tool name or pinned operation |
| Offboarding | Deprovisioning stops sign-in; per-session connections must be found and revoked one by one | Grant revocation effective on the next call; preflight refuses removal until personal connections are transferred or deleted |
| Audit | Whatever ChatGPT's own enterprise logging records about a connector call | One row per call attempt names the connection actually reached; free read-only Auditor seat |
| Added apps | Each person connects each app themselves in their own session | Organization connects once; every member sees the app through the same endpoint |

Because the questions arriving are organizational while the controls available are personal. Before replacing anything, write down what your current setup already answers. Check each answer in your own admin console, and date the note. These products ship quickly, and a claim in a blog post, including this one, ages.

Five questions are usually enough to decide:

1. Can you list, in one place, which members connected which third-party accounts?
2. Can you block one destructive operation for everyone in the finance role and leave the rest alone?
3. When someone is deprovisioned in your identity provider, does their app access stop, and how soon?
4. For a change in a third-party app, can one query name the account that made it?
5. Does a compliance reviewer need a paid seat to read the record?

Four good answers out of five and you are fine for now. Two and you are running an unwritten policy. The comparison across several AI clients at once, rather than ChatGPT alone, is laid out in [one plane, many clients](/blog/elaichi-vs-native-ai-connectors/).

## How does one org-wide endpoint behind OAuth work?

Elaichi connects each SaaS account once and serves the tools through one organization-wide endpoint. An endpoint is a single network address a client calls. The address is `POST /mcp`: standard MCP over Streamable HTTP, JSON-RPC 2.0, stateless, behind OAuth. OAuth is the sign-in handshake in which a client receives a scoped token instead of holding a password.

There are no per-toolbox URLs and no embedded tokens. Claude, ChatGPT, Cursor and the Elaichi Agent are all pointed at the same address and sign in there. What differs between two members is the grant, not the URL. Elaichi authors and serves the connectors in its catalog of 450+, rather than listing servers other people run.

Access resolves in three layers, and they are worth keeping distinct:

- **Permissions.** About 38 action strings grouped into roles, with exactly one role per member. Each role is a complete persona rather than a bolt-on.
- **Sharing.** A grant of view, use or edit on a resource, to a user, a team or the whole organization. A member sees only what they own or what was shared with them. Being an org admin does not silently widen a listing.
- **Restrictions.** A restriction is a rule about which connectors and which individual tools a target may reach. Targets are role or user only. There is no organization target, because the organization default is the absence of a rule, which allows everything.

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

The same resolver runs at four points: browse, connect, advertise and execute, plus a final check on the fully substituted outbound URL. One trap is worth knowing before you write your first rule. the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. An allow rule that names nothing therefore denies everything. Which half of a rule matches a tool name and which matches the pinned operation is worked through in [name versus pinned operation](/blog/block-matches-name-allow-matches-operation/).

## Can you pin an argument the model never sees?

Yes. Frozen parameters are a per-entry map over a tool's flattened argument space, and they have two effects. Frozen keys are stripped from the advertised schema, so the model never sees them. Frozen values are merged over caller arguments at execution, so passing the key cannot un-freeze it.

The full precedence is entry defaults, then caller and model arguments, then frozen parameters. In practice this is how you pin a tool to one workspace, one environment or one record set. The model cannot choose a different one, because the choice was never in the schema it read.

## What a single audit trail answers that per-user logs cannot

It answers which account was reached, by whom, on which attempt. Elaichi writes one entry per tool-call attempt, succeeded or failed, and both name the account. The recorded connection is the one actually reached during execution, not the one the caller intended. "Which of our two Notion workspaces did the agent write to" is the first question after a surprise change, and it has an answer.

`actor_kind` is a recorded field, not something inferred later from a user agent. Its values include `user`, `system`, `scim`, `api_token` and `ai_assistant`.

Each record carries the operation and tool, the connection, the classification, whether it was approved, the outcome, and an error code. Argument names and counts are logged. Argument values never are. The error text returned to the caller comes from the third party's response body and is never written to the trail, because audit records are org-visible and get forwarded onward.

Audit events and application logs share one record shape, so one query answers what happened instead of two systems being correlated by eye. Each organization has its own log tenant, enforced in the type system rather than by a WHERE clause. The trail is append-only, newest-first, cursor-paginated, and filterable by free text, category, actor, action kind and time. It is eventually consistent, so a row can take a moment to appear. Export to Datadog is implemented. Splunk HEC and Microsoft Sentinel are accepted as destinations but are not yet delivering.

A compliance reviewer reads all of this on a free Auditor seat.

## How soon does a change take effect?

There are two answers, and mixing them up is how a rollout plan goes wrong.

Grant revocation, member removal and suspension take effect on the next call. Elaichi re-reads the OAuth grant from the organization store on every single call, with no cache, and removing or suspending a member revokes every live grant in the same transaction as the membership change.

Role membership and restriction changes take about two minutes. They resolve through a 60 second cache plus edge propagation, on every surface: MCP, console and REST alike. If an incident needs a hard stop now, suspend the member rather than editing their restrictions.

## What happens to a personal connection when somebody leaves?

Removal is refused until the connections are resolved. Offboarding runs a preflight. A personal connection referenced by a toolbox entry, meaning a saved set of tools a member or team uses, must be transferred to the organization, a team or another member, or deleted. Unreferenced personal connections are cleaned up.

A private connection is not transferable at all. A credential only its owner could ever use does not become someone else's because its owner left. Delegated toolbox entries surface as a non-blocking warning, and re-pinning is the fix rather than a credential decision.

On the way in, four paths exist: single-use invite links with roles and teams pre-assigned, verified-domain auto-join with a default role, SCIM v2 provisioning, and just-in-time SSO. SAML and OIDC SSO are built in-house, with group-to-role mapping, so your identity provider stays the source of truth. Contractors are the harder case, and [the contractor version of this problem](/blog/shadow-ai-contractor-offboarding/) covers it.

## What a control plane does not fix

The prompt-injection write gate is client-side, on the agent window, and no MCP server can. An MCP server never sees the user's prompt, so The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. What does hold on the endpoint: permission checks per operation, the forbidden classification that no OAuth scope can reach, output redaction, scope limits and full audit logging.

Three other limits belong in the same note. The `eu` and `us` regions are hard residency, covering compute and storage, while `apac` is a placement hint (best-effort). Eu and us are the two hard-residency zones. Deleting an organization tears down the workspace but has no path to purge its log tenant, and the response names that residue instead of pretending otherwise. And The two plans are Gold and Black, with a 14-day trial. Gold is $15 per user per month, or $120 per user per year, with a 14 day trial that needs no card. Suspended members and the free-seat roles are excluded from the billable count. [What each plan includes](/pricing/) has the rest.

Expect one change in behavior too. Past 30 tools, counting catalog operations and connected tools together, the connected tools collapse behind two meta-tools, `search_tools` and `execute_tool`. One connected app is normally enough to trip that, so collapse is the usual case rather than an edge case. Ranking behind it is lexical, with a relevance floor described in [why the floor exists](/blog/search-tools-ranking-floor-idf/).

## When are ChatGPT's own connectors enough?

When the unit of control and the unit of risk are the same person. A five person company with two apps, no contractors, no regulated records and no auditor asking for a log does not have a governance problem. Adding a control plane there adds a vendor, a bill and a sign-in step, and buys back very little.

The trigger list is short and honest. You need something else when a second AI client appears, when contractors or agencies get access, when one person's assistant can write to a system of record other teams depend on, or when someone outside the team asks for evidence. Until then, keep the connections few and named. [The case for waiting](/blog/when-you-dont-need-an-mcp-gateway/) works through it in more detail.

## How to test the alternative in two weeks

Run the test on one team and one app, not the whole company. Seven steps produce enough evidence to decide.

Start by listing every member who has connected a third-party account inside an AI client, and which account they used. Do it by asking. The gap between your list and reality is the finding. Then pick one team and one app. Sales and your CRM is a reasonable start, and the order of operations for that case is in this [sales team walkthrough](/blog/sales-team-chatgpt-salesforce-accounts/).

Start the 14 day trial, connect the app once at the organization level rather than per person, and point ChatGPT at the single endpoint through its admin console. Have two members sign in. Write one restriction against a destructive tool for one role and time it. It should hold within about two minutes. Suspend a test member and make a call, which should fail on the next call. Finally, export the trail to Datadog and confirm the entry names the account reached.

Decide on the evidence you generated rather than on a vendor page. If the trial ends without checkout, the workspace pauses, plan-gated features lock, and nothing is deleted.

If the shape you are comparing is a per-member server inside an automation account instead, read [one endpoint, not one per user](/blog/zapier-mcp-alternative/). Otherwise, look through the [connector catalog](/connectors/) for the apps your teams actually run, and the [team setups](/use-cases/) for the order to roll them out in.

## FAQ

### Is there a ChatGPT connectors alternative that works for a whole organization at once?

Yes. Elaichi is a governed MCP control plane: every SaaS account is connected once, and the tools are served through one organization-wide endpoint at POST /mcp, behind OAuth. Claude, ChatGPT, Cursor and the Elaichi Agent are all pointed at that same address and sign in. There are no per-toolbox URLs and no embedded tokens, so what differs between two members is the grant, not the URL.

### How quickly does a restriction change take effect in Elaichi?

Role membership and restriction changes take about two minutes. They resolve through a 60 second cache plus edge propagation, on MCP, console and REST alike. Grant revocation, member removal and suspension are different: the OAuth grant is re-read with no cache on every call, so those are effective on the next call. To stop access at once, suspend the member rather than editing restrictions.

### What is the smallest scope a restriction can target?

No. In Elaichi a restriction targets a role or a user only. There is no organization target, because the organization default is the absence of any rule, which means allow-all. A user-targeted rule replaces role rules entirely rather than layering on top of them, and within the winning layer a block always beats an allow.

### Does the audit log show which account an AI assistant used?

Yes. Elaichi writes one entry per tool-call attempt, succeeded or failed, and both name the account. The connection recorded is the one actually reached during execution, not the one the caller intended. actor_kind is a recorded field whose values include ai_assistant, so an AI action is logged as such at the point of action rather than guessed afterwards. Argument names and counts are logged, and argument values never are.

### Can an MCP control plane protect against prompt injection?

No, and the reason is structural: an MCP server never sees the user's prompt. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. and cannot. What does apply on the endpoint is permission checks per operation, the forbidden classification that no OAuth scope can reach, output redaction, OAuth scope limits and full audit logging.

### What does Elaichi cost, and Is there a free trial?

There are two plans, Gold and Black, with a 14-day trial. Gold is $15 per user per month, or $120 per user per year. A 14 day trial starts without a credit card. Billable seats are active memberships with a minimum of one, and suspended members plus the free-seat roles, which are Guest, Billing Admin and Auditor, are excluded from the count.

## Read next

- [Elaichi vs Composio for company-wide MCP access](/blog/elaichi-vs-composio/) — Elaichi vs Composio: one organization-wide MCP endpoint with connectors Elaichi authors, against per-team endpoints over a large third-party app registry.
- [Elaichi vs native AI connectors: one plane, many clients](/blog/elaichi-vs-native-ai-connectors/) — Elaichi vs native AI connectors: what a second AI client costs in repeated authorization, provisioning, audit shapes and role models, and when native is still right.
- [Lunar MCPX alternative: count your servers first](/blog/lunar-mcpx-alternative-governed-access/) — Lunar's MCPX fronts the MCP servers you already run. If you run none, the right Lunar MCPX alternative removes the servers instead of proxying them.