Four paths around the ceiling

The organization-wide connector action policy is one of the strongest controls available on a Claude Team organization, and the Technical Note on setting the ceiling, "Set the ceiling before Claude can act", explains how to use it.

Remote connectors work across Claude surfaces. The important boundary is therefore no longer "which screen am I using?" The useful question is "which control plane governs this capability?"

Four adjacent paths make that distinction clear: desktop extensions, local MCP servers, Console API keys and personal Claude accounts.

Which control plane owns the path

The connector ceiling governs connector tools. A capability that enters through another control plane needs a control in that plane. The rule is about control planes rather than a permanent count of Claude screens, and a new surface does not automatically fall inside the connector action policy because it is new.

Desktop extensions

Remote connectors and desktop extensions are different things.

Remote connectors run through Claude’s connector infrastructure and work across Claude surfaces. Desktop extensions run locally and can reach endpoint resources such as files, local applications and localhost services.

The organization connector action ceiling is therefore not the only control you need for extensions.

Team and Enterprise Owners and Primary Owners have a separate desktop extension allowlist. It is disabled by default. Until it is enabled, users can access extensions from the registry.

Enable the allowlist with a default-deny posture, then add extensions against an explicit business case.

On managed endpoints, check the Claude Desktop system policies at the same time. The machine-level policies can override the in-app extension behavior. If you intend the organization allowlist to be the operative control, do not accidentally disable the extension system in MDM in a way that prevents the allowlist from functioning as designed.

The point is not that one control is stronger than the other. They govern different layers.

Local MCP servers

Local development MCP is another endpoint capability.

Claude Desktop exposes a managed system policy named isLocalDevMcpEnabled. Team and Enterprise administrators can deploy Claude Desktop policies through MDM.

On managed endpoints, set local MCP according to the organization’s policy rather than assuming the remote connector ceiling covers it. If the organization does not permit locally defined MCP servers, disable the capability through the managed Desktop policy.

This is exactly why AI governance cannot stop at the SaaS admin console. A local capability is controlled at the endpoint.

Console API keys

A Claude Console API key is not an exception inside the Team chat organization. It belongs to another administrative plane.

Do not describe Console as having no governance. Claude Console has its own:

• Organization membership
• Roles
• API keys
• Workspaces
• Billing
• Cost and usage reporting
• Rate and spend controls

What it does not inherit is the Team organization’s connector action ceiling, seat assignment or Team usage workflow.

If business users are creating Console keys, govern that environment as its own program. Inventory who can reach Console, who can create keys, which workspaces exist, what spend controls apply and where usage is monitored.

Engineering may have a legitimate reason to use Console. That does not make it a Team-plan exception. It makes it a second governed environment.

Personal accounts

A personal Claude account carries none of the Team organization’s connector action policy.

There are several controls around that path, but Team does not have every control Enterprise has.

On managed desktop devices, Claude Desktop supports forceLoginOrgUUID. Configure it with the approved organization UUID so the Desktop application rejects authentication to an account that does not belong to the permitted organization.

On the account side, verify the corporate domain and restrict new organization creation on that domain. That prevents new personal accounts on the work domain, but does not automatically absorb existing personal accounts and does not prevent someone using a separate personal email address.

Team and Enterprise also support Enterprise-managed authentication for a current list of MCP connectors. Where a supported connector is configured to require managed authentication through the IdP, centrally provisioned access can keep personal connector identities out of that particular work tool.

Do not generalize that capability to connectors it does not support. At the time of this article, Anthropic’s documented managed-auth connector list includes services such as Slack, Notion, Linear, Asana, Atlassian and others, with Okta supported as the launch identity provider. The documented list does not mean Gmail, Google Drive and Microsoft 365 automatically receive the same managed-auth boundary.

Enterprise has two broader controls that Team does not. The first is verified-domain connector restriction. For supported connectors, including Gmail, Google Drive, Microsoft 365 and Slack, it can prevent a work identity on a verified domain from being connected to a Claude account outside the Enterprise. The second is Tenant Restrictions, where a network proxy supplies the allowed organization identifiers and Claude rejects accounts outside that set. Tenant Restrictions are documented for Enterprise plans and Console organizations, not Team.

Team can close several personal-account paths, but it does not have the Enterprise controls that bind supported work identities and network access to an approved Claude organization.

Do not claim that a generic Google Workspace or Entra OAuth allowlist solves that last row. Source-side OAuth policy can still reduce exposure by controlling which users may authorize an application, requiring admin approval or blocking an application entirely. Those are useful controls. They are not the same as proving which Claude organization initiated the OAuth connection, and Anthropic has a separate Enterprise verified-domain connector restriction for precisely that boundary.

The register

Four paths, several control planes. Record each one in the same governance register as the connector ceilings, with:

• Capability
• Governing control plane
• Configured control
• Owner
• Plan dependency
• Last verified date

When Anthropic adds a new surface or capability, do not ask only whether the feature is enabled. Ask which control plane governs it.

A control that lives in a different admin console is the one most likely to disappear from the quarterly review.

Product note. Product features change frequently, so always check current features and documentation before acting on this note. It reflects behavior as reviewed in September 2026 and is a starting point rather than a configuration reference.

Companion technical note: Set the ceiling before Claude can act

Explore this expertise: AI Platform Governance

All technical notes