Claude Enterprise Controls: How to Govern Claude at Work Without Killing Productivity

TL;DR. Enterprise Claude controls require three layers: discover who's using Claude (sanctioned and personal), allow only your corporate Claude.ai tenant via Cloud Application Control, and inspect prompts and uploads in real time with endpoint DLP. Anything less and a user can bypass the policy by logging into a personal Claude account on the same browser.

The Claude conversation inside most security teams sounds like this. We don't have a policy. Or we do, but nobody enforces it. Or we have an enterprise license, but half the team is logged into Claude.ai on a personal account because that's where their chat history lives. Or all of the above.

You can argue this is an AI problem. It isn't. It's the same SaaS governance problem that's been around for a decade. A useful tool shows up, employees adopt it before procurement notices, the security team gets handed the result. AI just happens faster, and the consequences (a sensitive prompt sent to a personal tenant, an upload that doesn't come back) hit harder.

Here's what enterprise Claude controls actually look like when they work.

The three-layer model

Claude governance needs three controls working together. Any one of them in isolation has a workaround. All three together is a real policy.

Layer 1: Shadow AI discovery. You can't govern Claude usage if you can't see it. The SWG needs to identify every Claude session on every device, whether it's claude.ai in a browser, the Claude desktop app, an MCP integration, or an API call from a SaaS tool that wrapped Claude into its own UI. The output is a single view: which users, which devices, which Claude surface, sanctioned or not. Without this, the rest is theater.

Layer 2: Tenant-level access (Cloud Application Control). This is the layer most companies skip and pay for later. The web filtering policy says "Claude.ai is allowed." Great. But the user who logs into the corporate workspace can also log into a personal Claude account on the same domain. Same URL, different tenant. Your SWG sees an allowed destination and lets the traffic through. The user is now pasting customer data into a personal Claude tenant on company time and company hardware.

Cloud Application Control (CAC) closes this. CAC inspects the actual tenant the user is signing into and enforces a policy that only your corporate Anthropic workspace is allowed. Personal accounts get blocked at the identity layer, not at the URL layer. Same logic applies to ChatGPT, Gemini, Google Workspace, Microsoft 365, anywhere a user can be in either a corporate or personal context behind the same hostname.

Layer 3: Prompt and upload DLP. Even inside the sanctioned tenant, employees will paste things they shouldn't. Source code with credentials. Customer PII. Patient data. Earnings figures. M&A documents. The DLP layer needs to inspect the prompt and any attached file before it leaves the device, classify it, and either block, warn, or log based on policy. Dopamine DLP does this on-device with zero-retention APIs, so the prompt being inspected for sensitive content doesn't itself get retained or trained on. (Read more about how AI DLP actually works.)

Three layers. Discover, restrict to your tenant, inspect what gets typed. Skip any one and the policy has a hole the size of a browser tab.

Why URL blocking alone fails

Most companies start with the easy answer: block claude.ai entirely. This breaks in three predictable ways.

First, you're blocking the tool your team wants to use. Productivity loss is real. So is the rage ticket from the engineer who can't get to documentation autocomplete because IT blanket-blocked an AI domain. Within two weeks, an exception gets requested, the exception gets granted, and the policy is back where it started.

Second, you're not actually blocking Claude. You're blocking one of Claude's surfaces. The user can still use Claude through Slack apps, through API-wrapped SaaS tools, through Cursor, through every other piece of software that quietly added Claude as a backend in the last 18 months. The "Claude is blocked" memo is true on one URL and false everywhere else.

Third, you're encouraging the behavior you're trying to stop. When the corporate path is blocked, the personal path is what's left. Users tether to a phone, use a home laptop, or just type the prompt into a personal Claude account on their phone. Your data leaks anyway. You just lost visibility.

The "block it all" policy is the easiest one to write and the hardest one to enforce. The better approach is to allow Claude, enforce which Claude, and inspect what goes in.

What a working Claude policy looks like

A reasonable enterprise Claude policy in 2026 has four lines.

One, employees may use Claude for work-related tasks via the corporate Anthropic workspace. Personal Claude accounts are not permitted on corporate devices. Two, the following data types may not be entered into Claude prompts or uploads under any tenant: source code with secrets, customer PII, PHI, payment data, M&A material, board minutes, customer lists with contact info. Three, all Claude activity is logged centrally for compliance review. Four, exceptions go through the security team and have a time limit.

The policy is the easy part. Enforcing it without the three-layer stack above is what trips most teams up.

The enterprise stack, ranked by effort

You can get there in three deployment moves.

The first move is shadow AI discovery on whatever SWG you're running today. Most SSE platforms can identify Claude traffic if you tell them to look. Pull the report, see who's using what, and segment your population. You probably have more personal Claude usage than you think.

The second move is CAC. This is where most legacy SWG stacks fall over. Cloud Application Control at the tenant level requires the agent to inspect identity context inside the session, not just the URL. If your current SWG can't do this for Claude (or ChatGPT, or Gemini, or any of the AI tools), you've found the gap that needs to close. dope.security ships CAC as part of the core platform. (Read the broader sanctioned-vs-unsanctioned governance picture.)

The third move is endpoint DLP on AI prompts and uploads. Dopamine DLP intercepts file uploads and AI prompts, classifies them via zero-retention APIs, and applies one of three modes: Block, Monitor, or Off. Block stops sensitive content from leaving. Monitor logs without blocking, useful while you tune the policy. Off is for opt-in test rollouts. (Patent number 12,464,023, in case your procurement team needs it.)

Three moves. Same console. Same agent. Same policy model.

Where to start

If you're trying to lock down Claude usage this quarter, the fastest test is to run a 14-day pilot of dope.security on a sample group: one engineering team, one finance team, one sales team. Turn on shadow AI discovery, lock the population to your corporate Anthropic workspace via CAC, and put Dopamine DLP in Monitor mode for the first week so you can see the prompts users were sending before you decide which patterns to block. End of week two, you have a real picture, a real policy, and a clear conversation with leadership about what enforcement is actually catching.

Start a free trial or book a 20-minute demo. Same console, three layers, one agent. Claude stays useful. The data stays where it belongs.