Claude Code Security Needs a Deployment Acceptance Record

Claude Code security is a deployment-state question. The answer changes with the installed version and interface, then with the managed-settings source and permission rules. Sandbox configuration carries its own result. MCP policy and the gateway route matter as well, alongside the model destination. Anthropic documents a working-directory prompt boundary, deny-ask-allow rule precedence, a shell-command sandbox, and managed controls that can pin Claude Code to an LLM gateway. I would reject a review that approves the product name without preserving the effective configuration and test evidence for the machine that will run it.

TL;DR

• Approve one Claude Code version and surface against the effective managed-settings source and permission mode. Record the sandbox configuration, MCP policy, gateway route, and model destination.
• Test the deny and ask behaviors, then the allow and default behaviors, with named fixtures. A narrower allow rule cannot carve through a broad deny rule.
• Treat the sandbox as a shell-command boundary. File tools and MCP servers need separate controls, as do hooks, native Windows commands, and approved unsandboxed retries.
• Pin the gateway route with managed settings and prove that a direct provider route is refused. Preserve the request record and local test evidence under one acceptance ID.

Freeze the deployment state

Start the Claude Code deployment acceptance record with the version and operating system. Add the execution surface and installation source, followed by the environment and machine population. A terminal session on macOS and a cloud session are different security surfaces. Native Windows also changes the sandbox result because Anthropic's sandboxing documentation says commands run unsandboxed there unless Claude Code runs inside WSL2.

Record every settings source that can affect the session. Name the managed file and server-managed policy. Add project settings, user settings, environment variables, and the launch wrapper. Anthropic's managed-settings documentation says managed settings apply above other settings and explains how to inspect the active source through /status. Capture that screen as text or structured output. A screenshot with a green status dot ages badly; the acceptance record needs the key and resolved value. Preserve its source and collection time, plus the collector and machine identifier.

Connect this record to the wider AI security for coding agents review. That article owns cross-vendor source exposure and delegated-action design. This record owns the installed Claude Code state and the tests that approved it.

Prove permission precedence with fixtures

Anthropic's permissions documentation states that rules are evaluated in the order deny, ask, then allow. The first match in that order decides the outcome, regardless of rule specificity. A broad deny such as a blocked command family therefore wins over a narrower allow entry.

Build three harmless fixtures in a temporary repository. First, the allowed fixture reads a synthetic file inside the working folder. Next, the ask fixture attempts a benign operation covered by an ask rule. The denied fixture invokes a harmless command string covered by the broad deny rule and a narrower allow rule. Preserve the requested tool and matched rule. Add the effective mode and user prompt, followed by the final outcome and Claude Code version.

Add one test outside the starting directory. Anthropic's security guide describes the manual-mode working-directory boundary as a permission prompt for file tools. It also warns that an approved Bash command can still write anywhere the operating-system account permits. The fixture should prove both behaviors without touching real credentials or source repositories.

Test the sandbox as a narrow boundary

The Claude Code sandbox restricts filesystem and network access for shell commands. Anthropic explicitly says the sandbox covers shell commands only. File tools and MCP servers run outside it. Hooks run outside that shell boundary as well. The acceptance record should carry that sentence beside the sandbox result so a passing shell test is never presented as proof for the whole agent.

Use a temporary folder with a visible canary such as BLUE-LOCKER-41.txt. Permit reads inside the test workspace and deny reads from the neighboring canary folder. Add one allowed network host and one denied test host. Record the shell command and operating-system decision. Add the Claude Code result and any user prompt. Then verify the setting that controls an unsandboxed retry. An approved fallback changes the security result and belongs in the evidence.

Review excludedCommands and every setting that weakens filesystem or network isolation. Managed settings can also restrict which sources may widen read paths or managed network domains. Give each exception an owner and expiry. I prefer a failed developer workflow with a named exception ticket over a quiet fallback that turns a sandbox claim into decoration.

MCP servers and hooks require their own authorization and logging. Repository writes and downstream APIs do too. The AI-generated code vulnerabilities acceptance gate covers review and scans. It also covers tests, merge protection, exception state, and release evidence after code generation. A Claude Code permission result cannot certify the resulting diff.

Pin and test the model route

Anthropic's LLM gateway documentation documents a managed route using ANTHROPIC_BASE_URL. It also describes setting allowedProviders to customEndpoint so the managed machine refuses a session pointed at Anthropic directly or at a developer-selected proxy. Store the expected gateway host and provider policy in the acceptance record.

Run a positive test through the approved gateway with a synthetic prompt. Preserve the Claude Code session identifier and authenticated enterprise identity. Add the gateway request ID and model destination, followed by the policy version and timestamp. Next, change the destination in a controlled test profile and prove that Claude Code refuses the direct route. Repeat with an unapproved developer proxy. The negative result matters more than a successful request because it demonstrates route pinning under the exact policy and machine state approved for production, rather than merely confirming basic connectivity to one destination.

Gateway logs can show the routed HTTP model call. Local shell commands and file operations need host and repository evidence, with endpoint events where applicable. Put those identifiers on one page under the same acceptance ID. If a reviewer has to compare four browser tabs by timestamp alone, the join remains unfinished.

Build the deployment acceptance record

Use one record for one version and surface under a named policy set and machine population. Include these fields:

• Deployment identity: Record the Claude Code version and installation source. Add the interface, operating system, device group, environment, and technical owner.
• Effective policy: managed source and revision, resolved permission mode, deny-ask-allow rules, sandbox settings, MCP policy, hooks policy, and collected /status evidence.
• Route control: Record the gateway host and provider allowlist. Add the credential path, approved model destinations, negative-test profile, and direct-route refusal result.
• Test evidence: working-directory prompt, permission-precedence fixtures, filesystem and network denial, unsandboxed-retry result, and route-pinning tests.
• External controls: endpoint protection, secret storage, repository permissions, branch protection, MCP server authorization, and CI evidence owners.
• Lifecycle: Record the approver and residual risk. Add exception expiry, review date, evidence owner, and change triggers.

Change triggers should include a Claude Code upgrade and a new managed-settings source. Add operating-system changes and new MCP servers or hooks. Sandbox exceptions, gateway changes, credential changes, and provider additions also expire approval. Expire approval when any trigger fires. Silent inheritance of the old green check is the failure mode this artifact is meant to remove.

DeepInspect

DeepInspect applies when Claude Code model traffic is deliberately pinned to the organization's HTTP gateway and routed through the DeepInspect proxy. It can evaluate the supplied user or agent identity and data classification before forwarding the request. The same decision covers the model destination and route policy. Its record supplies the request ID, policy version, outcome, timestamp, and gateway destination needed by the Claude Code deployment acceptance record.

Local shell execution and filesystem writes remain outside this boundary. The same applies to hooks, MCP and local tool execution, repository changes, sandbox bypasses, credentials, endpoint state, and CI. Their evidence can join the acceptance record, but a DeepInspect decision cannot stand in for those controls. Claude enterprise security covers workspace-level administration that also remains separate from this route test. Book a demo today.