I thought about how to determine organizational settings for Claude Enterprise, starting from security policy

I'm emi, a coffee lover.

As organizations expand their use of Claude, I've been getting many questions about what rules and system settings are needed.

Before rolling out to general users, how much should be restricted, what should users be required to follow... It might seem like you can just enable management features one by one, but in practice the appropriate settings vary depending on the organization's policies.

So, based on publicly available information from Anthropic, I've organized the main management features available in the Claude Enterprise plan, the differences in Claude Code configuration files, and so on, and considered examples of how to translate likely real-world security policies into organizational settings.

1. Claude Plans

The following plans are available.

Note that Claude can be used in two ways: employees using chat, Claude Code, and similar tools, and Claude Platform, which uses the API to integrate Claude into your own services. This article covers the former — organizational use.

1-1. What is a "Seat"?

A "seat" in organizational plans is a slot for one user to use Claude. Organizations purchase seats in bulk and assign them to members. For example, the Team plan's "maximum 150 seats" means the organization can have up to 150 users assigned simultaneously.

2. Main Management Features Available in the Claude Enterprise Plan

SSO, SCIM, role-based access control, spend controls, audit logs, Compliance API, data retention controls, and more are offered as Enterprise features.

https://www.anthropic.com/product/enterprise

Organized by what each feature manages:

A policy of simply "wanting to protect confidential information" isn't enough to determine what controls are needed.
The specific requirements—whether you want to prohibit entering confidential information into Claude altogether, prevent data from being sent to external websites, delete stored data after a certain period, or simply be able to audit usage after the fact—determine what settings are required.

3. Thinking About Organizational Use in Three Layers

When using Claude in an organization, it helps to think in three layers.
These settings can be reviewed by opening [Organization Settings] from the username in the bottom left of the Claude web interface.

A: Settings Common to the Entire Organization

Settings that apply across the entire organization using Claude, including account, authentication, data retention, spend, and auditing.

Examples include SSO using the organization's IdP, adding and removing users via SCIM, and access control by role. Policies for handling accounts of departing or transferred employees and how to review usage are also related to this layer.

B: Product, Library, and Access Settings

Claude Enterprise allows you to manage products such as Claude Code and Cowork, plugins, connectors, skills, and more. You configure availability, connection targets, sharing scope, and execution permissions.

For Claude Code, you can upload a settings.json from the organization's admin console and distribute it as Server-managed settings. The distributed settings are applied at the top-level settings hierarchy called Managed settings. You can control executable commands, accessible files, communication destinations, MCP servers, and more.

C: Usage Rules and Operations

This layer covers things that cannot be controlled through Claude settings alone—such as what information may be entered, who is responsible for reviewing generated content, how exceptions are requested, and how incidents are handled. Rather than Claude settings, this involves defining and enforcing user behavior and internal rules.

Incidentally, you can write prompts as "organization instructions" in Claude's admin console, but that alone cannot technically and reliably block file access or external communication. Since it is ultimately a prompt, users may be able to use Claude in unintended ways depending on their instructions.

4. Settings to Prevent Incidents and Mechanisms to Review Usage

Governance is best approached as a combination of mechanisms that stop things before they happen, mechanisms that review what happened afterward, and human-operated processes.

The Compliance API is a mechanism for retrieving activity events, chat data, file contents, audit log events, and more, and integrating with existing tools such as DLP and SIEM to monitor, detect, and audit usage.

https://dev.classmethod.jp/articles/claude-enterprise-compliance-api-overview/

The Compliance API does not record all tool executions, local file accesses, or command contents in Claude Code. Depending on audit requirements, combine the Compliance API, audit logs, Claude Code's OpenTelemetry, and device/network-side logs.

5. Scope of Claude Code Configuration Files

From here, I'll use Claude Code as a concrete example of "B: Product, Library, and Access Settings" from the three layers.

Claude Code settings are written in JSON format. The scope and priority of settings are determined by where files are stored and how they are distributed.

Claude Code settings has the following scopes:

5-1. Priority Order of Setting Sources

When the same setting key is specified in multiple locations, in principle the value from the setting source higher in the following list takes priority.

1. Managed settings
2. Command-line arguments at startup
3. .claude/settings.local.json
4. .claude/settings.json
5. ~/.claude/settings.json

For example, suppose .claude/settings.json has the following setting:

{
  "model": "fable"
}

And ~/.claude/settings.json has the following setting:

{
  "model": "opus"
}

Since .claude/settings.json has higher priority than ~/.claude/settings.json, the model used is fable.

Managed settings have the highest priority, and for normal setting keys, users cannot override values specified by the organization with their own settings.

5-2. Permission Rules and How They Are Applied

Claude Code executes operations such as reading and editing files, running shell commands, and accessing the web as "tools." You can configure whether to deny these operations, ask the user for confirmation, or allow them without confirmation. These settings are called "permission rules."

Permission rules are written inside the permissions object in Claude Code's settings JSON. For the User, Project, and Local scopes, the settings JSON is settings.json or settings.local.json; for Endpoint-managed settings, it is managed-settings.json.

For example, configure as follows:

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

In this example, reading .env is denied, users are asked for confirmation before executing git push, and npm test is allowed to run without confirmation.

In this article, hierarchy within JSON is expressed using dot notation such as permissions.deny. permissions.deny refers to the deny key inside the permissions object in settings JSON like settings.json.

The behavior of each key is as follows:

Permission rules can target operations such as Read for reading specific files, Bash for executing shell commands, and WebFetch for accessing the web. Target operations are specified as rules like Read(.env) or Bash(git push *).

Permission rules are applied differently from normal setting keys. Rules written in permissions.deny, permissions.ask, and permissions.allow are collected from multiple scopes and applied together. The rules matching the attempted operation are then evaluated in the following order:

1. permissions.deny (deny execution)
2. permissions.ask (ask for confirmation before execution)
3. permissions.allow (allow execution without confirmation)

For example, if Managed settings' permissions.allow and Project settings' permissions.deny both match the same operation, that operation will be denied. This is not because Project settings overrode Managed settings, but because deny was evaluated first among the permission rules collected from multiple scopes.

If you want to use only the Managed settings rules without applying permission rules added by users or projects, set allowManagedPermissionRulesOnly in Managed settings.

5-3. Sandboxing and Its Role

The sandbox is a mechanism that isolates commands executed by Claude Code using OS features, restricting the files that can be accessed and the communication destinations. Settings are written in the sandbox object in settings.json. According to Configure the sandboxed Bash tool, supported environments are macOS, Linux, and WSL2.

The main objects in sandbox are as follows:

Permission rules and the sandbox differ in when they intervene. Permission rules determine whether to allow or deny a tool before Claude Code executes it. The sandbox restricts access while the executed command and its child processes are running. If a command permitted by permission rules accesses unexpected files or communication destinations internally, use the sandbox to restrict it.

5-4. How to Distribute Managed Settings

Managed settings is the scope for settings distributed by the organization. There are two distribution methods:

When both are distributed simultaneously, they are not merged by default. Which one is adopted depends on the priority of the distribution source, so verify before using both together.

If devices can be managed with MDM, Endpoint-managed settings, which can prevent tampering at the OS level, provides stronger guarantees. Server-managed settings are required if cloud sessions also need to be covered.

5-5. How to Verify Settings

Launch Claude Code in the terminal and enter /status in the interactive session. In the "Status" tab of the displayed screen, check the Setting sources line to see the currently loaded setting sources.

$ claude
> /status

Setting sources shows the loaded setting sources and does not display which key was adopted from which source.

Here is an example of what the Status tab looks like:

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
   Settings  Status   Config   Usage   Stats

   Version:          2.1.219
   Session name:     /rename to add a name
   Session ID:       xxx
   cwd:              xxx
   Login method:     Claude Enterprise account
   Organization:     xxx
   Email:            xxx

   Model:            opus[1m] (claude-opus-5[1m])
   MCP servers:      4 connected, 20 need auth · /mcp
   Setting sources:  User settings, Project local settings, Enterprise managed settings (remote)

   System diagnostics
    ⚠ xxx

The applied permission rules can also be checked by entering /permissions in the Claude Code interactive session. Switch between the Allow, Ask, and Deny tabs to see the rules applied to each.

$ claude
> /permissions

Here is an example of what the Allow tab looks like:

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
   Permissions  Recently denied   Allow   Ask   Deny   Workspace

   Claude Code won't ask before using allowed tools.
   ╭───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
   │ ⌕ Search…                                                                                                                                     │
   ╰────────────────────────────────────────────
     1.  Add a new rule…
     2.  Bash(.venv/bin/pip freeze *)
     3.  Bash(.venv/bin/python -c ' *)
     4.  Bash(.venv/bin/python xx)
     5.  Bash(xx)
     6.  Bash(xx)
     7.  Bash(xx)
     8.  Bash(xx)
     9.  Bash(xx)
   ↓ 10. Bash(echo "EXIT_CODE=$?")

   ←/→ to switch · ↓ to select · Esc to cancel

The result of fetching Server-managed settings can be checked by running claude doctor in the terminal and looking at the Managed settings (remote) line. The items displayed vary by Claude Code version, so also check the official documentation at the time of use.

$ claude doctor

Here is an example of the output:

emiki@<hostname>:~/xx$ claude doctor
Claude Code doctor

Running: npm-global (2.1.248)
Commit: 8c9482ad0510
Platform: linux-x64
Path: /home/emiki/.npm-global/lib/node_modules/@anthropic-ai/claude-code/bin/claude.exe
Config install method: global
Search: OK (bundled)
Auto-updates: enabled
Auto-update channel: latest
Last update attempt: failed (install_failed) — 2026-09-02
Managed settings (remote): loaded

Remote Control
xx

No installation issues found.

For a full setup checkup that can also fix issues, run /doctor in a Claude Code session.
emiki@<hostname>:~/xx$ 

5-6. Difference from ~/.claude.json

~/.claude.json is a file that holds state such as sign-in status and per-project state. Its role differs from settings.json, which is used to write configuration settings.

6. Difference in Roles Between settings.json and CLAUDE.md

In Claude Code, you can write project structure, build commands, coding conventions, and more in CLAUDE.md.

settings.json configures behavior and permissions such as which model Claude Code uses, which operations are permitted, and which files and communication destinations can be accessed. CLAUDE.md is for passing ongoing instructions and project information to Claude.

7. What Can Be Configured in Claude Code

The Settings reference lists many setting keys. Here is an excerpt of items that organizations are likely to consider:

Only "Commands / Tools" follows the handling in 5-2. Rules are collected from multiple scopes and merged, then evaluated in the order deny, ask, allow.

All other keys follow the priority order in 5-1. Keys with a single value adopt the value from the highest-priority scope. Keys with lists may either be merged from multiple scopes or use only the list from the highest-priority scope — which behavior applies differs per key, so check the Settings reference.

8. Thinking About settings.json Configuration from Organizational Security Policies

From here, let's consider examples based on organizational security policies.

8-1. Preventing Claude Code from Accessing Secret Information

Suppose the following policy exists:

Do not allow Claude Code to access .env files, SSH keys, or cloud credentials.

Access via Claude Code's built-in file tools can be denied with permissions.deny. However, this does not prevent all access via commands. To restrict at the OS level, use credentials in the sandbox.

Here is an example JSON to place in Managed settings:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(secrets/**)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/credentials)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "credentials": {
      "files": [
        {
          "path": ".env",
          "mode": "deny"
        },
        {
          "path": "~/.ssh/id_rsa",
          "mode": "deny"
        },
        {
          "path": "~/.ssh/id_ed25519",
          "mode": "deny"
        },
        {
          "path": "~/.aws/credentials",
          "mode": "deny"
        }
      ],
      "envVars": [
        {
          "name": "GITHUB_TOKEN",
          "mode": "deny"
        }
      ]
    }
  }
}

"sandbox" contains the sandbox-related settings. enabled enables the sandbox, credentials.files specifies files to protect, and credentials.envVars specifies environment variables to protect. Items with mode set to "deny" cannot be accessed by Bash commands and their child processes.

permissions.deny and the sandbox control different pathways. permissions.deny determines whether to allow or deny before Claude Code executes a tool. sandbox.credentials restricts access from commands and child processes running inside the sandbox.

The sandbox does not automatically identify credentials. If SSH keys, cloud service configuration files, or environment variables storing tokens not covered by the above example exist, add them according to your organization's environment.

Note that id_rsa and id_ed25519 are shown here as examples of common SSH private key filenames. If private keys are managed under different filenames, include those paths in the settings as well.

8-2. Requiring Human Confirmation for Production Deployments and External Writes

Suppose the following policy exists:

Require user confirmation before executing git push or production deployments.

{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(terraform apply *)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "allowManagedPermissionRulesOnly": true
}

permissions.disableBypassPermissionsMode disables the bypassPermissions mode that skips permission confirmation. The value is the string "disable", not a Boolean.

Enabling allowManagedPermissionRulesOnly allows you to use the Managed settings rules—rather than User, Project, or Local permission rules—as the basis for permission evaluation.

What counts as a production deployment varies by organization. It is necessary to identify not only terraform apply but also cloud service CLIs, database operations, writes to SaaS, and similar operations.

This setting is an example that requires confirmation for operations matching the specified command strings. It does not semantically determine what constitutes a production deployment, so controls for other pathways such as wrapper scripts, CI/CD, cloud CLIs, and MCP are also needed.

8-3. Restricting External Communication from Commands to Approved Domains

Suppose the following policy exists:

Limit external communication from commands launched by Claude Code to only business-required domains.

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": [
        "github.com",
        "api.github.com",
        "registry.npmjs.org"
      ],
      "strictAllowlist": true,
      "allowManagedDomainsOnly": true
    }
  }
}

sandbox.network restricts the communication destinations of Bash commands and their child processes. Specify allowed domains in allowedDomains and use strictAllowlist to deny unregistered destinations. Enabling allowManagedDomainsOnly also prevents users from adding their own allowed destinations.

This setting targets communication from commands running inside the sandbox. Claude Code's built-in WebFetch uses a different pathway, so it cannot be restricted by this JSON alone. To also control WebFetch, add permission rules like WebFetch(domain:example.com) to permissions.deny or permissions.allow. Determine the domains to allow based on the services actually used.

8-4. Preventing Use of Unmanaged MCP, Hooks, and Plugins

MCP, Hooks, and plugins allow you to integrate Claude Code with internal systems and development workflows. Some of these involve external communication or execution of local commands.

Assume the following policy:

Only allow extensions that the organization has reviewed.

In this case, the following settings are candidates:

strictKnownMarketplaces is not a setting for approving individual plugins, but a setting that limits the marketplaces from which plugins can be added and installed. These keys have exceptions and prerequisites, so verify their behavior in the official documentation before applying them.

Decisions on whether to allow something should be based on the provider and update method, connection destinations and data transmitted, and the scope of executable operations.

Even with the same MCP server, one that only searches internal documents and one that can create Issues or operate production environments have very different impact scopes. Don't just approve at the server level—also verify what each tool provided by that server can do.

8-5. Standardizing the Model and Claude Code Version Across the Organization

Some organizations may have requirements such as allowing only approved models to be used, or preventing configuration gaps from older versions of Claude Code.

Since availableModels alone does not restrict the default selection, combine it with enforceAvailableModels when standardizing organization-wide.

Restricting models can help control costs and ensure that only organization-verified models are used.
When restricting versions, it's a good idea to also prepare an update method. If only a minimum version is set with no means of updating, users may suddenly find themselves unable to launch Claude Code one day.

Model names and versions are updated frequently, so check the Settings reference at the time of use to confirm valid values.

9. How to Approach Organizational Settings

Stricter settings are not necessarily better. To avoid blocking necessary work through restrictions, consider in the following order:

1. Identify users, use cases, and data to be handled
2. Decide which operations to prohibit and which to allow
3. Translate into organization-wide management settings, Claude Code Managed settings, and usage rules
4. Verify with a subset of users before rolling out broadly
5. Decide on exception handling and periodic review procedures

The JSON in this article is intended to illustrate configuration methods and is not meant for direct production use. Verify the applied results using /status, /permissions, claude doctor, and actual operations, while checking the Claude Code version, OS, and impact on business operations.

Closing

I studied Claude Enterprise organizational settings and thought about what kinds of settings are possible. There are many configurable items, so rather than trying to cover everything, I recommend first thinking about what you want to control.

I hope this article is helpful when considering settings that align with your organization's security policies.

Questions and requests about this article can be submitted via the "Feedback for DevelopersIO" section at the bottom of the page.

References

https://support.claude.com/en/articles/11049762-choose-a-claude-plan

https://support.claude.com/en/articles/9266767-what-is-the-team-plan

https://support.claude.com/en/articles/9797531-what-is-the-enterprise-plan

https://www.anthropic.com/product/enterprise

https://docs.anthropic.com/en/docs/claude-code/enterprise-setup

https://code.claude.com/docs/en/settings

https://code.claude.com/docs/en/settings-reference

https://code.claude.com/docs/en/permissions

https://code.claude.com/docs/en/sandboxing

https://support.claude.com/en/articles/13015708-access-the-compliance-api