Turning on Claude's connector domain restriction leaves a cleanup job behind: connections established before enablement stay connected. An administrator can block a new connection attempt and still have older grants to investigate.
Start by listing the accounts, network routes, and connected services already in use. Assign a control to each path, then remove unwanted older access. Keep the cleanup list open even after the new sign-in policy passes its pilot.
This guide combines documented behavior with a recommended verification procedure. It does not report a General Analysis deployment test. For the broader discovery program, start with how to detect shadow AI.
Choose the control by what it checks#
Use this comparison when identity, network, and SaaS administrators divide the work. The controls inspect different parts of the request.
| Control | What it checks or changes | Rollout responsibility |
|---|---|---|
| Tenant restrictions | Permitted organization IDs on inspected requests | Network team maps covered routes |
| IP allowlisting | Source IP accessing your Enterprise organization | Identity and network teams maintain access points |
| Connector domain restriction | Work-service identity connecting to a Claude account | SaaS team inventories grants and connection ownership |
| Domain claiming | Moves eligible personal Claude accounts on your verified domain into Enterprise | Identity team plans account migration |
Write the policy in terms of the path you intend to stop. "Work mailbox connected to an unmanaged Claude account" requires a different check from "our Enterprise account accessed from an unapproved network." Keeping those cases separate also makes support tickets easier to diagnose.
Treat domain capture as a migration decision: Anthropic says it cannot be reversed. Review affected accounts and complete its SSO and provisioning prerequisites before enabling it. The connector toggle does not require you to initiate that migration.
See how your AI systems hold up under real attacks
General Analysis maps AI applications and agents, red teams prompts, retrieval, tools, MCP servers, browser actions, permissions, and business workflows, then turns findings into evidence your team can reproduce and retest.
Configure the managed network path#
Anthropic documents tenant restrictions for Enterprise and Console organizations, including web, app, API-key, and OAuth authentication. An inspecting proxy inserts the organization allowlist. Use organization UUIDs, separated by commas without spaces, and overwrite the header rather than append duplicates.
Code source: Anthropic tenant restriction header format, with illustrative organization IDs.
anthropic-allowed-org-ids: 11111111-1111-4111-8111-111111111111,22222222-2222-4222-8222-222222222222
Replace both IDs with approved organizations. Put this policy at the managed proxy; a header supplied voluntarily by an employee's script is a poor enforcement boundary.
Keep configuration failures distinct from policy decisions. Anthropic documents HTTP 403 with tenant_restriction_violation for a blocked organization, and HTTP 400 for duplicate or malformed restriction headers. Networks without the restriction retain standard authentication. Record which network the request actually used before interpreting the result.
For Claude Code, proxy configuration is a separate dependency. Review HTTPS_PROXY, bypass settings, and certificate trust in the environment that launches the client. Background agents share a supervisor that can outlive the shell: deliver network variables through managed settings or ~/.claude/settings.json, then verify a background session separately. A new terminal alone does not establish coverage. Bedrock, Google, and Foundry routes use their provider endpoints; do not infer their coverage from a successful direct-Anthropic test.
Build a small route inventory before broadening enforcement: managed browser, desktop client, developer terminal, remote environment, and any approved provider route. For each, name the component that forces traffic through the intended boundary. An empty owner or an assumed route should remain an open issue.
Keep IP allowlisting separate#
IP allowlisting controls authenticated requests into your Enterprise organization. Anthropic's setup procedure asks administrators to supply approved CIDR ranges through their contact or Support. Include office and VPN exits and other required access points; an omitted range can lock users out.
Our recommendation is to review availability and account policy together. Record the approved recovery route before changing the list. During a pilot, confirm that an authorized user can still reach the workspace through the intended remote-access path. That check protects the useful workflow while you investigate unapproved paths.
Enable connector restrictions, then review older grants#
An Enterprise Owner, Primary Owner, or custom role with Identity & Access management can enable the restriction after domain verification. In Organization settings, open Organization and access, find Connector domain restriction, and enable it. The policy applies across the parent Enterprise and its children. Anthropic's connector documentation lists supported services and the current limitations.
The check permits a connection when the service does not supply enough identity information. It also permits personal services to connect in the reverse direction, into Enterprise Claude accounts. Failed attempts do not notify administrators.
Give older connections a named owner. For each approved service, ask its administrator to identify the app, user, granted scopes, and intended Claude account. Some records may identify the SaaS user without identifying the destination Claude account. Keep those cases unresolved until the owner can establish where the access belongs.
Use the service's own administration tools to remove unwanted access. In Google Admin, open Security > Access and data control > API controls > Manage App Access. Review the app's OAuth client ID and users, then use its details to inspect configured scopes. Google warns that the scope selection list can include previously requested scopes, so it may differ from the current configuration.
If you need to block that app, select the affected organizational units before changing access to Blocked. Review the impact on approved users first. An app-wide control does not by itself distinguish two Claude accounts used by the same employee. Preserve the app/client ID and affected scope of the change in your cleanup record.
Microsoft 365 needs particular care. Anthropic says its connector's server-side requests originate from Anthropic infrastructure, and network-location restrictions can block the connector for every member. A user's device location therefore cannot establish where the connector request ran. Coordinate changes with the Entra administrator and retain a representative working case when testing a restriction.
For agent execution beyond account access, use the separate Cowork security guide.
Verify the rollout with a small evidence record#
Use authorized test identities and harmless sample content. The following is an illustrative review record, not a Claude configuration file or an API schema. Give every case an expected result before running it. Keep credential values and private message content out of this record.
Code source: illustrative.
case_id: connector-migration-01
owner: identity-team
service: approved-work-service
claude_account: enterprise-test-account
service_identity: work-test-account
connection_state: established-before-rollout
expected_result: unwanted-grant-removed
observed_result: unverified
evidence_reference: null
next_action: review-with-service-admin
Use separate cases for:
- An approved organization on the managed network, to preserve the normal workflow.
- A disallowed test organization on that network, to check the account boundary.
- A new work-service connection to an outside test account, to check connector policy.
- A connection established before rollout, to confirm the specific cleanup action.
- An approved remote or provider route, to establish its own coverage.
Record the client version, route, policy revision, time, and source of the observed result alongside each case. A browser error, a proxy record, and a SaaS grant record answer different questions. Investigate disagreements between them before closing the case.
Use Claude Compliance API records for the retained evidence they actually cover. Keep the downstream service's authorization record with the cleanup case so a later reviewer can tell what access changed.
Hand the rollout over with the case results and the remaining exceptions. Assign a review date to every unresolved grant or route, and reopen affected cases when a client, connector, or network policy changes.
