> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/handbook/1.-identity-and-access/1.3-tenant-restrictions-blocking-personal-accounts.md).

# 1.3 Tenant restrictions: blocking personal accounts

How to block personal AI accounts using tenant restrictions, organization headers, proxies, browser controls, detection, and exception handling.

*Last reviewed: August 18, 2026*

{% hint style="info" %}
Personal accounts can bypass the controls you configured for the enterprise workspace. Tenant restriction is the control family that keeps corporate users on managed accounts when they use AI tools on corporate devices, browsers, and networks.
{% endhint %}

## Tenant restrictions: what security teams need to know

Most AI governance programs start inside the managed workspace. That is necessary, but it leaves a simple escape path. A user can open the same AI service in a browser, desktop app, mobile app, CLI, or third-party wrapper and sign in with a personal account. Once that happens, enterprise SSO, SCIM, RBAC, retention, audit, and DLP may no longer apply.

Tenant restriction is the set of controls that closes that escape path. It can include network policy, browser policy, endpoint controls, domain capture, managed app deployment, device posture, proxy inspection, and user education. The goal is to make the managed tenant the normal path and the personal tenant the blocked or detected path.

Vendors implement tenant restriction differently. Some platforms expose formal tenant restriction headers or proxy controls. Others provide domain capture, SSO, workspace switching, app control, or role-level restrictions but do not provide a direct network-level tenant lock in public documentation. Confirm which category your vendor falls into before promising a hard block.

## Common tenant restrictions security failures

* Browser access is controlled, but desktop and mobile apps are left unmanaged.
* The managed workspace has SSO, but personal accounts on the same corporate email domain still exist.
* Endpoint agents and secure web gateways classify the domain as allowed without checking whether the account is managed.
* Developers use API keys, local CLIs, or IDE extensions outside the enterprise identity path.
* The security team assumes vendor controls exist because similar controls exist in other SaaS platforms.
* A block applies only on the corporate network, while remote users or mobile users route around it.

## Tenant restrictions security controls checklist

* Inventory every access surface: web, desktop, mobile, CLI, IDE, browser extension, API, and third-party embedded AI.
* Require managed app deployment where desktop or mobile apps are approved.
* Enforce managed configuration on developer surfaces, such as Claude Code managed settings and Codex managed configuration, so local CLI and IDE installs follow organization policy rather than personal defaults.
* Use SSO and SCIM to make the managed account path easy and reliable.
* Use domain capture or account consolidation where the vendor supports it.
* Configure secure web gateway, browser extension, and endpoint controls to detect personal-account use where direct blocking is not available.
* Treat personal-account uploads of regulated or confidential data as a policy event.
* Document which controls are hard blocks, which are detections, and which are user-process controls.
* Test from a managed laptop, unmanaged browser profile, mobile device, and developer CLI.

## Anthropic

### Overview

Anthropic documents Tenant Restrictions for Enterprise and Console customers. A corporate proxy injects an `anthropic-allowed-org-ids` header, and Anthropic blocks authentication to organizations outside the allowed list. The control covers Claude web, desktop and app access, API-key authentication, and OAuth-token authentication. It requires TLS inspection and only applies on networks where the proxy injects the header, so unmanaged networks and devices still need identity, endpoint, and egress controls.

Claude Tag needs a separate Slack boundary. Its member restriction is off by default, and the Enterprise RBAC capability does nothing until an owner enables the restriction. Claude Tag is disabled by default in channels containing guests and does not operate in Slack Connect channels, but admins should still restrict which workspaces, channels, DMs, connections, and repositories it can use.

### Anthropic documentation

* [Manage custom roles on Enterprise plans](https://support.claude.com/en/articles/13930452-manage-custom-roles-on-enterprise-plans)
* [Enforce network-level access control with Tenant Restrictions](https://support.claude.com/en/articles/13198485-enforce-network-level-access-control-with-tenant-restrictions)
* [Restrict where Claude Tag operates](https://claude.com/docs/claude-tag/admins/restrict-access)

### Applicable Harmonic guides for Anthropic

* [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide)

## OpenAI

### Overview

OpenAI documents that ChatGPT Enterprise users can move between enterprise workspaces and personal workspaces through the workspace switcher, and that personal workspaces under company email addresses may be subject to deletion or merge into the enterprise workspace. OpenAI also documents Lockdown Mode, but Lockdown Mode limits web and external-service access. It is not a tenant-restriction control for blocking personal account sign-in.

The OpenAI documentation reviewed for this guide does not describe a tenant-restriction header equivalent, so treat OpenAI personal-account control as a mix of workspace management, account-consolidation behavior, RBAC, SCIM, endpoint and browser governance, and detection. For Codex on developer machines, managed configuration lets organizations set approval policy, sandbox behavior, and MCP-related settings centrally, which keeps local installs inside organization policy rather than personal defaults.

### OpenAI documentation

* [Managing members, seat types, roles and access in ChatGPT Enterprise](https://help.openai.com/en/articles/8266401-managing-members-seat-types-roles-and-access-in-chatgpt-enterprise)
* [Lockdown Mode](https://help.openai.com/en/articles/20001061)
* [RBAC](https://help.openai.com/en/articles/11750701-rbac)
* [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration)

### Applicable Harmonic guides for OpenAI

* [Securing ChatGPT Enterprise Guide](https://www.harmonic.security/resources/securing-chatgpt-enterprise-guide)

## Frequently asked questions about tenant restrictions

### Is blocking the AI domain enough?

Only if the organization has decided no one should use the service. If the service is approved, the harder problem is allowing the managed tenant while blocking or detecting personal accounts.

### Should this live in identity, network, or endpoint?

All three usually have work to do. Identity owns managed sign-in and lifecycle. Network and browser controls handle web paths. Endpoint controls cover desktop apps, local agents, CLIs, and unmanaged browser profiles.

### Can we force employees onto the enterprise ChatGPT or Claude workspace?

Anthropic documents a network-level Tenant Restrictions header for Enterprise and Console organizations, but it only applies where a managed proxy injects the header. OpenAI documents account consolidation behavior but not an equivalent tenant-restriction header in the sources used here. Pair the vendor controls with endpoint, browser, and secure web gateway detection for unmanaged paths.

### How can teams detect personal AI account use?

Use browser, endpoint, secure web gateway, and identity logs to compare approved AI domains with managed-account signals. Treat unmatched usage as a review event, especially when corporate data appears in prompts or uploads.

### Does Lockdown Mode block personal ChatGPT accounts?

No. OpenAI documents Lockdown Mode as a role-level security configuration that limits outbound web and external-service access to reduce prompt-injection data exfiltration. It governs what a managed account can do inside the workspace, not which account a user signs in with.

## Applicable regulations and frameworks

| Governance page                                     | Relationship to this article                                                                                                    |
| --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| G.1 Map your controls to NIST AI RMF and CSF 2.0    | This article supplies implementation evidence for the NIST AI RMF and matching NIST CSF 2.0 outcomes.                           |
| G.3 DORA and AI resilience in financial services    | Conditional: for a DORA-regulated workflow, this supports identity and access control.                                          |
| G.5 SANS Critical AI Security Guidelines mapping    | This article implements relevant SANS Access Controls guidance.                                                                 |
| G.6 Write an AI Acceptable Use Policy that holds up | This article supplies a technical or process control used to enforce the acceptable-use policy.                                 |
| G.7 Ownership and RACI for AI security              | This control depends on the ownership and evidence responsibilities defined in the RACI.                                        |
| G.9 HIPAA controls for AI systems handling PHI      | Conditional: for a workflow handling ePHI, this supports HIPAA identity, authentication, least privilege, and workforce access. |

*G.2, G.3, G.4, and G.9 are conditional mappings. They apply only when the deployment is within the legal or regulatory scope described on the linked governance page.*

## Related handbook guidance

* [1. Identity & Access](/handbook/1.-identity-and-access.md)
* [1.1 SSO & SCIM for AI platforms](/handbook/1.-identity-and-access/1.1-sso-and-scim-for-ai-platforms.md)
* [1.4 Domain claiming: bringing shadow accounts into enterprise](/handbook/1.-identity-and-access/1.4-domain-claiming-bringing-shadow-accounts-into-enterprise.md)
* [G.6 Write an AI Acceptable Use Policy that holds up](/reference/governance-and-frameworks/g.6-write-an-ai-acceptable-use-policy-that-holds-up.md)
* [7.1 Roll out by risk: the phased plan](/handbook/7.-rollout-and-operations/7.1-roll-out-by-risk-the-phased-plan.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://handbook.harmonic.security/handbook/1.-identity-and-access/1.3-tenant-restrictions-blocking-personal-accounts.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
