Deploying Claude Code in the enterprise: the CIO and CISO guide

Since version 2.1.283, Claude Code no longer asks permission before acting. Sessions opened in a terminal or in VS Code start in auto mode: a second model, the classifier, examines actions in place of the user. This change arrived through an update, without your decision.

For a solo developer, it's a convenience. For an organisation, it's a delegation: a program reads files, modifies them, executes commands and connects to the network on your teams' workstations, according to rules that no one in your organisation has written.

This guide is for those who must write those rules. It doesn't revisit the tool's use from the developer side, already covered in the CCA-F lesson on Claude Code configuration. It addresses what an IT department and a security officer must decide, configure and verify before rolling out the tool.

1. What Claude Code actually does on a workstation

An online assistant responds in a browser window, and you copy the result. Claude Code works in your folders. It exists in four forms that rely on the same engine: the desktop application, the command line, the extensions for editors (VS Code, JetBrains) and the web version, which executes in virtual machines managed by Anthropic.

For the beginner: four actions

Everything the tool does comes down to four actions.

• Read: open files, search in a folder.
• Write: create or modify files.
• Execute: launch commands, as you would in a terminal.
• Connect: call a website, an API, an internal service.

The first two remain within the working directory. The last two can touch everything the user has permission to touch: the database, the shared repository, the cloud infrastructure.

For the expert: where what runs

The model doesn't run on the workstation. Claude Code sends the context to the model provider, receives an action request, executes it locally with the user's permissions, then sends back the result. Two consequences follow. The tool's permissions are those of the account that launches it, no more, no less. And everything the tool reads can leave for the model provider with the next request.

2. The six permission modes

A permission mode determines the actions the tool can launch without asking you. The choice of mode decides who validates: you, a classifier, a pre-established list, or no one.

For the beginner: what has changed

Until recently, the starting mode was manual mode: the tool asked before each modification and each command. Starting from version 2.1.283, interactive sessions in a terminal and in VS Code start in auto mode, across all offerings and with all providers. The first time, the tool displays a notice. After that, nothing reminds you, except a line in the status bar.

For the expert: the order that decides the starting mode

When launching a session in a terminal, Claude Code retains the first source that applies:

1. the --permission-mode option passed at launch;
2. the permissions.defaultMode key in a settings file;
3. the built-in mode, i.e. auto since 2.1.283.

Two details carry weight. A repository cannot grant itself auto mode: the auto value is ignored when it comes from a project's .claude/settings.json file. And sessions launched without interaction (claude -p, Agent SDK) don't follow quite the same rule: check their starting mode on your version before putting them in an integration chain.

3. The classifier: what it sees, what it blocks, where it stops

In auto mode, a second model examines actions before their execution. It blocks what exceeds the request, what targets infrastructure it doesn't recognise, and what seems dictated by hostile content read along the way. The documentation warns bluntly: auto mode reduces confirmation requests, it doesn't guarantee security.

For the beginner: a guard, not a safe

Imagine a guard at the entrance to a warehouse. He stops what seems abnormal to him, and he has good reflexes. He doesn't know your company: he doesn't know which server is production and which folder contains the contracts, as long as no one has told him.

What it blocks by default

Among the documented blocks:

• downloading code then executing it;
• sending sensitive data outside;
• deploying or migrating to production;
• force pushing, or cancelling uncommitted modifications in the repository;
• destroying files that existed before the session;
• granting permissions on a repository or cloud account;
• modifying DNS records, certificates or a secrets manager;
• merging a pull request that no human has approved.

What it lets through

Local operations in the working directory, installation of already-declared dependencies, read-only requests, and pushing to the repository you're working on. This last point often surprises: in auto mode, pushing to the current repository is permitted by default, main branch included. If you want a human checkpoint before each push, you need an ask rule (section 4).

For the expert: the evaluation order

Three limitations are worth knowing before relying on it.

It doesn't read tool results. The classifier sees your messages, tool calls and the content of your CLAUDE.md files. Results are removed from what it receives, so that trapped content in a file or web page can't manipulate it. It's a protection, and also a blind spot: it judges the action without seeing what it returned.

An instruction said in the conversation can be lost. If you write "don't push before my review", the classifier blocks corresponding actions. But this limitation isn't recorded as a rule: it rereads it in the history at each check. When the context is compacted and the message disappears, the limitation disappears with it. For a guarantee, the documentation refers to a deny rule.

It pauses when it blocks too much. After 3 blocks in a row or 20 total in a session, auto mode suspends and confirmation requests return. These thresholds aren't configurable. Repeated blocks generally signal that the classifier is missing a description of your infrastructure.

4. The allow, ask and deny rules

Modes set a general level. Permission rules refine it, tool by tool and command by command. They're evaluated before everything else.

For the beginner: three verbs

• allow: this action passes without asking.
• ask: this action always asks for confirmation, even in auto mode.
• deny: this action is forbidden.

A deny rule blocks in all modes, including bypass mode. It's the only firm guarantee in the entire mechanism, and it's where you should start.

For the expert: a foundation to adapt

The example below brings together the rule forms shown in the documentation. Paths and commands should be replaced with yours, then tested on a workstation before any deployment.

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "allow": [
      "Bash(npm test)"
    ]
  }
}

Four points of attention.

Broad rules fall in auto mode. Upon entering auto mode, Claude Code removes allow rules that authorise arbitrary execution: a general Bash(*), an interpreter with wildcard like Bash(python*), package manager launch commands. Narrow rules, like Bash(npm test), remain. They all return when leaving auto mode.

A rule applies to the command as written. A rule on git push doesn't see a push launched from a script. Don't count on a Bash rule to forbid an effect: forbid access to what makes the effect possible, and keep protection on the server side (protected branches, account permissions).

Some paths are protected by default. Writes to .git, .vscode, .claude, shell configuration files or .mcp.json are never automatically approved, except in bypass mode. An allow rule doesn't change that.

An ask rule remains a checkpoint in auto mode. It's the right tool to keep a human in front of a push, deployment or infrastructure command without giving up the rest of auto mode.

5. Managed settings: imposing a policy across the organisation

A setting placed by each developer in their corner doesn't make a policy. Managed settings are settings that the organisation deploys on each workstation. Claude Code applies them above all other levels: neither the user, nor the project, nor a launch option replaces them.

For the beginner: four ways to deliver policy

The file goes here:

• macOS: /Library/Application Support/ClaudeCode/managed-settings.json
• Linux and WSL: /etc/claude-code/managed-settings.json
• Windows: C:\Program Files\ClaudeCode\managed-settings.json

For the expert: a starting policy

{
  "permissions": {
    "defaultMode": "default",
    "disableBypassPermissionsMode": "disable",
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)"
    ]
  },
  "allowManagedPermissionRulesOnly": true
}

This file does four things: it starts sessions in manual mode, it forbids bypass mode, it blocks two reads, and it makes permission rules coming from the user, project and launch options ignored. To also remove auto mode, add "disableAutoMode": "disable" in the permissions block. Without this key, setting defaultMode changes the starting mode, but anyone can still switch to auto during the session.

On a workstation, run /status in Claude Code: the "Setting sources" line should display enterprise settings and their source. The claude doctor command lists entries the tool discarded because they were invalid.

What the policy doesn't cover

Four blind spots are written in black and white in the documentation, and it's better to know them than to discover them.

• Only one mechanism applies by default. When several sources deliver a policy to the same workstation, Claude Code retains the highest-ranked one and ignores the others, without warning. Server-managed settings come before MDM, which comes before file.
• Cloud sessions don't read the workstation. A session executed in an environment hosted by Anthropic has neither MDM profile nor local file. Its policy must come from server-managed settings.
• A local administrator can modify the source. That's why MDM redeploys the profile at regular intervals.
• The policy only binds Claude Code. A developer calling the API from another tool isn't concerned. API key control remains a separate subject.

6. The sandbox and isolation

Modes decide whether the tool asks before acting. Isolation decides what an action can reach once launched. Both combine and don't replace each other.

For the beginner: the closed room

A sandbox is a closed room in which the command executes. Even if it makes a mistake, it can only touch what's in the room. Claude Code includes a sandbox for shell commands, available on macOS, Linux and WSL2.

For the expert: three levels

• The built-in sandbox. It activates with the /sandbox command or the sandbox.enabled key. By default, a command executed in the sandbox has no network access. Allowed domains are declared in sandbox.network.allowedDomains, and the sandbox.network.allowManagedDomainsOnly lock makes any list not coming from managed settings ignored. The file system follows the same logic, with allow and deny lists in read and write.
• The container or virtual machine. It's the only acceptable framework for bypass mode. On Linux and macOS, Claude Code actually refuses to start in this mode with root privileges, except in a recognised sandbox.
• The dedicated workstation. For teams that touch production, a workstation or remote session without direct access to secrets remains the simplest measure to explain and audit.

The documentation proposes a useful compromise for those who don't want the classifier: manual mode associated with the sandbox in automatic acceptance. Commands pass without confirmation as long as they stay in the closed room, and deny rules continue to apply.

7. MCP connectors and servers

An MCP server gives Claude Code new tools: querying a database, reading a ticketing tool, controlling a browser. Each added server widens what the tool can reach, and therefore what trapped content can make it do. Your guide on the 40 tools to install says which are worth it. This section says who decides to plug them in.

For the beginner: the question to ask

For each connector, three questions suffice. What data does it give access to? Who wrote it and who maintains it? What can it send outside?

For the expert: available locks

• allowedMcpServers and deniedMcpServers: the list of permitted servers and that of forbidden servers.
• allowManagedMcpServersOnly: when it's true, only the allow list coming from managed settings counts. The deny list, however, accumulates from all sources.
• managed-mcp.json: a file deployed alongside managed settings to provide the organisation's servers.
• disableClaudeAiConnectors: cuts claude.ai account connectors.
• strictKnownMarketplaces and blockedMarketplaces: frame the sources from which extensions can be installed.

A trap to know: a malformed allow list is applied as an empty list. No server added by users is then admitted until the value is corrected. It's the right behaviour for security, and a source of support tickets if no one is warned.

8. Data: what leaves, where, and for how long

Claude Code executes on the workstation, but the model is remote. To work, the tool sends over the network the session context: your requests, file extracts, command results.

For the beginner: two regimes

Everything depends on the contract under which the tool is used.

• Commercial offerings (Team, Enterprise, API, third-party cloud platforms): Anthropic indicates it doesn't train its models with code and requests sent, unless the client has chosen to provide their data. Standard retention is 30 days.
• Consumer offerings (Free, Pro, Max): retention is 30 days, or 5 years if the user has agreed for their data to help improve models. The setting belongs to each person.

The practical consequence is immediate: a developer using their personal subscription on company code does so under the consumer regime, with their own settings. It's the first point to check in an inventory.

For the expert: three levers

• Zero retention. It exists for Claude Code on the Enterprise offering. It's not included by default: it activates per organisation, after validation with the publisher.
• The provider. Claude Code also works through Amazon Bedrock, Google Cloud's agent platform and Microsoft Foundry. Processing, region and contract are then those of your cloud provider. Warning: in this case, server-managed settings aren't retrieved, and policy must come from MDM or a file.
• Telemetry. The tool sends by default operational metrics and error reports. The DISABLE_TELEMETRY variable, delivered in the env block of managed settings, cuts it for all affected workstations. It also cuts the data that feeds your organisation's usage dashboard: it's a trade-off, not a neutral setting.

To compare what each publisher does with the data they receive, the Trust Index documents models one by one.

9. Costs

Three items make up the bill, and the third is often forgotten.

• Access. Claude Code requires a paid subscription (Pro, Max, Team, Enterprise) or a usage-billed account.
• Model consumption. It depends on the chosen model, context size and level of effort requested. A long task in auto mode consumes without anyone watching.
• The classifier. On the Enterprise offering, on API accounts and with cloud providers, its calls count in consumption. Each check sends part of the history and the pending action. Reads and modifications in the working directory don't pass through it: the additional cost mainly comes from commands and network access.

For the expert: three settings that count

• Restrict models. A model set in managed settings is only a default value, which the user can change for their session. To actually limit the choice, it's the availableModels key that must be deployed.
• Cap effort. The maxEffortLevel key sets a ceiling that no source can raise.
• Track usage. The organisation has a usage dashboard. Look at it during the pilot, not after the first bill.

To estimate a model's cost by volume, the Cost Engine does the calculation on each model card on nAIvigate.

10. The deployment plan by population

A single policy for the entire company is either too strict for developers or too loose for those who touch production. Break down by population.

The five stages

1. Inventory. Who already uses the tool, under what subscription, in what version, on which repositories. Version matters: below and above 2.1.283, the starting mode isn't the same.
2. Write the foundation. Deny rules, bypass mode prohibition, starting mode by population. One page suffices.
3. Pilot. A volunteer team, two to four weeks, with tracking of classifier blocks and consumption. Wrong blocks say what needs to be declared in trusted infrastructure.
4. Deploy. Through the mechanism corresponding to your workstation management, checking on one workstation before scaling.
5. Train and review. Teams need to know what each mode does and why a verbal instruction doesn't replace a rule. The policy is reread at each notable evolution of the tool: this one is proof.

11. Ten mistakes to avoid

1. Leaving the starting mode at factory setting. It has already changed once without warning.
2. Taking the classifier for a guarantee. The publisher itself says otherwise.
3. Counting on an instruction said in the conversation. It disappears with the message that carries it.
4. Authorising bypass mode on a workstation. Its place is in a container.
5. Setting defaultMode believing you've removed auto mode. You also need disableAutoMode.
6. Stacking two delivery mechanisms unknowingly. Only one applies, and the other is ignored silently.
7. Forgetting cloud sessions. They read neither the MDM nor the workstation file.
8. Letting any connector be plugged in. Each MCP server widens what the tool can reach.
9. Tolerating personal subscriptions on company code. The data regime isn't yours.
10. Discovering classifier cost on the bill. It's measured during the pilot.

Test your understanding

Frequently asked questions

Should auto mode be forbidden? Not on principle. On a development workstation, with deny rules, declared trusted infrastructure and a sandbox, it reduces confirmation fatigue, which itself pushes to validate without reading. On a workstation that touches production, I would remove it.

Is manual mode really safer? It is as long as the human reads what they validate. After the fiftieth confirmation of the day, that's no longer the case. Security comes from rules and isolation, which the mode doesn't replace.

Can you prevent a developer from bypassing the policy? On the tool, yes: managed settings aren't replaced by any personal setting. A local administrator can however modify the source, and the policy doesn't cover other tools that call the API.

Do settings apply to the desktop application and extensions? Yes for the terminal, VS Code and JetBrains extensions and the Code tab of the desktop application, which read the same sources. Cloud sessions follow a different rule (section 5).

Can Claude Code work with a model other than Anthropic's? Through a gateway, yes, with variable compatibility depending on models. Auto mode, however, requires a recent supported model: on another model, the session starts in manual mode.

Where to start if nothing is in place? With an inventory of versions and subscriptions, then with three lines in a managed settings file: starting mode, bypass mode prohibition, and deny rules on your secrets.

To go further

The practical guide "Claude Code starts in auto mode" summarises this guide in one page, to display or send to a team. The CCA-F lesson on Claude Code configuration covers the developer side: CLAUDE.md files, commands, skills, continuous integration.

If you need to set these configurations in your organisation and train the teams who will use them, that's the subject of the audit, implementation and training path in the Studio.

To see where you stand, the Claude Code configuration checker scores your settings file and produces the corrected file, with nothing sent anywhere.

Sources

• Claude Code documentation, Choose a permission mode: the six modes, starting mode by version, classifier, protected and critical paths.
• Claude Code documentation, Deploy managed settings: delivery mechanisms, source order, keys reserved for managed settings, verification.
• Claude Code documentation, Data usage: training policy, retention periods, telemetry.
• Mickael Dorigny, « Installation et utilisation de Claude Code : premiers pas », IT-Connect, 2 October 2026.

Documentation consulted on 5 October 2026. Version numbers and configuration keys evolve quickly: verify them on your version before writing your policy.