Ask a CISO why they trust Microsoft Copilot and you get a clean answer. It signs in through Entra, it respects conditional access, and a personal Microsoft account can’t quietly stand in for the corporate one. The governance story is coherent, which is most of why Copilot sails through security review while other tools stall.

Now your team wants Claude. The CISO asks the obvious question: can we get it to the same bar?

Yes.

But the instinct for how it’s done is wrong, and the wrong instinct is a bit expensive.

The instinct is to reach for tenant restrictions, because the name sounds like the answer. It isn’t the lock. It’s a network control that only fires when traffic crosses your inspecting proxy, which means it does nothing the moment a laptop is off the VPN or in someone’s hand at home. The control that actually holds is one layer up, at identity: enforce single sign-on, then claim your email domain so a personal account can’t be created under it at all. That is the Copilot posture, rebuilt for Claude, and it’s the first stone of getting the tool safely into hands at all. Everything below is how, and where the sharp edge hides.

Tenant restrictions fail off the network

Anthropic does ship a tenant-restrictions feature, and it’s real. A corporate proxy injects an HTTP header, anthropic-allowed-org-ids, a comma-separated list of org UUIDs with no spaces, and Claude’s servers reject any session that isn’t in the list. The docs are blunt about the prerequisites: TLS inspection is required, and it’s Enterprise and Console plans only. Read that as what it is. The control lives on the wire, not in the account.

So picture the gap. The header gets injected only when the request passes through the proxy that does the injecting. On the corporate network, on a managed device, fine. Off the network, on a personal laptop, on a phone tethered to home wifi, there’s no proxy in the path and nothing to inject. The restriction silently doesn’t apply. For a workforce that is half-remote, that’s not a proper lock. It’s a lock that’s only engaged when you’re already inside the building.

Here’s the part that catches Microsoft-stack teams flat. They assume their existing Entra controls cover this, and reach for Tenant Restrictions v2. It doesn’t reach Claude at all. TRv2 injects its headers at Microsoft login endpoints, to govern which external Microsoft and Entra accounts your people can use. Claude doesn’t authenticate through Microsoft. Neither does ChatGPT. Turns out the flagship Microsoft control named “tenant restrictions” does nothing for the AI tools the CISO is actually worried about.

The pattern I keep seeing is a team that turns on conditional access, assumes the AI tools are covered, and only later finds out the consumer login was never in scope. There’s a Microsoft Q&A thread where one admin lays it out exactly: “Continue with Google” slips past Conditional Access, a second org replies “we have the exact same question, and suspect it isn’t possible,” and there is no accepted answer. Months of admins arriving at the same wall, and no door in it.

There’s a deeper reason identity-as-network keeps failing, and a security firm put it well: “IAM tracks logins. It misses the API token usage of a Shadow AI tool that never ‘logs in’ but authenticates via a header.” A network you can’t fully see is a network you can’t fully gate.

What does Copilot actually give your CISO?

Strip the marketing and the Copilot trust comes down to one thing: identity does the governing, not the network. You sign in to Copilot through Entra, so the same conditional-access policy that protects email protects the AI. The account is the unit of control, and the account is anchored to your tenant. There’s no separate “AI control” to bolt on, because the AI inherits the identity perimeter you already run.

That’s the bar to match.

And it tells you where to aim: at Claude’s accounts, never its traffic.

Claude can do this. Its Enterprise tier binds to your identity provider through SSO and SCIM, the same rails Entra rides, so a corporate Claude account becomes a managed object that joins and leaves with the directory. Get that in place and you’ve moved the question from “can we inspect the traffic” to “can a non-corporate account even exist.” The second question has a real answer. The first one never quite did.

But SSO alone is only half. SSO governs the corporate account beautifully and says nothing about the personal one on the same laptop. Which is the whole problem, and the reason for the next stone.

Claim the domain, and mean it

The control that closes the personal-account gap is domain verification. You prove to Anthropic that you own yourcompany.com, and then you turn on the setting that stops anyone from spinning up a personal Claude organization using a @yourcompany.com address. After that, a corporate email can only live inside your managed org. The personal-account-with-a-work-email path, the one SSO and proxies both miss, is closed at the source, because the source is the directory, not the device.

This is the move dope.security gestures at from the other side. Their pitch for ChatGPT is to inject a chatgpt-allowed-workspace-id header so OpenAI rejects non-corporate sessions, and they’re refreshingly blunt that buying ChatGPT Enterprise alone doesn’t stop personal logins. Each AI vendor has its own bespoke header, there’s no standard, and every header approach still rides the network. Domain capture is the one control that lives in the account layer and travels with the user wherever they sign in.

One real limit, because I’d rather you hear it from me. Domain capture only catches accounts created with your email. It does nothing about an employee using a personal gmail.com login to paste your data into a personal Claude. That’s a real residual gap, and it’s why this is a posture, not a switch. The domain claim shrinks the attack surface to “personal accounts on personal identities,” which you manage with device policy and culture, not with a header. Past that line the question stops being whether the account is yours and starts being whether the tool even knows who is holding it, which is a separate problem.

The one-way door

Here’s the bit the vendor blogs skip, and the reason I lead the “how” with a warning rather than a checklist.

Claiming your domain is close to irreversible, and its blast radius is your whole company. Get the scope wrong, claim a domain that also covers a subsidiary or a contractor population you didn’t account for, and you don’t get a tidy error. You get real people locked out of accounts they were using to do real work, and an unwind that runs through Anthropic support rather than a setting you can flip back. I’ve watched smaller versions of this with SSO cutovers, where a domain assumption nobody questioned took down a group nobody remembered. The domain claim is that, with the safety off.

So treat it like the one-way door it is. Map every email domain and subdomain in use before you claim anything. List the populations on each: staff, contractors, the acquired team still on their old domain, the service accounts. Decide what happens to each on the day the claim lands, and stage it, ideally alongside an SSO rollout so the managed path exists before the personal one closes. Boring? Painfully so. It’s also the difference between a quiet Tuesday and an outage with your name on it.

Nobody writes this section because it isn’t a feature, it’s a risk. The feature is one toggle. The work is everything around the toggle.

Layer the network control, don’t trust it

None of this means tenant restrictions are useless. On a managed device, on the corporate network, the anthropic-allowed-org-ids header is a fine extra layer, and a TLS-inspecting proxy injecting it adds real friction to the lazy path. Defense in depth is right here. The mistake is mistaking the outer layer for the lock.

So the order, and it mirrors the Copilot posture exactly. Enforce SSO so the corporate account is a managed object. Claim your domain, carefully, so a personal account can’t wear a corporate face. Then add the network header on managed devices as the belt to identity’s braces. Do it in that order and a security review has a coherent story to read, the same coherent story that gets Copilot waved through.

Get it backwards, lead with the proxy header and call it done, and you’ve built a control that protects the one place your data was already safe, the managed device on the corporate network, and leaves wide open the place it actually leaks. Identity first. The wire is only ever the backup.