How to determine organizational settings for Claude Enterprise, considered from a security policy perspective

I'm emi, a coffee lover.

I often receive inquiries about what kinds of rules and system configurations are needed when expanding Claude usage across an organization.

Before rolling it out to general users, questions arise about how much to restrict, what users need to comply with, what administrators can configure... While it may seem like you just need to enable management features one by one, the appropriate settings actually vary depending on the organization's data classification, device management policies, and the tasks you want to delegate to Claude.

So, based on publicly available information from Anthropic, I've organized the main management features available in the Claude Enterprise plan, the differences between Claude Code configuration files, and worked through examples of how actual security policies might be translated 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 other features directly, 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 organization plans refers to a slot that allows 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 at a time.

2. Main Management Features Available in 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, they break down as follows.

A policy of simply "wanting to protect confidential information" is not enough to determine the necessary controls.
You need to clarify specific requirements—whether you want to prohibit entering confidential information into Claude at all, prevent data from being sent to external websites, delete stored data after a certain period, or whether being able to audit usage after the fact is sufficient—before finalizing configuration details.

3. Thinking About Organizational Use in Three Layers

When using Claude across an organization, it helps to break things down into the following three layers.

3-1. A Settings Common to the Entire Organization

Settings common to the entire organization using Claude, including accounts, 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 around how to handle accounts of departed employees or transfers, and how to review usage, are also related to this layer.

3-2. B Product, Library, and Access Settings

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

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

3-3. C Usage Rules and Operations

This layer defines things that cannot be controlled through Claude settings alone—what information can be entered, responsibility for reviewing generated content, exception requests, incident response, and so on. Rather than configuring 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 communications. Since it is ultimately just a prompt, there may be cases where users can use it in unintended ways depending on their instructions.

4. Settings to Prevent Incidents and Mechanisms to Review Usage

It is good to think about governance as a combination of mechanisms that stop things before they happen, mechanisms that confirm after they happen, and mechanisms that humans operate.

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 access, or command contents in Claude Code. Depending on your 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 focus on Claude Code as a concrete example of "B Product, Library, and Access Settings" among the three layers.

Claude Code settings are written in JSON format. The scope and priority of settings are determined by where the file is stored and how it is distributed.

Claude Code settings has the following scopes.

5-1. Priority Order of Configuration Sources

When the same setting is specified in multiple places, the value from the configuration source higher in the following list takes precedence in principle.

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"
}

Meanwhile, ~/.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 regular settings, 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 the JSON configuration for Claude Code. For the User, Project, and Local scopes, settings.json or settings.local.json serves as the configuration JSON; for Endpoint-managed settings, managed-settings.json is the configuration 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, the user is asked for confirmation before running 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 item inside the permissions object in a configuration JSON such as settings.json.

The behavior of each item is as follows.

Permission rules can target specific operations such as Read for reading 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 regular settings. Rules written in permissions.deny, permissions.ask, and permissions.allow are collected from multiple scopes and applied together. The rules matching the operation being attempted 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 permissions.allow in Managed settings and permissions.deny in Project settings 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 apply only the rules from Managed settings without applying permission rules added by users or projects, set allowManagedPermissionRulesOnly in Managed settings.

5-3. Sandbox and Its Role

The sandbox is a mechanism that isolates commands executed by Claude Code using OS features, restricting accessible files and communication destinations. Settings are written in the sandbox object of 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 evaluate whether a tool can be executed before Claude Code runs it. The sandbox restricts access while the executed command and its child processes are running. Use the sandbox to restrict commands allowed by permission rules from internally accessing unexpected files or communication destinations.

5-4. Distribution Methods for 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 behavior 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 needed if cloud sessions are also to be included.

5-5. How to Verify Settings

Launch Claude Code in a terminal and type /status within the interactive session. In the "Status" tab of the displayed screen, you can check the currently loaded configuration sources in the Setting sources row.

$ claude
> /status

Setting sources shows which configuration sources were loaded; it does not show which key was adopted from which source.

Below is an example display of the Status tab.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
   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

Applied permission rules can also be checked by typing /permissions within a Claude Code interactive session. Switching between the Allow, Ask, and Deny tabs lets you review the rules currently applied to each.

$ claude
> /permissions

Below is an example display of the Allow tab.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
   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 retrieval result of Server-managed settings can be checked by running claude doctor in a terminal and looking at the Managed settings (remote) row. The items displayed may change depending on the Claude Code version, so also check the official documentation at the time of use.

$ claude doctor

Below 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. Differences from ~/.claude.json

~/.claude.json is a file that holds 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 describe 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 to allow, 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 a large number of configuration keys. Extracting items that organizations are likely to consider, they break down as follows.

Only permission rules follow the handling described in 5-2. They are collected and merged from multiple scopes, then evaluated in the order deny, ask, allow.

All other keys are determined by the priority order in 5-1. Keys with a single value use 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—this varies per key, so check the Settings reference.

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

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

8-1. Preventing Claude Code from Accessing Sensitive Information

Prevent Claude Code from accessing .env, SSH keys, and cloud credentials.

Suppose you have such a policy.

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 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" are made inaccessible from Bash commands and their child processes.

permissions.deny and the sandbox control different paths. permissions.deny evaluates whether a tool can be executed before Claude Code runs it. sandbox.credentials restricts access from commands and child processes running within the sandbox.

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

Note that id_rsa and id_ed25519 are given here as examples of common SSH private keys. If you manage private keys under different filenames, include those paths in the configuration as well.

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

git push and production deployments require user confirmation before execution.

Suppose you have such a policy.

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

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

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

What constitutes a production deployment varies by organization. You need to identify not just terraform apply but also cloud service CLIs, database operations, writes to SaaS, and more.

This setting is an example that requires confirmation for operations matching specified command strings. It does not semantically evaluate whether something is a production deployment, so you also need controls for other paths such as wrapper scripts, CI/CD, cloud CLIs, and MCP.

8-3. Limiting External Communications from Commands to Approved Domains

External communications from commands launched by Claude Code should be limited to only the domains necessary for business.

Suppose you have such a policy.

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

sandbox.network is a setting that restricts communication destinations for 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 additional allowed destinations.

This setting targets communications from commands running within the sandbox. Claude Code's built-in WebFetch uses a different path and cannot be restricted by this JSON alone. To also control WebFetch, add permission rules such as WebFetch(domain:example.com) to permissions.deny or permissions.allow. Determine the allowed domains based on the services you actually use.

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 communications or execution of local commands.

Assume the following policy.

Only extensions verified by the organization may be used.

In this case, the following settings are candidates.

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

When deciding whether to allow something, consider the provider and update method, the connection destinations and data sent, and the scope of operations that can be performed.

Even with the same MCP server, there is a significant difference in impact between one that only searches internal documents and one that can create issues or operate production environments. Rather than just approving at the server level, verify what can be done with the tools provided by that server.

8-5. Standardizing the Model and Claude Code Version

Some organizations may have requirements to allow only approved models, or to prevent configuration gaps caused by outdated Claude Code versions.

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

Restricting models can help control costs, and you can ensure that only organization-validated models are used.
When restricting versions, it is good practice to also provide an update method. If only the minimum version is set without a means to update, there is a risk that users may suddenly be unable to launch Claude Code one day.

Model names and version numbers are updated regularly, so check the Settings reference at the time of use for valid values.

9. How to Proceed with Organizational Configuration

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

1. Identify users, use cases, and data being 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. Validate with a subset of users before rolling out
5. Decide how to handle exceptions and conduct periodic reviews

The JSON in this article illustrates configuration methods and is not intended for direct production use. Verify the Claude Code version and OS you are using, the impact on your work, and validate the applied results using /status, /permissions, claude doctor, and actual operations.

Closing

I studied Claude Enterprise organizational settings while thinking about what configurations are possible. Since there are many configurable items, I recommend first thinking about what you want to control rather than trying to cover everything.

I hope this article serves as a reference when considering settings that align with your organization's security policy.

For questions or feedback about this article, please contact us via "Share Your Feedback with DevelopersIO" at the bottom of the screen.

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