Guide
Who controls which connectors a Claude workspace can use?
Giving an AI read-write access to production systems is a governance question before it is a technical one. Here is the control model, and the review worth running before anything gets enabled.
On Claude's team plans, governance has three layers: org admins decide which connectors exist for the workspace, each user's own sign-in to the underlying tool bounds what Claude can reach as them, and the connector itself decides which actions exist and which require explicit approval. Each layer is independently revocable.
Key takeaways
- The admin enablement step is the single control point security teams ask for: a connector that is not enabled does not exist for the workspace.
- Per-user OAuth means Claude never has its own account; it acts as the signed-in person, bounded by their existing permissions.
- The connector's own tool design is the third layer: which actions exist at all, and which wait for a human approval.
- Revocation works at every layer: disable the connector, revoke a user's token in the tool, or remove a single write action.
- Ask a connector vendor the five review questions below before enabling anything.
What does connector governance actually mean?
Deciding, deliberately, three things: which connectors a workspace can use, what each connector is allowed to do, and who can approve the actions that change or send data. On Claude's team plans those decisions map onto three independent layers, which is what makes the model auditable.
The failure mode governance prevents is not usually a rogue AI. It is sprawl: individually added integrations nobody reviewed, credentials nobody rotates, and write access nobody remembers granting. Centralized enablement replaces that with a short list someone actually approved.
This post covers the control model. For the step-by-step of getting a team live, see how to roll out a custom Claude connector to your whole team.
Layer one: what the org admin controls
Admins decide which connectors are available to the workspace at all. Members cannot use a connector the admin has not enabled, so the workspace's integration surface is exactly the approved list, not the union of everything every member ever tried. That list is the audit starting point.
In practice this turns connector adoption into a lightweight change-management process: someone proposes a connector, whoever owns the workspace reviews it, and enablement is the approval. The review is where the five questions in the checklist section belong.
Plan surfaces evolve, so verify the current admin capabilities for your plan in the Claude Help Center rather than assuming this post or any other third-party description is current.
Layer two: what per-user sign-in bounds
Each member authenticates to the connected tool as themselves via OAuth. Claude holds no master credential and no service account. Whatever a person cannot see or do in the tool, Claude cannot see or do while acting for them, and the tool's own audit log attributes every action to that person.
This is the property that makes most compliance conversations short. Access review stays where it already happens, in the underlying tool's permission model. Tightening a person's role in the CRM tightens their Claude access in the same motion, with no second system to reconcile.
It also means the tool's existing audit trail keeps working: actions taken through the connector appear under the acting user's identity, not under a shared integration account that obscures who did what.
Layer three: what the connector itself enforces
The connector decides which operations exist as tools and which of them are gated. A well-built connector separates read tools from write tools, keeps destructive and outbound actions behind an explicit human approval, and simply does not implement operations the business never wants automated. Absence is the strongest policy.
This layer is where governance gets granular. An admin enables or disables a whole connector; the connector's design decides that deleting records is not possible at all, that sending email always waits for approval, and that updating a deal stage is allowed freely.
- Actions that do not exist in the connector cannot be invoked, prompted, or tricked into running.
- Approval gates fire in the conversation, so the person sees exactly what is about to happen before it does.
- Gates are adjustable per action as trust builds, without touching the other two layers.
Our own builds follow a written safe-writes standard: if an action cannot be undone with one click, it waits for a human.
What review should a connector pass before enablement?
Five questions: What can it read? What can it write? Where is it hosted and by whom? How does each user authenticate? And which actions are gated behind approval? A vendor who cannot answer all five crisply, in writing, has answered the real question already.
For a custom connector built for you, the answers should be specific to your build, not generic marketing. Which objects, which fields, which actions, which gates.
Add one operational question for the vendor relationship itself: who maintains the connector when the underlying tool changes its API, and under what commitment? A connector that silently breaks is a governance problem too, because teams route around broken tools in unreviewed ways.
Our connector security checklist expands this into the full list an admin or security reviewer can work through.
How does revocation work when something changes?
At whichever layer fits the situation. Offboarding a person: their tool account deactivation ends their access. Retiring a connector: the admin disables it workspace-wide in one action. Tightening policy: the connector's gates or tool list change once, centrally, and apply to everyone immediately.
The layers fail safe independently, which is the property to look for in any AI integration: no single revocation path, when missed, leaves access standing.
It is worth rehearsing the retirement case before rollout: know who disables the connector and who revokes the OAuth app in the underlying tool. Five minutes of runbook beats an incident-day scramble.