# Claude and ChatGPT connectors for teams

> Claude and ChatGPT connectors for teams work per person by design. Here is the point where that stops being enough, and the two documented limits people hit first.

**TL;DR** The connectors built into Claude and ChatGPT are excellent at one person connecting one account, which is what they are for. They become a problem at company scale for two documented reasons: connections are authorized per person, and Claude reaches your server from Anthropic's cloud rather than the user's laptop, so anything on a private network needs firewall work. Neither is a flaw. Both are the edge of what a client-side connector covers.

## Claude and ChatGPT connectors for teams, and where they stop

Start by giving the built-in option its due. If two people need an assistant to
read a document store, the connectors already in the client will do it today,
for nothing, with no procurement. Anything this post says about limits should be
read against that baseline, because most teams should start there.

The limits are not defects. They are the boundary of what a connector configured
by one person can cover, and both of the ones that matter are documented by the
vendors themselves.

## Limit one: the connection belongs to a person

OpenAI's help center describes
[connected apps in ChatGPT](https://help.openai.com/en/articles/11487775-connectors-in-chatgpt)
as something you connect by signing in to the account that already has access to
the information you want to use, with availability depending on your plan,
region, workspace, role and interface. It notes that some apps instead use an
administrator-managed connection.

Anthropic's equivalent, on
[custom connectors using remote MCP](https://support.claude.com/en/articles/11175166-about-custom-connectors-remote-mcp)
updated 11 August 2026, is similar in shape: a person adds a connector and
authorizes it.

Read those as an access model rather than a setup guide and the consequence is
clear. Access follows individuals. That is exactly right when the thing being
reached is that individual's own account, and it is the wrong unit when the
question is which of the company's two workspaces a given team may write to.

## Limit two: the call comes from the vendor's cloud

This is the one that surprises people mid-project, and it is worth quoting
because it invalidates a common plan.

Anthropic's documentation states that when you add a custom connector, Claude
connects to your remote server from Anthropic's cloud infrastructure rather than
from your local device, and that this is true across every Claude client
including the desktop app. A server hosted on a private corporate network,
behind a VPN, or blocked by a firewall will not connect even though you can
reach it from your own machine. Making it work means allowlisting the published
IP ranges in your firewall.

So "we will just point it at the internal one" is not a plan unless somebody in
network security has agreed to open a path. Worth discovering in week one rather
than week six.

## What actually breaks at company scale

Three questions arrive in the same order at every company, and none of them is
about capability.

**Who may reach what.** With per-person connectors the answer is assembled by
asking people, because no single place already knows. That is tolerable at five
people and not at fifty.

**How access is taken away.** When somebody leaves, each connector they
authorized is its own small task, in a place their manager may not have an
account. The work scales with people multiplied by systems.

**What happened.** After an unexpected change, the useful record names which
account was reached, not just that an assistant did something. Per-person
connectors produce per-person histories, which is a different artifact from an
organization's audit trail.

## The version of this that keeps the native experience

Worth being clear that a control plane is not an alternative user experience.
It is reached through the same connector mechanism the clients already have, so
people keep using Claude, ChatGPT or Cursor exactly as before. What changes is
what sits on the other end of the connection.

With Elaichi that is one organization-wide endpoint. Everyone points at the same
address and signs in, and the grant decides what they see. There are no
per-toolbox URLs and no embedded tokens, and no server to mint per person.

The three questions above then have single answers. Restrictions say which
connectors and which individual tools a role or a user may reach. 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. The
audit trail records one entry per tool-call attempt, succeeded or failed, naming
the connection actually reached rather than the one intended, with argument
names but never argument values.

Role and restriction changes are the slower path at about two minutes, through a
short cache plus edge propagation. It is worth knowing which changes are fast and
which are not.

## The honest case for staying native

Do not buy a control plane to find out whether agents are useful. Find that out
with the connectors you already have, because the answer arrives in a week and
costs nothing.

Stay native if the people involved are few, if the accounts they connect are
genuinely their own, and if nobody outside the team is asking what the agents
touched. That describes a lot of teams, and for them the built-in connectors are
not a compromise but the correct tool.

There is also a middle path worth naming: some systems governed centrally, the
rest left to individuals. Nothing forces an all-or-nothing decision, and the
systems that belong in the middle are usually the ones with shared accounts or
customer data in them.

## What to check before you decide

Pick the one system you would least like an agent to write to by mistake. Ask
who currently has it connected, how you would find out, and how you would
disconnect it for one person by tomorrow morning.

If you can answer all three from memory, the native connectors are serving you.
If you cannot, the gap is not a missing feature in Claude or ChatGPT. It is that
you are asking an organization-level question of a per-person tool. The
[MCP gateway comparison](/blog/mcp-gateway-comparison/) covers what to weigh
next.

## FAQ

### Are the connectors built into Claude and ChatGPT enough for a company?

For a handful of people connecting their own accounts, usually yes, and they cost nothing extra. They stop being enough when somebody has to answer who may reach which system, take that access away centrally, or show what an agent did on a specific day, because a connector authorized by an individual produces an individual answer to each of those.

### Can I point a native connector at an internal server?

Not without firewall work. Anthropic documents that Claude connects to a remote server from its own cloud infrastructure rather than from the user's device, on every client including the desktop app, so a server on a private network or behind a VPN will not connect unless you allowlist the published IP ranges.

### Do native connectors and a control plane compete?

Less than it looks. A control plane is reached through the same connector mechanism, so the client keeps its native experience and the company gets one place to grant, restrict and log access. The choice is not connectors or governance; it is whether each person configures their own or everyone points at one governed address.

## Read next

- [MCP gateway comparison: what each one governs](/blog/mcp-gateway-comparison/) — An MCP gateway comparison across five ways to give a company governed AI access, what each one actually controls, and the question that separates them: what varies from one person to the next.
- [Connect Notion to ChatGPT without oversharing](/blog/connect-notion-to-chatgpt-privately/) — To connect Notion to ChatGPT without exposing private pages, the connection has to carry each person's own access rather than a shared workspace credential.
- [What your controls miss about shadow AI at work](/blog/shadow-ai-at-work/) — Shadow AI at work is mostly invisible to proxies, DLP and your IdP, because none of them sit where the paste happens. Here is what each one records, and what closes the gap.