# How to connect Elaichi AI to ChatGPT

> How to connect Elaichi AI to ChatGPT: one endpoint in the admin console, an OAuth sign-in per person, and role and restriction checks on every call.

**TL;DR** To connect Elaichi AI to ChatGPT, an admin points ChatGPT's own admin console at one organization-wide Elaichi MCP endpoint, and each person signs in to it with OAuth. There is no API key to paste and no per-user URL. After that, the member's role, the resources shared with them and any restrictions decide which tools ChatGPT can see and call. Every attempt is recorded in the audit log, naming the account actually reached.

## How to connect Elaichi AI to ChatGPT in five steps

Your support team already lives in ChatGPT. Someone asks for Zendesk access inside it, and the shortest path is a personal API token pasted into a custom setup. Do that ten times and you have ten credentials nobody can revoke centrally.

How to connect Elaichi AI to ChatGPT comes down to five steps. An admin adds one URL in ChatGPT's own admin console. Each person signs in through that connector with OAuth, a sign-in handshake that issues a per-person grant rather than sharing a password. Each person connects the app accounts they are entitled to use. Restrictions decide which connectors and which individual tools reach them. Every call attempt lands in the audit log.

MCP, the Model Context Protocol ([spec](https://modelcontextprotocol.io/specification), checked September 2026), is the open standard an AI client uses to discover and call tools. Elaichi serves every connected SaaS account through one organization-wide MCP endpoint, a single network address that accepts tool calls. It is `POST /mcp`, standard MCP over Streamable HTTP, JSON-RPC 2.0, stateless, behind OAuth.

## What does an admin add to the ChatGPT admin console?

One address, once. The admin adds the Elaichi organization's MCP endpoint as a connector in ChatGPT's admin console and rolls it out to the workspace. OpenAI moves its menu labels around, so check OpenAI's current admin documentation for where connectors live today. The value you paste does not change.

There are no per-toolbox URLs and no embedded tokens. There is no MCP server to create, list or revoke per person. The endpoint is one address, and what varies is the grant behind each person's sign-in.

Many people arrive looking for an Elaichi AI connect to ChatGPT integration API, expecting a second API to wire up plus a key to store in a secrets manager. There is not one. The MCP endpoint is the API surface, and OAuth carries identity, so nothing durable and copyable ends up inside the client.

The same address works for Claude and Cursor through their own admin consoles. Adding a fourth MCP client is the same shape of work: one URL, one rollout, no fork of the setup. A comparison of that model against each vendor's own built-in app connectors sits in [one plane, many clients](/blog/elaichi-vs-native-ai-connectors/).

## What does a user see the first time they sign in?

A sign-in screen, then a short list of tools. ChatGPT opens Elaichi's OAuth flow, the person authenticates, and ChatGPT holds a grant scoped to that person.

How they authenticate depends on what the organization set up. Elaichi supports Google, GitHub and Microsoft sign-in, email codes, TOTP multi-factor codes with single-use recovery codes, and passkeys. Enterprise SAML and OIDC single sign-on, meaning identity handled by your own provider, is built in-house. SCIM v2 provisioning and group-to-role mapping sit alongside it, and domains are verified with a DNS TXT record.

What appears after sign-in is narrower than most people expect, by design. A member sees only what they own or what was explicitly shared with them through a grant of view, use or edit. No org-level permission silently widens that listing, org owners and admins included.

If the person's role lacks the `tool:execute` permission, the list comes back empty and any call returns an in-band error naming the missing permission. Guest, Auditor and Billing Admin are the roles without it. That is the correct outcome for a compliance reviewer who signs in out of curiosity.

## Where do the app accounts come from after ChatGPT is connected?

The person connects them, from inside ChatGPT or from the Elaichi console, against a catalog of 450+. Elaichi authors and serves those connectors from its own infrastructure, so there is no separate MCP server for your team to run per app.

The connect step returns a connect URL. That URL is a one-time session and carries no token, which is why it is safe to hand back over MCP. Credentials never live in Elaichi. A separate credential service holds per-account secrets, encrypted with AES-256-GCM at rest, and owns token refresh. A failed refresh marks the connection `needs_reauth` rather than failing quietly mid-workflow.

An organization can supply its own OAuth app per connector. The accepted body is a client ID, a client secret and scopes, and everything endpoint-shaped is deliberately unrepresentable. It is gated on `connector:manage`, not `connection:manage`, so everyone who can delete a connection does not silently gain the ability to repoint the organization's OAuth app.

When the catalog does not cover something, custom connectors are authored from JSON config. They can be forked from a public connector and can pull upstream changes through a review surface that separates new tools, safe updates, config diffs, conflicts and upstream removals. Synthetic tools chain steps into a graph, each step calling a connection's tool with templated arguments, and every step goes through the same restriction and audit pipeline as any other call.

## What governs a ChatGPT tool call once the connector is live?

Three layers, checked against the same resolver on every call. Keep them distinct, because they fail differently.

First, permissions. Elaichi has around 38 action strings grouped into roles, and exactly one role per member, enforced by a unique index. `tool:execute` gates the whole endpoint ahead of every scope.

Second, resource sharing. A grant of view, use or edit on a connection or toolbox is what makes it visible to somebody who does not own it.

Third, restrictions, which are the rules saying which connectors and tools a target may reach. Targets are role or user only. There is no organization target, because the organization default is the absence of any rule, which means allow-all. A user rule replaces role rules entirely rather than layering on top. Within the winning layer, allows union, blocks union, and blocks always beat allows.

Two details bite people. the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything, so an allow rule naming nothing denies everything. And a block matches the tool name or the pinned operation, while an allow matches the pinned operation only. The reasoning behind that asymmetry is set out in [name versus pinned operation](/blog/block-matches-name-allow-matches-operation/).

Frozen parameters sit underneath all of this. A frozen key is stripped from the schema ChatGPT is shown, so the model never sees it, and the frozen value is merged over caller arguments at execution. Passing the key cannot un-freeze it. The precedence runs entry defaults, then caller arguments, then frozen parameters.

Timing matters when you are fixing something live. A role or restriction change takes effect within about two minutes, through a 60-second cache plus edge propagation. Only grant revocation, member removal and suspension are effective on the next call, because the grant's revocation state is re-read from the organization store every time.

OAuth scopes narrow things further. They are `mcp:read`, `mcp:write`, `mcp:destructive` and `mcp:tools`, and a tool classified `forbidden` is reachable under no scope at all. `mcp:tools` does not replace the ladder. A connected tool whose method is a delete needs `mcp:destructive` as well.

## Why does ChatGPT show only search_tools and execute_tool?

Because the tool count crossed 30, and the connected half collapsed behind two meta-tools. That threshold counts control-plane catalog operations and connected tools together, and the control-plane catalog alone runs to dozens of operations. One connected app is normally enough to trip it, so collapse is the normal case rather than an edge case.

Control-plane operations stay listed individually under the `elaichi__{resource}__{operation}` namespace, and `search_tools` never returns one. Tools withheld by a restriction are excluded from the count, since they were handed to nobody.

`execute_tool` is only a naming indirection. It unwraps to the same tool name and arguments and falls through the identical gates. There is no separate execution path and no privilege hiding inside it.

Search ranking is purely lexical over the tool name, description and connector label, weighted so an exact name match outscores a connector label, which outscores a description hit. A relevance floor keeps a query about one app from returning a plausible-looking tool from another. The failure that motivated the floor is written up in [the ranking floor post](/blog/search-tools-ranking-floor-idf/).

## What the audit log shows after a ChatGPT call

one entry per tool-call attempt, succeeded or failed, and both name the account actually reached. The audit log here means the append-only record of who did what, and the recorded connection comes from the execution rather than from the intent. "Which of my two Notion workspaces did the agent write to?" is the first question anybody asks after an unexpected change.

`actor_kind` is a recorded field, not an inference. Its values include `user`, `system`, `staff`, `scim`, `api_token` and `ai_assistant`. Whether an action came through an AI client is written at the point of action, not guessed later from a user agent string.

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. Two error strings exist per failed call, and the one built from the third party's response body goes back to the caller only. The audit entry is never derived from the request or the response, because audit records are org-visible and fan out to whatever SIEM the customer configured.

The trail is append-only, newest-first, cursor-paginated and filterable by text, category, actor, action kind and time. It is eventually consistent, so a row may take a moment to appear. Forwarding to your own destination is available, with Datadog implemented and Splunk HEC and Microsoft Sentinel accepted but not yet delivering. The region chosen at organization creation decides where the trail lands: `eu` and `us` are hard residency for compute and storage, while `apac` is a placement hint (best-effort). Eu and us are the two hard-residency zones. A read-only Auditor seat is free, so a reviewer reading all of this does not consume a license.

## What happens to ChatGPT access when somebody leaves?

removing or suspending a member revokes every live grant in the same transaction as the membership change, so the next call from that person's ChatGPT session fails. Suspension behaves the same way.

The removal itself runs a preflight first. Personal connections referenced by a toolbox entry have to be resolved, by transfer to the org, a team or another member, or by deletion, or the removal is refused. Unreferenced personal connections are cleaned up. A private connection is not transferable at all, because a credential only its owner could ever use does not become someone else's when that owner leaves. Delegated toolbox entries surface as a non-blocking warning, and re-pinning is the fix rather than a credential decision. The same-day version of this for short-term staff is in [contractor offboarding](/blog/shadow-ai-contractor-offboarding/).

## What connecting ChatGPT this way does not protect against

Prompt injection on the endpoint. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. It sees a tool call that has already been decided.

So do not sell this internally as an anti-injection control. What does hold on the endpoint is worth stating plainly: role-based permission checks per operation, the `forbidden` classification that no OAuth scope can reach, output redaction, scope limits and full audit logging. Enforcement runs at four points against the same resolver, at browse, connect, advertise and execute, plus a final check on the fully substituted outbound URL, plus a final check on the fully-substituted outbound URL.

The practical effect is containment rather than prevention. A manipulated model still cannot call a tool its caller was never granted, and whatever it did call is attributable afterwards.

## When you should not connect ChatGPT to a control plane yet

If four people use ChatGPT against two apps they each own personally, this is more machinery than the problem deserves. Turn the apps' own admin controls up, and revisit when the first contractor leaves or the first team asks for an account that is not theirs. The fuller version of that argument is in [the case for waiting](/blog/when-you-dont-need-an-mcp-gateway/).

Cost is the other honest constraint. 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, no credit card to start. Checkout does collect a card, and it sets the paid trial to the remaining days rather than granting a fresh 14, so it is one continuous trial rather than two. Suspended members and the free-seat roles are excluded from the billable count.

If you are ready, the next decisions are which connectors to turn on and which team goes first. Browse the [connector catalog](/connectors/) or the [team pages](/use-cases/), and for a worked example of one team's rollout, read [Salesforce access for a sales team](/blog/sales-team-chatgpt-salesforce-accounts/).

## FAQ

### Do I need an API key to connect Elaichi AI to ChatGPT?

No. Elaichi serves one organization-wide MCP endpoint at POST /mcp, behind OAuth, so each person signs in rather than pasting a key. There are no per-toolbox URLs and no embedded tokens in the client, and there is no second API to wire up alongside the endpoint.

### Can the same Elaichi endpoint be used for Claude and Cursor as well as ChatGPT?

Yes. Elaichi's MCP endpoint is one address for the whole organization, and Claude, ChatGPT and Cursor can each be pointed at it through their own admin consoles. Adding a further MCP client is the same work again: one URL, one rollout, no separate setup per client or per user.

### How quickly does a restriction change affect what ChatGPT can call?

A role or restriction change in Elaichi takes effect within about two minutes, because it resolves through a 60-second cache plus edge propagation. Only grant revocation, member removal and suspension are effective on the next call, since the grant's revocation state is re-read from the organization store on every call.

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

No. Restrictions in Elaichi target a role or an individual user, and there is no organization target. 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 blocks always beat allows within the winning layer.

### Does connecting ChatGPT through Elaichi stop prompt injection?

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

## Read next

- [MCP governance platforms compared for IT teams](/blog/mcp-governance-platforms-compared-for-enterprise-it-teams/) — MCP governance platforms compared on four mechanics: who authors the connectors, how many addresses clients point at, where the access decision is made, and what the record proves.
- [MCP tool search relevance floor, from first principles](/blog/search-tools-ranking-floor-idf/) — A search for a Cal.com tool returned a Notion one. The MCP tool search relevance floor is the rule that stops it: a result must cover half the query's weighted mass.
- [MCP context window tool overload at 30 tools](/blog/context-window-problem-mcp-tools/) — MCP context window tool overload starts earlier than most teams expect: Elaichi collapses connected tools behind two meta-tools once the combined count passes 30.