Blocking Personal ChatGPT, Claude and Gemini Accounts at Work: Enforce corporate AI workspaces with tenant restriction headers

Buying an enterprise AI workspace does not stop staff signing in to the same assistant with a personal account, on the same domain, from the same corporate laptop. Corporate and consumer sessions for ChatGPT, Claude and Gemini share hostnames, so URL filtering cannot tell them apart, and blocking the domain also blocks the workspace you pay for. The working control is a tenant restriction: a proxy or browser adds an HTTP header naming the organisations that may sign in, and the provider refuses every other account on that network. This guide covers the header for each assistant, the TLS inspection and device paths that carry it, account consolidation, rollout and rollback, monitoring and framework mapping. It assumes discovery is already done; for finding AI use in the first place see the Shadow AI Discovery Guide. Products are listed alphabetically; order is not a ranking.

Key takeaways

• Header-based allowlists are the core control. Each assistant reads its own request header listing approved workspace, organisation or domain identifiers, and refuses sign-in for any account outside that list.
• TLS inspection is the price of entry. The proxy must decrypt the provider's traffic to insert the header, so the AI domains must be in scope for inspection, not on the bypass list.
• Overwrite, never append. A user or browser extension that adds its own header can widen the allowlist; configure the proxy to replace the header on every request.
• Coverage ends at the managed network path. Personal phones on mobile data and unmanaged home laptops are outside the control, so pair it with device policy and a clear acceptable use rule.
• Consolidate accounts, then block. Moving existing personal accounts on the company email domain into the corporate workspace first avoids lost work and a wave of help desk calls on enforcement day.

Why URL blocking fails and tenant restrictions work

A consumer ChatGPT, Claude or Gemini session and a corporate one use the same web application. A category or URL block therefore has two outcomes, both bad: allow the domain and personal accounts work, or block it and the sanctioned workspace breaks. Google states the point directly in its Workspace guidance: URL filtering is not a substitute because managed and consumer traffic use the same URLs.

Tenant restrictions move the decision to the provider. The network adds a header that says, in effect, "only these organisations may authenticate from here". The provider compares the signed-in account's organisation with the list and returns an error for anything else. This gives three properties a URL filter cannot:

• Identity-aware: the decision uses the organisation the account belongs to, which the provider knows and the proxy does not.
• Same-domain safe: the corporate workspace keeps working on the same hostnames.
• Provider-enforced: the refusal comes from the provider's own service, so it also covers API and desktop app traffic where the provider says it does.

It is the same pattern Microsoft and Google have long offered for their productivity suites. The Tenant Restrictions Guide covers Microsoft Entra tenant restrictions v2 and the Google Workspace header in depth; this guide applies the pattern to AI assistants.

The header for each assistant

Each provider defines its own header name and identifier. Header names in HTTP are case-insensitive; proxy vendors write them with different capitalisation.

ChatGPT

Proxy vendors that publish ChatGPT support document a ChatGPT-Allowed-Workspace-Id header whose value is the OpenAI workspace ID: Trend Micro lists it as a comma-separated list of workspace IDs, and Cato Networks lists it as the OpenAI workspace ID (UUID) and refers administrators to OpenAI's own documentation for where to find it. OpenAI's Help Center article on corporate network controls documents the header as Workspace Blocking for ChatGPT Enterprise customers, with the workspace ID taken from Admin Settings and the header applied only to requests to chatgpt.com.

• Before enabling: confirm in OpenAI's Help Center which plans support the control and which ChatGPT hosts the header must be inserted on, because the host list decides whether desktop, mobile and API traffic is covered.
• Several workspaces: list every workspace the organisation owns (for example a separate workspace for a subsidiary), or users of the missing one are blocked.
• Anonymous use: where the service can be used without signing in, a sign-in restriction alone does not stop it. Decide whether anonymous chat is acceptable; if not, add a proxy rule for unauthenticated sessions.
• Related hardening: the ChatGPT Enterprise Security Guide covers SSO enforcement, SCIM and workspace data controls once traffic is confined to the corporate workspace.

Claude

Anthropic documents tenant restrictions for Enterprise plan members and Claude Console organisations. The proxy inserts anthropic-allowed-org-ids on traffic to claude.ai, api.anthropic.com, claude.com and anthropic.com, with TLS inspection required.

• Value format: comma-separated organisation UUIDs with no spaces. For long lists, append ;n=K to the base header and place the remaining UUIDs in anthropic-allowed-org-ids1 to anthropic-allowed-org-ids{K-1}, up to 10 header lines and 500 UUIDs. Every declared continuation header must be present.
• Coverage: web, desktop and app access, API key authentication and OAuth token authentication, including artifacts.
• Blocked response: HTTP 403 with permission_error and the code tenant_restriction_violation; a malformed header set returns HTTP 400.
• Proxy behaviour: Anthropic asks that the proxy overwrite the headers on every request rather than add them only when absent.
• Test: from the restricted network, call https://api.anthropic.com/v1/messages with your organisation's API key (should succeed) and with a key from another organisation (should be refused).

Gemini

Gemini for Google Workspace users is served at gemini.google.com and through the mobile apps and Gemini in Chrome, and sign-in uses a Google account. Google's control for personal Google accounts on a corporate network is the X-GoogApps-Allowed-Domains header added to traffic to *.google.com, listing the organisation's Workspace domains. Google states that services requiring sign-in are blocked for accounts outside the list, that services which do not require sign-in are not, and that blocked users see an error naming the account and the permitted domains.

• Reserved values: consumer_accounts allows gmail.com and consumer accounts, visitor_accounts allows Drive visitors; leave consumer_accounts out to block personal accounts. Google notes gserviceaccounts.com is needed for authenticated service accounts.
• Without a proxy: on ChromeOS, the "Sign-in to secondary accounts" device setting can limit sign-in to listed domains. On managed Chrome elsewhere, the AllowedDomainsForApps policy appends the same header; the Tenant Restrictions Guide covers it.
• Breadth: the header acts on Google sign-in as a whole, not on Gemini alone, so it also blocks personal Gmail, Drive and YouTube sign-in and affects Google Cloud console and gcloud sign-in. Plan for that, and pilot to confirm the behaviour on Gemini in your environment.
• Workspace side: in the Admin console, turn the Gemini app on for the organisational units that should use it and set conversation history retention (3, 18 or 36 months). Google notes that users reaching the app as an additional service fall under consumer terms, so confirm each user's edition gives the enterprise data protections you expect.

Choosing an enforcement path

The header has to reach the provider on every request. Choose the path per device population rather than one path for all.

• Small organisations: a cloud gateway that already supports these headers usually beats building proxy rules by hand, and the Chrome policy can cover Gemini quickly on managed Chrome.
• Large organisations: expect several paths at once, and give one team ownership of the header values so that a new workspace or subsidiary is added in every path on the same day.
• Inspection exceptions: check that AI domains are not on a TLS bypass list kept for privacy or pinning reasons. The TLS Inspection Guide covers the trade-offs.
• Gateway or CASB: tenant restrictions confine sign-in; prompt-level DLP and coaching need a gateway or CASB. The AI Gateway vs CASB/SSE for Controlling Shadow AI guide compares those enforcement points.

Consolidating existing personal accounts first

Staff who have used personal accounts registered with their work email address will lose access the moment the block applies. Move them before enforcement:

1. Verify domains and enforce SSO in each corporate workspace, so that new sign-ups on the company domain land in the corporate tenant.
2. Use the provider's account consolidation feature where one exists. Anthropic's domain claim for Claude Enterprise, for example, finds personal accounts on a verified domain and gives each holder a single 30-day window to bring chats, projects and files into the workspace or start fresh; it requires DNS verification, enforced SSO and JIT or SCIM provisioning, and Anthropic marks the setting irreversible. Check the equivalent options in OpenAI and Google documentation for your plan.
3. Add everyone to the identity provider before the deadline, or they are locked out of the workspace as well as the personal account.
4. Announce the change with the date, the approved workspace URL, and how to export personal data that should not move.

Rollout, testing and rollback

1. Inventory: list every corporate workspace and organisation ID per assistant, including subsidiaries, partners whose workspaces staff legitimately use, and developer API organisations.
2. Observe: before enforcing, use gateway logs to measure sign-ins per assistant and, where the gateway reports it, the instance or account domain. This sizes the impact.
3. Pilot ring: apply the headers to an IT pilot group. Test each assistant on web, desktop app and mobile, with a corporate account (should work), a personal account (should be refused) and an API key from a non-approved organisation.
4. Check side effects: for the Google header, test Google Cloud console, delegated mailboxes, partner Drive shares and YouTube sign-in. For Claude, confirm developer tooling that calls api.anthropic.com still works with corporate keys.
5. Harden the header: set overwrite behaviour, strip user-supplied copies, and alert on header configuration errors such as Anthropic's HTTP 400 responses.
6. Widen in rings by business unit, with the help desk briefed on the error pages each provider shows.
7. Rollback: remove the header rule from the proxy or browser policy for the affected group. Record who may do this and log each use, because a silent rollback reopens personal accounts for everyone.

Detection and measurement

Log the decision at the proxy and at the provider. Useful signals:

• Refusals: HTTP 403 tenant_restriction_violation responses for Claude, Google's not-allowed sign-in error page, and ChatGPT refusals as logged by your gateway. A refusal spike after a change is expected; a steady rate shows persistent attempts worth a conversation.
• Header failures: HTTP 400 responses or traffic to AI hosts with no inserted header, which indicate an inspection bypass or a path the rule does not cover.
• Uninspected AI traffic: connections to AI domains from devices without the agent, or via DNS over HTTPS and personal VPNs. See the AI Usage Monitoring Guide.
• Workspace audit logs: new member joins and seat growth in the corporate workspace, which should rise as personal use falls.

Where identity fits

Tenant restrictions are an identity control enforced at the network edge: they decide which identity provider's accounts may authenticate. Two non-human paths need attention. API keys are covered for Claude by Anthropic's documentation, so keys issued to a personal Console organisation stop working on the corporate network, which is the intended result but can break a developer's side project in CI. Service accounts and automation that sign in to Google need gserviceaccounts.com kept in the header. Treat the workspace and organisation IDs themselves as configuration that changes through change control, since adding one ID silently admits a whole tenant. See the AI Platform Account Takeover Guide for protecting the corporate accounts that remain.

Framework mapping

Common failure patterns

• Blocking the whole domain. The sanctioned workspace breaks and users move to phones. The Samsung ChatGPT source code leak shows the pressure: after staff pasted source code into the public service, the response was a temporary restriction on generative AI tools on company devices. An approved workspace plus tenant restrictions avoids choosing between a leak and a ban.
• AI domains on the TLS bypass list. The header is never inserted and the control silently does nothing. Test from every network path.
• Appending instead of overwriting. A user-supplied header survives and admits extra organisations.
• Forgetting a workspace. A subsidiary or second Claude organisation is missing from the list and a whole team is locked out on day one.
• Google header side effects. Personal Gmail, partner Drive shares or Cloud console access break because the header acts on all Google sign-in, not only Gemini.
• Ignoring anonymous and mobile use. Sign-in restrictions do not cover logged-out chat or personal phones; policy and coaching must cover what the network cannot. See Block vs Sanction vs Coach.

Practitioner checklist

• List every corporate workspace and organisation ID per assistant, with an owner.
• Verify domains, enforce SSO and consolidate personal accounts on the company domain before enforcement.
• Bring AI domains into TLS inspection on every enforcement path.
• Insert ChatGPT-Allowed-Workspace-Id, anthropic-allowed-org-ids and X-GoogApps-Allowed-Domains with overwrite behaviour.
• Pilot on web, desktop, mobile and API with corporate and personal accounts.
• Test Google side effects and developer API keys before widening.
• Log refusals and header errors, and alert on AI traffic without the header.
• Document rollback authority and record each use.
• Update the acceptable use policy so that personal AI accounts are out of scope for work data on any device.

Standards and references

• Anthropic: Enforce network-level access control with tenant restrictions
• Anthropic: Claim and migrate accounts on your domain
• Google: Block access to consumer accounts
• OpenAI: Corporate network controls in ChatGPT Enterprise
• Google: Turn the Gemini app on or off
• Trend Micro: Adding a tenancy restriction
• Cato Networks: Managing tenant restrictions for SaaS apps
• NIST: SP 800-53 Rev 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Tenant Restrictions Guide · Shadow AI Discovery Guide · Shadow AI Policy Template · ChatGPT Enterprise Security Guide