How to restrict ChatGPT Enterprise connectors

Can admins restrict ChatGPT Enterprise connectors?

Yes. Somebody in finance asks for Salesforce inside ChatGPT, and you want the boundary set before the first query runs.

Scope note before the detail: the OpenAI sections below are sourced to a specific help.openai.com article and a check date. Re-check a menu path on the live page before you write a runbook. The sections after "Where ChatGPT's per-action switches stop" describe Elaichi, a third-party MCP control plane, and how it extends those controls below the per-app level.

You can restrict ChatGPT Enterprise connectors app by app, and on Enterprise and Edu group by group. As of this check, apps are managed at Admin Console, then the workspace, then Plugins. The older page is Workspace settings, then Apps. It is also reached from Plugins through Manage Legacy Apps (help.openai.com, admin controls for plugins and apps, checked October 2026).

Plan matters more than anything else here:

The workspace-wide switch is the one control that exists on every paid team plan. Business workspaces start with apps on. New Enterprise and Edu workspaces start with a selected default set on. If you're auditing an existing workspace, don't assume the default. Read the current state directly.

Giving different groups different apps

Per-group app assignment is Enterprise and Edu only; it does not exist on Business at any price point. The path is Permissions & roles, then Custom roles, then Plugins & connected data, then Select. Roles are assigned to manual groups or groups synced via SCIM.

SCIM (RFC 7644) is the standard that syncs users and groups from your identity provider (Okta, Entra ID, etc.) into ChatGPT. So group membership in ChatGPT tracks group membership in your IdP, instead of being maintained by hand.

Two resolution rules matter in practice:

• Roles are additive. If any role a person holds grants a permission, they have it. There is no "most restrictive role wins": a second role can only add access, never subtract it.
• Propagation is not instant. Changes take up to 5 minutes to apply (help.openai.com, role-based access control in ChatGPT, checked October 2026). If you're testing a permission change, wait before concluding it failed.

On Business there is no group grain at all. Switching an app on switches it on for every member of the workspace. If your plan is Business and finance needs an app that support should not reach, that split cannot be built in the ChatGPT admin console. It has to live in an identity layer or a separate tool below the app.

Read actions, write actions and when ChatGPT asks first

Separate controls govern what an app may do and when the person is asked to approve it. Keep them distinct when you configure a workspace.

Business has had the Actions control since a release dated 20 April 2026 (help.openai.com, admin controls for plugins and apps, checked October 2026).

On Plugin permissions: members of a managed workspace never get a lasting "Always allow". No current OpenAI page documents what the default setting is for a newly enabled app. Check your own workspace rather than assuming "Always ask" or any other state (help.openai.com, managing app permissions, checked October 2026).

These controls only police what ChatGPT asks about. The destination system's own OAuth 2.0 scopes are a separate, independent check. OAuth is the browser sign-in flow that issues a scoped, revocable token instead of handing over a password. Salesforce's or Jira's own scope grants still apply underneath whatever ChatGPT allows.

Who may publish a custom MCP app

Only Admins and Owners can publish a custom app, on every plan tier that supports custom apps at all.

MCP (Model Context Protocol) is the open standard an AI client uses to discover a server's tools and call them. On Business, only admins and owners can use developer mode. On Enterprise and Edu, role-based access control can let regular members build and test drafts. The publish step, which sets the app's enabled actions and, on Enterprise and Edu, which groups receive it, stays with Admins and Owners.

Two behaviors worth planning around:

• Snapshots, not live sync. A published app runs on a frozen snapshot of its tool list. If the connector adds a tool later, it arrives disabled by default until an admin manually refreshes the app.
• No verification, no escalation path. OpenAI does not review or verify custom MCP apps before publish. There is no documented member-to-admin request flow for "I need this app published" (help.openai.com, developer mode and MCP apps, checked October 2026). Whatever approval process you want has to be built outside ChatGPT. It lives in Slack, a ticketing system, or the approval step in front of the tool call itself.

Where ChatGPT's per-action switches stop

This is the architectural limit that the controls above cannot see past. It applies to a server that exposes a search tool and an execute tool instead of listing every connected tool, as Elaichi does.

To ChatGPT, Elaichi is one custom app whose listed tools are search_tools, execute_tool and Elaichi's own operations. The actual connected tools, a Salesforce record update or a Jira issue create, are never listed in tools/list, no matter how few of them exist. The model finds a connected tool at runtime by calling search_tools, then invokes it by calling execute_tool with the tool's identifier as an argument.

Consequence: ChatGPT's per-app Actions toggle (read/write) and its Plugin permissions prompt can only act on execute_tool as a single undifferentiated unit. They cannot distinguish a Salesforce read from a Jira write, because both are the same tool call from ChatGPT's point of view. Only the arguments differ, and ChatGPT's admin console does not inspect arguments. Elaichi annotates execute_tool as destructive and open-world precisely because its real risk tier can't be known until the call resolves.

The practical implication: setting the aggregator app to "read actions only" in ChatGPT does not make the connectors behind it read-only. That setting acts on execute_tool, which runs every connected tool, reads included, so it cannot single out the writes behind it. If you need read/write or connector-level granularity, it has to be enforced inside the aggregator, before the call leaves it. That is what the rest of this post describes.

Writing per-app and per-tool rules in Elaichi

From here on, this describes Elaichi specifically, not an OpenAI feature.

Elaichi enforces per-app and per-tool rules as restrictions, written server-side, independent of ChatGPT's own permission model. A restriction names 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.

Resolution logic, in order:

1. A user-level restriction replaces the role's restriction entirely. It does not layer on top of it. If a user has their own rule, the role's rule for that user is ignored, not merged.
2. Within the winning layer, allow rules union and block rules union.
3. Blocks always beat allows, regardless of which rule was written more recently or more specifically.
4. An allow rule naming nothing denies everything. In Elaichi, the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. It is an easy rule to write by accident when a restriction is left half-filled.
5. An allow rule naming a connector as a whole grants every tool on that connector, even if specific tool entries are also listed. The tool entries in that case add nothing beyond what the connector-level grant already covers.

Matching detail that affects correctness: blocks match on the tool's name or on the operation pinned against the catalog. Allows match the pinned operation only. The reason is that a tool's advertised display name can be edited by whoever maintains the connector's documentation. Matching allows against a name would let a documentation edit silently widen access. A withheld tool is fully invisible to the caller: it is absent from both tools/list and the search_tools index, and its name is never transmitted. A restriction change takes effect within about two minutes.

Elaichi authors and serves 600+ connectors from its own infrastructure on one organization-wide endpoint, https://api.elaichi.ai/mcp. Because the restriction is enforced at that endpoint rather than inside any one client, a restriction written once for a role applies identically. That is true whether the member is using Claude, ChatGPT, Cursor, any other MCP client, or the Elaichi Agent. Each client sees the same filtered tool list and the same enforcement, because the filtering happens before the response reaches the client.

Each member holds exactly one role, which is why roles are built as complete personas rather than stacked fragments. The walkthrough of when to block a tool and when to block the app covers how to choose the grain for a given rule.

Failure mode to plan for: because enforcement happens at api.elaichi.ai, that endpoint is a dependency for every connector call from every client. If it's unreachable, calls fail closed: ChatGPT's execute_tool call returns an error rather than falling back to a direct, unfiltered connection to Salesforce or Jira. This also means every connector call takes one additional network hop versus a native, unmediated connector. Whether that overhead matters depends on your latency budget. It is worth measuring against your own traffic rather than taking on faith.

Where each layer's record lives

The two layers, ChatGPT's own logs and Elaichi's audit log, keep separate records, and neither is a superset of the other.

ChatGPT's Compliance Logs Platform is Enterprise and Edu only (Business has no equivalent). APP_LOG events carry the user's id and email, the app identifier (app_type includes MCP for custom apps), the conversation id, and the request/response payload. Relevant admin events include APP_SET_ENABLED_ACTIONS, ROLE_SET_PLUGIN_PERMISSIONS, and PLUGIN_USE_BLOCKED. Files are retained 30 days. No field documents the specific tool name that was called inside an aggregator app (OpenAI, compliance API reference, checked October 2026). That is precisely the gap that makes the per-action limit concrete: ChatGPT's own logs cannot tell you which connector or tool ran inside execute_tool.

Elaichi's audit log is the append-only record of what a tool-call entry has to capture at the tool level. Elaichi writes one entry per tool-call attempt, succeeded or failed. Argument names and argument counts are logged; argument values are never logged. Each entry records the client surface and the OAuth client the call arrived through. Claude, ChatGPT, and Cursor are distinguishable from each other by their registered redirect URIs. Each entry also states how the call was approved, which over MCP corresponds to the scope the client was granted at consent. The log is eventually consistent, so a row can take a short time to appear after the call completes. Don't treat an immediate query as authoritative.

The order to set this up

This sequence is Elaichi-specific. Write the restrictions before anyone connects. A person who signs in first can connect any catalog app their role allows. A restriction added afterward does not retroactively apply to calls already made.

1. Decide the roles. One role per member, each a complete persona.
2. Write a restriction per role in Elaichi: allow rules for the approved connectors, blocks for the specific tools nobody in that role should reach.
3. Create the custom app in ChatGPT under Workspace settings, then Apps, then Create. Paste https://api.elaichi.ai/mcp exactly, with no trailing slash, then Scan Tools and complete the OAuth prompt.
4. Publish the app, setting its enabled actions and, on Enterprise and Edu, the groups it's assigned to.
5. Set Plugin permissions to control how often ChatGPT prompts before a call.
6. Have each member connect and sign in. They choose scopes on Elaichi's own consent screen at connection time, and that per-person grant is independent of the role-level restriction and cannot exceed it.
7. Read the first week of calls in Elaichi's audit trail, filtered to the ChatGPT client. Confirm the restrictions behaved as written before you treat the rollout as done.

The client-side detail of step 3 and step 6 is covered in the ChatGPT connection walkthrough.

When the native controls are enough

If ChatGPT is the only AI client your organization will run, stop at the native controls described above. That holds when every app your teams need is already in OpenAI's own catalog with the granularity you need. The workspace switches, custom roles, and action controls cost nothing beyond your existing ChatGPT plan. Adding another layer for a problem you don't have is pure overhead.

A control plane like Elaichi earns its place under two conditions, not before. The first: a second MCP client enters the picture (Claude, Cursor, an internal agent), and you need the same restriction to apply in both without maintaining it twice. The second: the access rule you need is finer than "this app, on or off". That means a specific tool inside a connector rather than the whole connector. The Claude side of that two-client case is set out in approving apps for Claude across a company.

The case against adding a layer prematurely is set out in when a gateway is premature. The trade-off against OpenAI's built-in apps is in native connectors versus one endpoint. For the architecture underneath all of this, see what an MCP control plane is. To check whether your teams' apps are covered, see the connector catalog or team use cases.