Editorial status: Human-reviewed and checked against official Anthropic and GitHub documentation on August 25, 2026. This is a configuration blueprint, not a claim that AgentField has audited Claude Code or any EDR product.

Claude Code is not merely a chatbot that suggests code. It can read and edit files, execute shell commands, start subprocesses, and call external services through MCP. That power makes it useful—and makes a permissive, company-wide rollout a security architecture decision.

The strongest deployment is layered. Claude Code policy limits what the agent is allowed to request. Its sandbox limits where commands can act. Device management makes the policy difficult for a user or repository to override. GitHub detects credentials that reach source control. Endpoint detection and response (EDR) watches the device for suspicious execution. None of these controls replaces the others.

The short version: a defensible baseline

For an organization, start here:

  1. Pilot Claude Code with non-production repositories and test identities.
  2. Keep the default interactive permission mode; centrally disable bypass and autonomous modes where appropriate.
  3. Deny reads of known secret locations and deny high-impact commands.
  4. Allow only repeatable, narrow commands that developers genuinely need without a prompt.
  5. Run shell commands inside Claude Code’s filesystem and network sandbox.
  6. Distribute non-overridable policy through the Claude admin console, MDM, Group Policy, Intune, or fleet management.
  7. Permit only approved MCP endpoints or deploy an exclusive managed-mcp.json catalog.
  8. Turn on GitHub secret scanning and push protection, protect branches, and require review.
  9. Keep EDR running and forward Claude Code telemetry into security monitoring where available.
  10. Test the effective configuration with /status, /permissions, /mcp, and controlled negative tests.

This is a starting point, not a universal policy. A developer changing documentation needs fewer capabilities than an SRE debugging production.

Start with a threat model, not a long denylist

Before writing JSON, decide what the deployment must prevent:

  • accidental deletion or destructive migration;
  • secret collection from .env, SSH, cloud, password-manager, or browser data;
  • data exfiltration over an unrestricted network path;
  • supply-chain execution through curl | sh, npx, package lifecycle scripts, or an unreviewed MCP server;
  • publication through git push, package registries, cloud CLIs, or deployment tools;
  • bypass of prompts and policy;
  • malicious instructions stored in an unfamiliar repository, issue, log, webpage, or MCP result.

A rule list cannot enumerate every dangerous shell expression. Use deny rules for clear organizational boundaries, narrow allow rules for routine work, and sandboxing or OS controls for the rest.

Understand the five configuration scopes

Claude Code settings use strict JSON—comments and trailing commas are invalid. Add the published schema URL to get editor validation.

Scope Typical location Best use
User ~/.claude/settings.json Personal defaults across projects
Shared project .claude/settings.json Reviewed team conventions committed to Git
Local project .claude/settings.local.json Personal exceptions that should not be committed
Command line --settings, permission flags A temporary session override
Managed Admin console, OS policy, or managed-settings.json Organization policy users and repositories must not loosen

The documented precedence is managed settings, command-line arguments, local project settings, shared project settings, then user settings. However, array settings such as permission rules are commonly merged and deduplicated across scopes. Do not assume that a higher-level array erases every lower-level entry. Test the effective result.

Run /status and inspect Setting sources to confirm which layers loaded. Invalid files are reported there; claude doctor can also help identify rejected configuration. A policy that exists in an MDM profile but is not loaded by the client is not a control.

A practical settings file

The following is an illustrative project baseline. Copying it unchanged is not a security assessment: adapt paths, package managers, and release commands to your environment.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(npm run lint)",
      "Bash(npm run test *)"
    ],
    "ask": [
      "Bash(npm install *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(git push *)",
      "Bash(gh pr merge *)",
      "Bash(npm publish *)",
      "Bash(rm *)"
    ]
  }
}

Rules are evaluated in the order deny, ask, allow. A matching deny wins even if another rule allows the command. This is useful for hard boundaries, but it means a broad deny can make a desired exception impossible. Prefer exact, reviewed patterns over patterns such as Bash(*).

Claude Code parses compound shell commands into separate operations for permission evaluation, but shell syntax and wrappers are still complex. Blocking only the literal string curl does not guarantee that no program can make an outbound request. That boundary belongs in the network sandbox, host firewall, proxy, and identity policy too.

What should be prohibited?

There is no universal list, but most organizations should explicitly decide how to handle these groups:

Risk Examples to review Safer default
Publication git push, gh pr merge, npm publish, deployment CLIs Deny or require a separate human-controlled workflow
Destruction rm, database drop/migration, cloud delete commands Deny broadly; execute approved operations outside the agent session
Remote execution curl, wget, npx, shell installers Ask or deny; pin reviewed dependencies and restrict egress
Credential access .env, .ssh, .aws, .kube, keychains Deny paths and remove credentials from the agent environment
Privilege changes sudo, package/system managers, service control Deny on developer endpoints
Policy bypass bypass-permission flags or modes Disable centrally

On managed clients, consider enforcing:

{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "disableAutoMode": "disable"
  },
  "disableClaudeAiConnectors": true
}

The exact setting names and availability can change; verify them in the current Claude Code settings reference. Also remember that instructions in CLAUDE.md are guidance for the model, not an enforcement boundary. Security requirements belong in permission rules, managed policy, and the operating environment.

Use the sandbox as a real boundary

Claude Code’s sandbox separates filesystem and network controls. Both matter: filesystem restrictions without egress controls can still expose readable data, while egress restrictions without filesystem controls can still permit local damage.

Use /sandbox to inspect the available configuration and keep the writable area limited to the intended repository. Do not run normal work from a home directory that contains unrelated repositories, SSH keys, cloud configuration, or personal files. For higher-risk repositories, use a disposable VM or container with no production credentials and an allowlisted network path.

Avoid bypassPermissions on a normal workstation. If a fully unattended mode is genuinely required, place it inside a separately secured, disposable environment with a minimal identity, no ambient credentials, constrained egress, immutable policy, and an independent review-and-release step.

Distribute settings so repositories cannot weaken them

A committed .claude/settings.json is good for transparent project conventions, but anyone who can change the repository can propose a change to it. Organization-wide security boundaries should be managed.

Anthropic documents several delivery options:

  • Claude admin console / server-managed settings: centrally publish policy to supported Team or Enterprise organizations. This is the clearest choice when all users authenticate through the managed Claude organization.
  • macOS MDM: deploy the com.anthropic.claudecode managed preference with Jamf or another configuration-profile system.
  • Windows management: deploy policy under HKLM\\SOFTWARE\\Policies\\ClaudeCode through Intune or Group Policy.
  • Linux fleet management: place managed files with root ownership through the organization’s configuration-management tooling.
  • System file: deploy managed-settings.json to /Library/Application Support/ClaudeCode/ on macOS, /etc/claude-code/ on Linux/WSL, or C:\\Program Files\\ClaudeCode\\ on Windows.

Managed settings have the highest documented precedence and cannot be loosened by ordinary project or user settings. For large fleets, stage the rollout: security test group, volunteer engineering group, one business unit, then general availability. Record the intended configuration version and verify it from the client rather than trusting deployment status alone.

MCP: allowlist the server, then restrict its tools

MCP extends Claude Code into GitHub, databases, ticketing systems, browsers, and internal services. A directory listing is not a security audit. Review who publishes the server, how updates are delivered, what data it receives, what scopes its token has, what tools it exposes, and whether tool output can introduce untrusted instructions.

Anthropic documents three organization patterns:

  1. allowedMcpServers / deniedMcpServers filter what users may configure.
  2. allowManagedMcpServersOnly: true makes the approved catalog authoritative.
  3. A system-level managed-mcp.json defines the exclusive set of servers; users cannot add or modify others.

For an allowlist, match a controlled URL or exact command. A server name alone is a weak identifier because the person defining a server can choose its name.

{
  "allowManagedMcpServersOnly": true,
  "allowedMcpServers": [
    { "serverUrl": "https://mcp.example.com/*" },
    {
      "serverCommand": [
        "/usr/local/bin/company-mcp",
        "--config",
        "/etc/company/mcp.json"
      ]
    }
  ],
  "deniedMcpServers": [
    { "serverUrl": "http://*" }
  ]
}

An undefined allowlist permits any server; an empty allowedMcpServers array locks MCP down. Deny entries take precedence. With a managed-mcp.json file, use MDM, Intune/Group Policy, or fleet management because Anthropic says that file is not delivered by server-managed settings.

Do not embed API keys in managed-mcp.json: users on the device may be able to read it. Prefer per-user OAuth, environment expansion backed by a secure credential mechanism, or a headers helper. Give the MCP identity the least privilege it needs and separate read-only tools from mutating tools. Then use Claude Code’s tool permissions to allow only the necessary mcp__server__tool calls rather than blindly approving every tool a server advertises.

GitHub secret scanning is the repository safety net

Denying reads of .env reduces exposure, but it cannot guarantee that a credential never appears in generated text, copied test data, a patch, or an unrecognized file. GitHub’s secret scanning detects supported credential patterns that reach a repository. Push protection can block a detected credential before the push completes and records bypass activity when repository-level protection is enabled.

Use both where your repository and plan support them, and add custom patterns for organization-specific token formats when available. Treat every alert as a possible credential compromise: remove the secret from the change, revoke or rotate it at the provider, investigate use, and clean history where necessary. Merely deleting the string in a later commit is insufficient.

Secret scanning is pattern-based. It does not prove that a repository contains no secrets, and it does not stop an agent from sending a secret through another channel. Keep secrets out of the workspace, use short-lived credentials, and constrain network access.

Why EDR still matters

Claude Code policy sees Claude Code tool requests. EDR sees endpoint behavior: process creation, suspicious child processes, persistence attempts, unexpected network connections, and other telemetry supported by the chosen product and operating system. That makes it a valuable detective and response layer if a permitted tool, package script, MCP server, or exploited process behaves unexpectedly.

EDR is not a substitute for least privilege or sandboxing, and AgentField is not claiming that every EDR product detects agent-specific attacks. Validate coverage with safe simulations: an unexpected subprocess, access to a decoy secret, an outbound connection to a test destination, and attempted persistence. Confirm alerts reach the security team and that containment does not destroy evidence needed for investigation.

For an enterprise rollout, correlate endpoint telemetry with GitHub audit events, secret-scanning alerts, identity-provider events, proxy logs, and Claude Code telemetry supported by your deployment. The goal is a reviewable chain from agent request to process, network activity, code change, and repository event.

Rollout and verification checklist

Before approving production use:

  • Claude Code is installed from an official channel and updated through a managed process.
  • Users authenticate through the intended Claude organization or API billing account.
  • Managed policy disables prohibited permission modes.
  • /status shows the expected managed source on representative macOS, Windows, and Linux devices.
  • Known secret paths cannot be read in a controlled test.
  • High-impact commands are denied or prompt as designed.
  • Filesystem writes and network egress stay inside the approved sandbox boundary.
  • /mcp shows only approved servers and tools.
  • MCP credentials are per-user, scoped, and absent from committed configuration.
  • GitHub secret scanning and push protection are configured and bypasses are reviewed.
  • Branch protection or rulesets require an independent review for agent-authored changes.
  • EDR remains active and the security team has tested alert and containment workflows.
  • A documented exception, incident-response, and offboarding process exists.

The principle to keep

Claude Code’s settings should reduce routine risk and make dangerous actions visible. They should not be asked to perform the jobs of a sandbox, identity system, source-control control, or endpoint security platform. A safe rollout uses each layer for what it can actually enforce—and verifies the result from the developer device through to the repository.

Official sources