Claude Code Is Not One Thing: What Governing It Actually Involves
I have spent the past several months working on a Claude Teams pilot: taking an AI assistant from something people were excited about to something with approvals recorded, controls in place, and evidence that those controls actually do what the documentation says they do. Much of that was ordinary enterprise groundwork. Which identity signs in. Which devices are allowed. Which folders the tool can see. Who is on the list and who is not.
Then the conversation turned to Claude Code, and I had to put several assumptions down.
The first and biggest one was that Claude Code is a product. It is not, or at least not in the way that matters for a decision. It is one capability that appears in six different places, and those places behave so differently that a judgement which is entirely sensible for one of them can be reckless for another. Working through it surface by surface took considerably longer than I expected, mostly because every time I thought I had found the boundary of the thing, there was another version of it sitting just outside.
Somebody in your organization is going to ask whether you can turn on Claude Code. The question sounds like it has a yes-or-no answer, the way “can we install Slack” has a yes-or-no answer. It does not.
This post is what I wish someone had handed me at the start. It is written for people who have to make or approve that decision without being the person who writes the policy files. No prior knowledge assumed. By the end, you should be able to read an enablement request and know which questions to ask.
First, what Claude Code actually does
Most people have used an AI assistant that answers questions in a chat window. You type, it types back, and nothing happens in the world. Claude Code is a different proposition. It reads the files on a machine, writes new ones, edits existing ones, and runs commands. If you ask it to fix a broken piece of software, it does not describe the fix. It makes the fix.
That distinction is the whole reason surfaces matter. An assistant that only talks needs very little governance. An assistant that acts needs to be told what it is allowed to touch, and you need some way of knowing afterwards what it touched. Where the assistant is running determines how much of that you can actually do.
The six surfaces
The command line. A developer types into a terminal window on their own laptop. Claude Code runs there, reads the project on that laptop, and changes files on that laptop. This is the original and still the most common way it is used. It is also the version that leaves the deepest footprint on a device, because everything happens on the device.
The code editor. The same capability, presented inside the software developers already work in, such as VS Code or JetBrains. It is a nicer window onto the same engine. The work still happens on the developer’s machine.
The desktop app. Claude Code appears as a tab inside the desktop application rather than as a terminal. It is aimed at people who want the capability without living in a terminal. Importantly, the desktop app can start several different kinds of session: one that runs on the local machine, one that runs on a remote server the user connects to, one that runs inside a Linux environment on the same machine, and one that runs on a machine in the cloud that the organization does not own. Same button, four very different situations.
The web and mobile versions. The user opens a browser or a phone, describes what they want, and the work is carried out on a virtual machine hosted by the AI provider. Nothing runs on the user’s device at all. This is genuinely useful, because it means someone can kick off a piece of work from anywhere, and it is also the surface where an organization has the least direct control.
Remote control. A user steers a session that is running on their own machine somewhere else, typically from a phone. The work happens locally, the instructions arrive remotely.
The Linux subsystem on Windows. A Linux environment running inside a Windows machine. Developers like it. It is worth calling out separately because policies applied to Windows do not automatically apply inside it.
The single question that separates them
If you remember one thing, make it this: where does the work actually happen?
Every surface falls on one side of that line. The command line, the code editor, desktop local sessions and remote control all execute on a machine the organization owns and manages. The web, mobile and cloud sessions execute on a machine the provider owns.
That line determines what you can control, because the tools organizations use to control software are almost all device tools. Application control decides which programs may run on a laptop. A network proxy decides which internet addresses that laptop may reach. Endpoint monitoring watches what happens on that laptop. Not one of those things reaches a virtual machine in someone else’s data center. They are not weakened there. They are simply absent.
Four kinds of control, and how far each one reaches
It helps to think of controls as living in four layers, ordered roughly from most central to most local.
Layer one: the switches in the admin console. Server-side toggles that an administrator flips for the whole organization. Turn the web version on or off. Turn the desktop version on or off. These take effect immediately and cannot be overridden by a user. They are the cleanest control available, and they reach every surface that has a switch.
Layer two: the central rulebook. A policy file held centrally and delivered to every session that signs in with an organization account. It can say things like “you may read files in this folder and nowhere else”, “you may not run these commands”, “you may not connect to any external tools”. It refreshes regularly and cannot be edited by the user. Crucially, it travels with the account rather than the device, which means it is the only layer that reaches every surface, including the cloud ones.
Layer three: policy files on the device. Configuration placed on a managed laptop by the IT team. This does two jobs the central rulebook cannot. It applies before the user has signed in, which closes the gap where somebody could log in with a personal account instead of a work one. And it keeps working if the central rulebook cannot be reached. It reaches only the machine it is installed on.
Layer four: the organization’s own IT controls. Application control, network filtering, endpoint monitoring, software deployment. Long-established, well understood, and confined entirely to managed devices.
Now overlay the surfaces. Local surfaces are covered by all four layers. Cloud surfaces are covered by two. That is the entire governance story in one sentence.
Three things that surprised me
These were the findings that changed how I approached the review, and all three cut against what I had assumed going in.
There is no off switch for the command line or the code editor. The admin console has toggles for the desktop version, the web version and remote control. It has none for the two surfaces developers are most likely to use. If someone can install the software and sign in with a work account, that surface exists. You can constrain what it is permitted to do through the central rulebook, and you can prevent the program from running at all through application control, but you cannot switch it off from a console. Any conversation that assumes “we’ll just leave it disabled” needs correcting on this point early.
Cloud sessions trade one risk model for another, not for a smaller one. The cloud version runs inside an isolated virtual machine, which is a real and meaningful safety property. Isolation means a mistake cannot spread to the corporate network. But you give up device monitoring, network filtering, application control, and on standard commercial plans, any record of what happened in the session. Whether that trade is acceptable depends on what the work involves. It is not obviously better or worse. It is different, and it should be decided deliberately rather than inherited by accident.
Isolation is not available everywhere. There is a sandbox feature that constrains what the assistant can reach on the machine it runs on. It works in cloud sessions and in Linux environments. On a standard Windows laptop running the command line, it does not. So the surfaces where an organization has the most control are also the surfaces where the assistant has the fewest built-in restraints. The controls have to do the work there, because the architecture is not doing it for you.
A sensible order to enable things
The instinct is often to start with the easiest surface to switch on. The better instinct is to start with the surface where you can prove your controls are working.
A defensible sequence looks roughly like this.
Start with the command line on managed devices, for a named group of people. All four control layers are available. You can restrict which folders are readable, deny the commands you do not want run, block connections to outside tools, and confirm through your own monitoring that the restrictions are holding. Accept that the code editor comes with it, because it uses the same engine and cannot be separated by policy.
Add the desktop version once the first step is proven. It reuses the same rulebook. The extra care needed is around the additional session types the desktop app offers, since turning on the desktop version without also closing off cloud, remote and Linux sessions quietly enables surfaces you did not intend to enable.
Treat the web and mobile versions as a separate decision entirely. Two of your four control layers are structurally unavailable, and on standard commercial plans there is no session record to review afterwards. There are ways to bring cloud execution back inside your own network, and there are higher-tier plans that add audit capability, but both are prerequisites rather than nice-to-haves.
Leave remote control off unless there is a real use case. It is a convenience feature. Convenience features should earn their place.
Four questions worth asking
When an enablement request lands on your desk, these will get you most of the way.
Which surface, specifically? If the answer is “Claude Code”, the request is not yet a request. Send it back.
Where will the work run? On a managed device or on a provider-hosted machine. This tells you which control layers you have.
What can it reach? Which folders, which repositories, which external tools, which parts of the network. Vague answers here are the most common cause of scope creep.
How would we know afterwards? If nobody can describe how you would reconstruct what happened in a session, you do not have a control, you have a hope.
The takeaway
Claude Code is a capability, not an application, and it appears in places with meaningfully different properties. The useful mental model is not “is this tool safe” but “which version of this tool are we talking about, where does it run, and which of our existing controls actually reach it”.
Organizations that ask those questions tend to enable Claude Code faster than organizations that treat it as one big decision, because they can say yes to the narrow, well-controlled version now instead of debating the whole thing indefinitely. Precision is not the enemy of speed here. It is the route to it.
