To govern ChatGPT and Claude connectors in the enterprise, treat every connector as a third-party integration with delegated access to company data: keep an allow-list of approved connectors, disable custom or user-added remote servers by default, grant the narrowest OAuth scopes each connector supports, assign an owner, and review usage on the same schedule as other SaaS apps. Connectors are increasingly built on the Model Context Protocol, so the controls that apply to registering and governing MCP servers apply here too, with one difference: the client is a vendor's chat product, not an agent you run.
The reason this needs a deliberate policy is that connectors are easy to turn on. A user clicks connect, approves an OAuth screen, and the assistant can now search a drive, read a ticket queue or post to a channel. Nobody filed a procurement request, and the security team may only find out from an OAuth grant report weeks later.
What a connector actually is
The MCP project describes the protocol as an open standard that lets AI applications such as Claude or ChatGPT connect to data sources, tools and workflows (MCP introduction). In practice, enterprise connectors come in three flavours:
- Vendor-built connectors for common SaaS products, listed in the assistant's own catalogue.
- Third-party connectors published by the SaaS vendor or another developer.
- Custom remote MCP servers that a user or admin adds by URL, which may be internal tools or anything on the internet.
All three share the same shape. The assistant holds or brokers an OAuth token for the user, calls the connector's tools during a conversation, and puts the results into the model's context. Exact admin options, such as who can add custom servers, whether write actions are allowed and which plans expose which controls, vary by vendor and plan and change often. Check your vendor's current admin documentation rather than relying on any summary, this one included.
Why connectors bypass normal review
Connectors sit in a gap between three existing processes:
| Process | Why it misses connectors |
|---|---|
| SaaS procurement | No new vendor contract; the assistant is already approved |
| OAuth app review | Grants are made per user and often look like the assistant itself, not a new app |
| Network and DLP controls | Traffic goes from the vendor's cloud to the SaaS API, not through corporate egress |
The result is a classic shadow AI pattern: data moves between approved systems along a path nobody approved. Custom remote servers are the sharpest edge, because a user can point the assistant at any endpoint. That is the chat-product version of the problem described in detecting shadow MCP servers.
The risks to plan for
Data leaving its boundary
A connector moves content from the source system into the assistant's context, and from there into answers, summaries and possibly other connectors. Documents that were restricted to a team can reappear in a conversation shared more widely. Check how the vendor handles connector data for retention and training under your contract.
Over-broad OAuth scopes
Many integrations request read-write access to an entire workspace when the use case needs read-only access to one folder. The scope granted at connection time is the blast radius if the token or the assistant session is misused.
Write actions from chat
Connectors that can send messages, create tickets, edit files or change records let a prompt cause a real-world action. A prompt injection hidden in a document the assistant reads can trigger those actions on the user's behalf. Least privilege at the tool level is the main defence; see scoping MCP tool permissions.
Untrusted custom servers
A custom remote server can return poisoned tool descriptions, harvest the data sent to it, or change behaviour after approval. The vetting questions in MCP server vetting and registry risk apply to every URL a user wants to add.
Missing audit trail
The vendor's logs may show that a connector was used, but not always with the detail an investigator needs. If you cannot answer which user read what through which connector, you cannot scope an incident.
A governance model that works
1. Inventory what is connected
Start with what exists. Pull OAuth grant reports from your identity provider and from major SaaS admin consoles, export whatever connector and app usage data your assistant vendor provides, and list custom server URLs in use. This inventory is the baseline every other control depends on.
2. Default-deny custom servers
Where the admin console allows it, restrict custom remote MCP servers to admins or an approved list. Users who need a new server file a request, and it goes through the same vetting as an internally deployed MCP server.
3. Maintain an allow-list of connectors
Approve connectors one at a time with a recorded business purpose. For each, record the data it can reach, the scopes it requests, whether it can write, and the owner who answers for it.
4. Minimise scopes and write access
Prefer read-only connectors. Where write is required, limit it to specific roles or groups if the vendor supports that, and require a confirmation step for consequential actions.
5. Tie connectors to data classification
Connectors that reach confidential or regulated data need a stronger justification and a shorter review interval. Some data sources should not be connected to a general-purpose assistant at all.
6. Review and revoke
Review the allow-list quarterly, revoke unused grants, and remove connectors whose owner has left. Revocation should be tested, not assumed.
Who owns connector governance
Connector decisions cut across teams, so name the owners up front. Security owns vetting and the allow-list criteria. Identity owns OAuth grant visibility and revocation. Data protection owns the classification rules and the vendor data-handling review. The business owner of each connector answers for its purpose and its users. Without that split, connector requests stall or, more often, get approved by whoever happens to hold admin rights in the assistant console.
Checklist
The Praesidia angle
Vendor chat products enforce their own connector settings; Praesidia does not change what an admin can configure inside ChatGPT or Claude. Where it helps is the MCP layer you control. Discovery ingests telemetry from agent runtimes and surfaces MCP servers that were never formally registered, so they can be adopted into governance rather than only reported. Registered servers keep their credentials encrypted and held at the proxy, attached after policy evaluation, and an agent's access can be set tool by tool. Tool calls that pass through Praesidia are policy-gated and logged with the agent, the policy decision and the latency; calls that do not pass through Praesidia are not recorded. Discover what is connected, secure the servers you run, and prove what happened.
For the full approach, see the MCP server governance guide.