Claude Code Permissions and Security: Authentication, Rules, Sandboxing, and Secrets

Claude Code needs enough authority to inspect a repository, run its checks, and make the change you requested. It does not need every credential, network destination, file, or destructive command available on the machine.

The practical security model has several layers: authentication proves which account pays for and governs the session; permission modes and rules decide which tools need approval; sandboxing limits filesystem and network reach; operating-system and cloud controls contain the process; and human approval remains the boundary for consequential actions.

This guide reflects Anthropic’s official documentation checked on August 9, 2026. Exact modes, settings keys, and supported clients can change, so validate examples against the installed client and current reference.

Authentication is not authorization

Claude Code supports Claude subscriptions, Teams or Enterprise accounts, Claude Console, Amazon Bedrock, Google Vertex AI, and Microsoft Foundry. The selected path determines billing, credential management, model access, and organizational policy. It does not by itself decide which local file or command a session may use.

Inside a session, use /status to confirm the active account and provider. From the shell, use:

claude auth status --text

Do not diagnose identity by printing an API key. If browser login is intended, use the documented OAuth flow. Use ANTHROPIC_API_KEY only for a deliberately selected API-key workflow, and inject it from a secret manager or protected environment rather than committing it to a project file.

If a credential appears in a prompt, log, screenshot, commit, issue, or pull request, assume exposure. Revoke or rotate it, remove it from future distribution, and investigate where it propagated. Merely deleting the visible line does not invalidate copies or Git history.

Begin with read and plan authority

For an unfamiliar repository or risky change, begin by asking Claude to inspect and explain without mutation. Plan mode helps keep the session read-oriented, but task scope still matters:

Inspect the repository and identify the files, tests, existing changes, and risks
for this task. Do not edit files, install packages, change Git state, contact
external services, or run a deployment.

Then authorize the smallest useful edit and validation commands. A task that changes one module normally does not need access to another repository, a cloud console, production credentials, or a broad home directory.

Permission prompts are a decision surface, not friction to eliminate. Read the complete command and target. Shell composition, redirection, command substitution, scripts, package lifecycle hooks, and environment expansion can make a short allowed prefix perform broader work than it appears to.

Understand modes, rules, and precedence

Claude Code exposes permission modes for common interaction postures, including default prompting, accepting edits, plan mode, and organization-enabled automatic or bypass modes. Use the installed client’s /help, mode indicator, and settings reference rather than assuming an old mode name still has the same behavior.

Permission rules are expressed for tools and their inputs through settings. Rules can allow, ask, or deny matching operations. A useful baseline denies sensitive paths and dangerous commands, asks for mutations and network access, and allows only recurring read or validation commands that have been reviewed.

Do not treat a deny string as a complete shell firewall. A command can invoke another program, execute a script, use a package manager hook, or reach the same resource through a different path. Rules reduce prompts and block known operations; sandbox and OS policy contain what a permitted process can actually reach.

Organization-managed settings can prevent lower settings from adding permission rules and can disable bypass permission mode. That distinction matters: a project cloned from an untrusted repository must not be able to grant itself greater authority than company policy.

Combine permissions with sandboxing

Anthropic’s managed controls can enable sandboxing and define network allowlists. The sandbox is an enforcement layer around command execution, while permission rules decide whether Claude may attempt the action. Use both.

Separate the important boundaries:

Boundary	Question
Working tree	Which repository and paths may be read or written?
Process	Which programs may start, and under which OS identity?
Network	Which domains, ports, proxies, and local services are reachable?
Credentials	Which secrets enter this process, command, or MCP server?
Data	Which records may be retrieved for this caller and purpose?
Side effects	Which deploy, send, pay, delete, or access changes need fresh approval?

Sandbox support differs by operating system. Anthropic’s current setup documentation says WSL 2 supports sandboxed execution while native Windows and WSL 1 do not. Do not claim equivalent containment across clients merely because the permission prompt looks the same.

For high-risk or untrusted tasks, use a dedicated container, VM, ephemeral cloud environment, or separate OS account with no production credentials. A trusted repository does not make every dependency, issue body, retrieved page, or generated command trusted.

Write narrow rules for real commands

Audit the prompts users repeatedly approve. Convert only stable, understood operations into narrow rules. Examples of safer candidates include a focused test runner or a read-only Git inspection command. Broad patterns such as all git, all npm, all gh, or every shell command allow unrelated mutations and network behavior.

Path scope is equally important. Allowing writes to the repository does not justify writes to SSH configuration, shell startup files, cloud configuration, credential stores, or neighboring projects. When a task needs an additional directory, add it explicitly and understand which configuration Claude discovers there.

Use hard stops for:

credential or secret-store access that the task does not require;
force pushes, history rewrites, branch deletion, and broad cleanup;
recursive deletion or commands with unresolved broad targets;
production deployments and DNS changes;
payments, purchases, emails, messages, and external publication;
account membership, roles, policies, and access changes.

An approval should bind the exact actor, action, target, and current evidence. Do not reuse “the user approved deployment” as standing authority for later environments or materially different changes.

Keep secrets outside project instructions and prompts

Never put secrets in CLAUDE.md, skills, hooks, MCP configuration committed to Git, test fixtures, or example logs. Project instructions are loaded into context, and repository files may be shared with teammates or sent to remote execution environments.

Use a secret manager, CI secret store, provider identity, or short-lived credential. Give each integration only the scopes it needs. Separate read-only automation credentials from credentials that can merge, deploy, delete, send, or change access.

Avoid common unsafe patterns:

appending a plaintext key to a shell profile;
echoing a key to check whether it exists;
passing a secret in a command-line argument visible to process listings;
storing production credentials in a project .env copied between machines;
filtering logs with a simple grep and assuming every secret is removed;
sending full request or response bodies to debugging or telemetry services.

Where supported, configure a credential helper that returns the secret at startup and keep helper output out of logs. Review provider-specific authentication precedence so an unexpected environment variable does not silently override the intended account.

Treat MCP servers as privileged integrations

MCP servers add tools, resources, prompts, and external data to the session. Review the server publisher, source, update mechanism, transport, authentication, tool schemas, network destinations, and returned content. A server’s natural-language description is not proof that its implementation stays within that description.

Use project, user, local, and managed scope deliberately. Keep credentials separate per server and environment. Anthropic’s managed settings support MCP allow and deny controls and an option to permit only managed servers. Use those controls for a fleet rather than relying on each developer to notice an unsafe package name or URL.

Retrieved MCP content remains untrusted. A document or issue can contain prompt injection that asks Claude to ignore policy, reveal secrets, or call a write tool. Enforce access before retrieval, label external content as data, restrict tools independently, and validate side effects outside the model.

Secure hooks and automation separately

Hooks execute at lifecycle events regardless of whether Claude remembers a prose instruction. That makes them valuable for deterministic validation and dangerous when they interpolate untrusted data into a shell.

Keep hooks small, fast, repository-aware, and fail-safe. Pass structured input through a parser, quote exact values, use explicit paths, cap execution time, and avoid printing environments or request bodies. Managed settings can restrict hooks and allowed HTTP hook destinations.

Non-interactive execution needs additional controls:

a fixed working directory and clean input branch;
bounded turns, timeout, cost, and output size;
explicit allowed tools and network destinations;
minimal CI job permissions;
untrusted pull-request and issue text treated as data;
structured output parsed as untrusted output;
deterministic tests after model work;
no automatic push, merge, deploy, or secret use without a separate authorized gate.

Audit the effective configuration

Security depends on the configuration actually loaded, not the file you intended Claude to read. Use /status, /memory, client diagnostics, and organization tooling to inspect the active identity, settings sources, instructions, MCP servers, plugins, and sandbox state.

Test policies with representative cases:

a permitted read;
a permitted focused test;
a write outside the repository;
a blocked credential path;
a blocked network destination;
a composed shell command that attempts to bypass the obvious rule;
an MCP result containing hostile instructions;
a deployment request that must stop for human approval.

Record the client version, operating system, settings sources, and results. Repeat after upgrades or policy changes.

Incident response checklist

If Claude Code or an integration exceeds its intended authority:

Stop the session, process, job, or affected MCP server.
Disable the implicated capability, credential, or network route.
Determine which files, services, and external systems were reached.
Rotate exposed credentials and invalidate active sessions.
Preserve sanitized audit evidence without copying secrets into a ticket.
Reconcile whether each side effect completed before retrying.
Fix the narrow enforcement gap and add a regression case.
Re-enable in a sandbox or read-only lane before restoring full authority.

The safest Claude Code setup is not the one with the most prompts or the fewest prompts. It is the one where routine, verified actions are easy; authority is proportional to the task; and a mistaken model decision cannot silently become an irreversible external action.

Continue with the setup guide, Git and parallel workflows, and hooks, MCP, and automation.