Is Claude Code Safe to Use at Work? A Decision Guide for 2026

Yes, Claude Code can be safe to use at work, but only once your organization configures it rather than accepting each laptop's defaults. Use a commercial plan so your code is not used for training, push managed settings that turn on the sandbox and lock permission rules, restrict MCP servers and plugins, and keep a person reviewing every change before it merges.

Any tool that can run npm install can do damage, so the real question is who decides which actions run, what boundary contains a wrong decision, and what record exists afterward. This guide answers that for engineering managers and security leads. Every fact about Claude Code and Anthropic below comes from Anthropic's own documentation, read on 22 October 2026. Claude Code changes quickly, so check the linked pages before you write policy around a specific version number.

Key takeaways

• The default no longer asks first. Interactive terminal and VS Code sessions on v2.1.283 and later start in auto mode, where a classifier model reviews actions instead of you.
• Permission rules are enforced by Claude Code, not the model, but Bash rules match command text, not programs. A real boundary needs the OS level sandbox.
• The sandbox is off by default and covers shell commands only. File tools, MCP servers, hooks and plugin processes run outside it.
• Commercial plans are not used for training. Consumer plans are, if the user leaves that setting on. Standard commercial retention is 30 days.
• Transcripts sit on the laptop in plaintext under ~/.claude/projects/ for 30 days by default, including anything a tool read.
• Admins can lock settings centrally through the claude.ai admin console, MDM or a managed settings file.
• Regulated data needs a specific setup: HIPAA coverage requires a BAA plus the HIPAA configuration or zero data retention.
• Roll out in stages: pilot, guardrails, then wider access with telemetry in your own collector.

What can a coding agent read, run and send by default on a developer laptop?

The starting permission mode

Per Anthropic's permission modes page, a session's mode comes from the --permission-mode flag, then permissions.defaultMode in settings, then the built in default:

A repository cannot quietly change this for its contributors: "auto" in a project's .claude/settings.json does not take effect, and "bypassPermissions" there is ignored. On Team and Enterprise plans, auto mode is available by default until an administrator disables it in managed settings.

What auto mode lets through

In auto mode, explicit allow, ask and deny rules resolve first. Read only actions and file edits inside the working directory are approved outright. Everything else goes to a classifier, which tells Claude why it blocked something, usually with a rule name such as [Data Exfiltration]. Anthropic notes that the classifier's input excludes tool results, so hostile text in a file or web page cannot address it directly.

The default block list includes curl | bash style download and execute, sending sensitive data to external endpoints, production deploys, mass cloud deletion, granting IAM or repository permissions, force pushes, destructive git resets, terraform destroy, merging a pull request no human approved, and printing a live credential into the transcript.

The default allow list is where security teams should slow down. Per the same page, auto mode allows installing dependencies declared in your manifests or lock files, reading .env and sending credentials to their matching API, read only HTTP requests, and pushing to any branch of the current repository, including the default branch, apart from deploy targets such as production. Print the full lists with claude auto-mode defaults. For a company, "push to the default branch" and "read .env" are decisions you may want to keep with a person, and server side branch protection is the right place to enforce the first.

What Manual mode does

In Manual mode (the default setting), Claude Code starts read only. Per the permissions page, file reads inside the working directory and a built in set of read only commands such as ls, cat and git status run without asking. Edits, other shell commands, most web fetches and web searches prompt. Unmatched commands require approval, and a command Claude Code cannot fully analyze prompts even if part of it matches an allow rule.

One detail most people miss: the security page says the working directory boundary is a permission prompt, so a Bash command you approve can still write anywhere your user account can. For an OS boundary you need the sandbox.

What leaves the machine

Anthropic's data usage page says prompts and model outputs go to the model provider over TLS 1.2 or later. Whatever the agent reads to answer you, file contents and command output included, becomes part of that conversation. Claude Code also sends operational telemetry by default on the Claude API, and WebFetch sends the requested hostname to api.anthropic.com for a safety check before fetching.

What do permission modes, sandboxing and network egress settings actually enforce?

Sort every control by who enforces it. Anthropic's documentation is unusually explicit about this.

Permission rules: real, but scoped

The permissions page states that rules are enforced by Claude Code, not by the model, so a prompt injection that persuades the model still has to get past them. Rules evaluate deny, then ask, then allow, and the first match wins regardless of specificity. A deny rule naming a whole tool, such as Bash, removes it from Claude's context entirely.

The limit is just as explicit. A Bash rule matches the command text Claude writes. Anthropic's own table shows that a deny rule for Bash(curl *) stops curl https://example.com but not /usr/bin/curl https://example.com or sh -c 'curl https://example.com'. In the docs' words, such a rule "isn't a security boundary around the program." Treat Bash deny rules as guardrails, not as a control you would cite to an auditor.

Read deny rules such as Read(./.env) block built in file tools and recognized commands, but per the docs not grep -r pattern . or a script that opens files itself. A .claudeignore file has no effect; move its entries into Read deny rules.

The sandbox: the boundary the OS enforces

Anthropic's sandboxing page describes a boundary the operating system enforces around shell commands and the processes they start, built on the open source @anthropic-ai/sandbox-runtime package. On native Windows, commands run unsandboxed; use WSL2. Key facts:

• Off by default. Turn it on with /sandbox or sandbox.enabled: true.
• Writes are limited to the working directory, a temp directory and added directories. Protected paths such as .git stay write denied.
• Reads cover most of the machine by default, including ~/.ssh and ~/.aws/credentials. The docs say there is no built in credential deny list.
• Network: no direct route out. A local proxy checks each hostname against allowed domains, which start empty.
• Environment variables are inherited, secrets included, unless you use sandbox.credentials or CLAUDE_CODE_SUBPROCESS_ENV_SCRUB.
• Escape hatch: Claude can ask to retry a failed command unsandboxed. allowUnsandboxedCommands: false closes that, and failIfUnavailable stops a silent fallback when the sandbox cannot start.

Network egress limits

The proxy decides by hostname and, by default, does not inspect TLS. Anthropic warns that allowing a broad domain such as github.com can create an exfiltration path, and that code in the sandbox could potentially use domain fronting. It also warns that allowing a Unix socket like /var/run/docker.sock effectively grants host access. For companies, strictAllowlist refuses unlisted hosts instead of prompting, and allowManagedDomainsOnly honors only the organization's domains.

What runs outside the sandbox

Per the sandboxing page: Read, Edit, Write, WebFetch and WebSearch; command hooks; local MCP servers; plugin monitors; LSP servers; helpers such as apiKeyHelper; commands you type at the ! prompt in most sessions; excluded commands; approved unsandboxed retries; and processes started by mods. To put all of that behind one boundary, Anthropic recommends running the whole Claude Code process in a dev container, a VM or the sandbox runtime. The docs add that effective sandboxing needs both filesystem and network isolation; either one alone leaves a path out.

What happens to our code and prompts?

Training

Anthropic's data usage page splits by plan. On Free, Pro and Max, the user chooses, and Anthropic trains on that data when the setting is on, Claude Code included. Under commercial terms (Team, Enterprise, API, third party platforms and Claude Gov), Anthropic does not train generative models on code or prompts sent to Claude Code, unless the customer opts in, for example through the Development Partner Program. If developers use personal accounts on company code, training depends on a toggle each person controls. Company use belongs under commercial terms.

Retention

Per the ZDR page, ZDR is not part of the standard Enterprise plan. Anthropic enables it per organization after confirming eligibility. It does not cover claude.ai chat, Cowork, analytics metadata, or data processed by third party tools and MCP servers, and it disables cloud sessions, artifacts, feedback and Remote Control. Even with ZDR, Anthropic may retain a flagged session's inputs and outputs for up to 2 years.

Feedback is a separate channel: transcripts sent with /feedback, /bug or /share are retained for 5 years. Encryption at rest is AES-256 on the Anthropic API, with customer managed key options on Amazon Bedrock and Google Cloud's Agent Platform.

Telemetry

Usage metrics never include code, prompts or file paths, per Anthropic. Turn channels off with DISABLE_TELEMETRY=1, DISABLE_ERROR_REPORTING=1, DISABLE_FEEDBACK_COMMAND=1, or all non essential traffic with CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC. On Bedrock, Agent Platform, Foundry and Claude Platform on AWS, metrics, error reports and feedback are off by default.

What stays on the laptop

Anthropic's .claude directory page says session files are plaintext and anything that passes through a tool is written to a transcript: file contents, command output, pasted text. Transcripts in ~/.claude/projects/ are swept after cleanupPeriodDays, default 30. Prompt history in ~/.claude/history.jsonl stays until deleted, except under the HIPAA configuration. A .env value a tool read ends up in the transcript. So "what happens to our code" has two answers: what Anthropic keeps, set by your plan, and what each laptop keeps, set by your endpoint controls.

What are the real 2026 attack paths?

Rather than repeat third party claims we could not verify, here are the attack paths Anthropic's own documentation designs against.

Prompt injection through repository content and web pages

Text in a README, issue, comment or web page can try to redirect the agent. Anthropic's defenses include the permission system, not auto approving curl and wget, summarizing most web fetches through a separate model call, and keeping tool results out of the auto mode classifier. Its advice: review suggested commands, avoid piping untrusted content to Claude, verify changes to critical files, and use VMs for work that touches external services. See opening an untrusted repo with an AI coding agent.

Repository configuration that runs before you expect

A repository can ship hooks, an env block, skills, subagents and an .mcp.json. The workspace trust dialog is the gate, but the permissions page shows that hooks and the env block are used in claude -p and SDK runs, which never show the dialog, and .mcp.json servers connect there without asking. For headless runs on code you did not write, Anthropic's advice is --setting-sources user or --bare, plus --settings '{"disableAllHooks": true}'. This matters most in CI pipelines that point an agent at outside pull requests.

MCP servers

The security page says Anthropic reviews connectors against listing criteria before adding them to its directory, but it does not audit or manage any MCP server. By default anyone can connect any server, and local servers run outside the sandbox. Anthropic's managed MCP page adds that a serverName allowlist entry "is not a security control," because users choose names. Enforce with serverUrl and serverCommand. Background: is it safe to install an MCP server.

Plugins and auto update

Plugins can bundle skills, agents, hooks and MCP servers. Per the plugin admin page, marketplaces with autoUpdate refresh in the background, and plugins with a command source re-run that command every session, even with DISABLE_AUTOUPDATER set. A plugin you reviewed last month may not be the one running today. Restrict sources with strictKnownMarketplaces, and see whether coding agent plugins and skills are safe to install.

Git configuration and protected paths

Some files turn a write into later code execution: .git, .gitconfig, shell profiles, .npmrc, .husky, .pre-commit-config.yaml, .mcp.json. Anthropic lists these as protected paths. Writes to them prompt in Manual mode, go to the classifier in auto mode, and are never pre approved by an allow rule, except in bypassPermissions mode, which the docs reserve for isolated containers or VMs and say offers no protection against prompt injection.

Dependencies the agent adds

Auto mode allows installing declared dependencies by default, so the agent can change your dependency tree and run install scripts as part of ordinary work. That is a supply chain decision. See whether AI coding agents add vulnerable dependencies.

Where do secrets leak?

Anthropic also documents masking, where sandboxed commands see a placeholder and the proxy substitutes the real credential only for allowed hosts; it needs TLS termination and is honored only from user, managed or command line settings. For more, see how to stop an AI agent reading .env files and how infostealers steal developer and AI agent tokens.

What managed settings and policies should an admin lock down centrally?

How policy reaches machines

Anthropic's managed settings page lists four delivery routes carrying the same keys: server managed settings from the claude.ai admin console (polled hourly), an MDM profile in the com.anthropic.claudecode domain or the HKLM\SOFTWARE\Policies\ClaudeCode registry key, a managed-settings.json file at /Library/Application Support/ClaudeCode/, /etc/claude-code/ or C:\Program Files\ClaudeCode\, and the HKCU registry as a last resort. Managed values override user, project and command line settings. Anthropic-hosted cloud sessions only read server managed settings, and Cowork sessions never fetch them, so plan policy per surface.

A starting policy

This file uses only keys documented by Anthropic. Adapt it; replace the IDs and domains.

{
  "forceLoginMethod": "claudeai",
  "forceLoginOrgUUID": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "permissions": {
    "defaultMode": "default",
    "disableBypassPermissionsMode": "disable",
    "deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)"],
    "ask": ["Bash(git push *)"]
  },
  "allowManagedPermissionRulesOnly": true,
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "network": {
      "allowedDomains": ["registry.npmjs.org", "pypi.org", "files.pythonhosted.org"],
      "allowManagedDomainsOnly": true
    },
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  },
  "allowManagedMcpServersOnly": true,
  "allowedMcpServers": [{ "serverUrl": "https://mcp.example.com/*" }],
  "strictKnownMarketplaces": [{ "source": "github", "repo": "your-org/*" }],
  "disableSideloadFlags": true,
  "cleanupPeriodDays": 14,
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "https://otel.example.com:4317",
    "DISABLE_FEEDBACK_COMMAND": "1"
  }
}

What it does, per Anthropic's docs:

• Login keys force claude.ai sign in to your organization and refuse API key sessions. A wrong UUID locks everyone out, so check it.
• defaultMode: "default" starts in Manual mode. Add "disableAutoMode": "disable" under permissions to keep auto mode off during the pilot.
• allowManagedPermissionRulesOnly stops repositories and users adding their own allow rules.
• The sandbox block enforces the sandbox, closes the unsandboxed retry, limits egress and hides credentials. failIfUnavailable makes Claude Code exit on native Windows, so target macOS and Linux or move Windows users into WSL2.
• MCP and plugin locks make your allowlists authoritative. To keep plugins under ~/.claude/skills/ working, the docs say to add { "source": "skills-dir" }.
• cleanupPeriodDays shortens laptop transcript retention, overriding the developer's value.
• The env block sends telemetry to your collector. A repository's settings cannot set the telemetry destination.

For tighter MCP control, a managed-mcp.json at the same system path gives exclusive control: users cannot add or use any other server, including plugin servers. It cannot be delivered through server managed settings. Owners on Team and Enterprise plans also toggle Remote Control and cloud sessions organization wide, and requiredMinimumVersion blocks outdated binaries.

Confirm the policy is in force

Run /status and look for Enterprise managed settings on the Setting sources line. Outside a session, claude doctor prints an Organization policy line. claude mcp list should show only approved servers.

How do we audit what the agent did after the fact?

OpenTelemetry in your own collector. Anthropic's monitoring page documents metrics such as claude_code.session.count, claude_code.commit.count and claude_code.pull_request.count, and events including claude_code.user_prompt, claude_code.tool_result, claude_code.tool_decision, claude_code.permission_mode_changed, claude_code.mcp_server_connection and claude_code.plugin_installed. tool_decision records accept or reject with a source such as config, hook or user_permanent. Events carry user.email, session.id and a prompt.id linking everything from one prompt.

Prompt text and responses are redacted by default, and tool parameters and output are not logged until you set OTEL_LOG_USER_PROMPTS, OTEL_LOG_TOOL_DETAILS or OTEL_LOG_TOOL_CONTENT. Full detail helps investigations and also puts file contents into your logging pipeline, so decide deliberately. OTEL_LOG_MANAGED_SETTINGS=1 records a SHA-256 digest of the resolved policy, useful evidence that guardrails were in force.

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317
claude
# then look for claude_code.session.count and claude_code.user_prompt in your collector

Local transcripts hold every tool call and result until the sweep removes them; collect them before they age out if an incident needs them. Git and pull requests are the durable record of what changed: keep agent work on branches with required human approval and mandatory CI, and see a human review gate for AI generated fix pull requests. Cloud sessions log all operations for compliance and audit, per Anthropic's security page.

Is "safe at work" different for regulated data?

Yes. The question shifts from configuration to coverage under your agreements.

SOC 2

Anthropic's security page points to the Anthropic Trust Center for its SOC 2 Type 2 report and ISO 27001 certificate; pull them directly for vendor review. For your own audit, the controls are yours: who may use the agent, on which repositories, with which permissions, how changes are reviewed and logged. Managed settings, telemetry export and branch protection provide that evidence.

HIPAA

Anthropic's legal page says a BAA extends to Claude Code under the HIPAA configuration on Claude for Enterprise, or with ZDR enabled. The HIPAA setup page adds:

• The configuration covers Claude Code in the terminal, the Code tab in Claude Desktop, and Cowork in local mode. The VS Code and JetBrains extensions keep working but are not covered.
• It applies only with a Claude Enterprise sign in connecting directly to the Claude API. Bedrock, Agent Platform, Foundry, gateways, custom base URLs and Console API keys are not eligible.
• It needs v2.1.285 or later and turns off WebFetch, cloud sessions, Remote Control, feedback and artifact publishing.
• Claude Code strips Anthropic credentials from processes it starts, but not cloud or GitHub credentials, and the BAA does not cover data sent to those services.
• Local session data is the organization's responsibility. claude purge --all --yes removes most of it; removing a seat deletes nothing on the laptop.

PCI DSS and other regimes

None of the Anthropic pages reviewed for this guide describe Claude Code as in scope for PCI DSS. Without written confirmation from Anthropic, keep cardholder data and its systems out of the agent's reach: no production credentials on laptops, no real card data in fixtures, and sandbox rules that cannot reach the cardholder environment. Remember too that ZDR excludes third party MCP servers, so each one you approve is a separate processor to review.

What is a sensible rollout?

Step 1: Fix the account model. Put work use on Team, Enterprise or API access under commercial terms and enforce it with the login keys. Anthropic's legal page says subscription OAuth sign in is meant for Claude Code and Anthropic's native apps, and third party developers may not route requests through Free, Pro or Max credentials, so keep subscription sign ins inside Anthropic's own apps.

Step 2: Pilot small. Five to ten engineers on repositories with no production secrets or regulated data, running the starting policy with Manual mode, the sandbox on and telemetry flowing. Check versions with claude --version.

Step 3: Verify on a real machine.

claude doctor               # read the Organization policy line
claude mcp list             # only approved servers should appear
claude auto-mode defaults   # review what auto mode would allow and block

Then try things that should fail: add an unapproved MCP server, read .env, curl an unlisted host. Each failure is a passed test.

Step 4: Tune for friction. Anthropic's troubleshooting list notes the sandbox can break docker, git over SSH and some database clients. Fix with narrow excludedCommands and specific domains, not by switching the sandbox off. If prompt fatigue is real, consider auto mode for trusted teams with managed deny and ask rules still in force; entering auto mode drops broad allow rules such as Bash(*) anyway.

Step 5: Publish an approved MCP and plugin catalog, enforced with the allowlists above, and review each plugin's hooks before adding it.

Step 6: Gate dependency changes. Every agent change to a manifest or lock file should get a scan and a policy check in CI before merge. Most rollouts skip this.

Step 7: Widen and re-review quarterly. Defaults change, as the recent auto mode default shows.

Where Safeguard fits

Claude Code's controls govern what the agent may do on the laptop. They do not tell you whether the package it just added carries a known vulnerability. That is where Safeguard helps:

• Scan what the agent changed. safeguard scan --dir . scans a repository (or --image and --sbom for images and SBOM files), writes JSON under ./output, and matches components against vulnerability databases with reachability analysis.
• Gate the merge. Safeguard policies and gates run in the platform, and safeguard exec runs in CI, so a pull request that introduces a vulnerable version can fail before review.
• Fix with a pull request. Autonomous remediation opens tested fix pull requests; it ships switched off.
• Use it from inside Claude. Add Safeguard from Claude's connector directory with OAuth. If you enforce an MCP allowlist, add https://mcp.safeguard.sh/* to allowedMcpServers.

Safeguard does not replace Claude Code's permissions, sandbox or managed settings, and it does not make a regulated deployment compliant. Configure Claude Code first, then use Safeguard to keep the agent's dependency changes reviewed.

What about Codex and other coding agents?

The same questions apply to every agent, answered from each vendor's own docs. OpenAI's agent approvals and security page for Codex lists sandbox modes read-only, workspace-write and danger-full-access (no sandbox and no approvals, not recommended), approval policies including on-request and never, network off by default for local runs, and Seatbelt on macOS with bubblewrap and seccomp on Linux. Version controlled folders default to workspace-write with on-request, and admins set policy through managed configuration. That page did not address training on customer data, so check OpenAI's terms for your plan.

For any agent, ask: what runs by default, which controls the OS enforces, whether it trains on your data, what it keeps locally, which extension points run code, whether admins can lock settings, and what audit trail it leaves.

Common mistakes

1. Assuming the default asks first. Current terminal sessions start in auto mode. Enforce Manual mode if your policy needs it.
2. Treating Bash deny rules as a boundary. They match text. Use the sandbox.
3. Forgetting what runs outside the sandbox: file tools, MCP servers, hooks, plugins.
4. Leaving ~/.ssh and ~/.aws readable to sandboxed commands.
5. Allowing broad network domains, which the proxy cannot inspect.
6. Using personal consumer accounts for company code.
7. Using bypassPermissions on a real workstation.
8. Running claude -p on outside pull requests with project settings and hooks loaded.
9. Allowlisting MCP servers by name instead of URL or command.
10. Forgetting the plaintext transcripts on every laptop, including at offboarding.
11. Letting dependency changes merge unscanned.

Fix it without waiting for upstream

Coding agents add and upgrade dependencies quickly, so a vulnerable version can land in a branch before anyone reads the lock file diff. Treat that like any dependency incident, and do not wait on a maintainer to close it.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These are real product sessions. None changes how Claude Code's permissions or sandbox work; they show how Safeguard adds dependency review and human approval to an agent workflow.

This demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. It mirrors the tool level control an administrator applies in Claude Code with allowedMcpServers and permission rules: the agent can query findings and safe versions and nothing more.

Click through it at your own pace, or open it full screen.

This is a real Safeguard CLI session. You run safeguard, ask it to fix the lodash CVE in a repository, and it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. It shows what "ask before each command" should look like for any agent touching your dependency tree.

Click through it at your own pace, or open it full screen.

This real Android session sends work to a computer running the Safeguard CLI and approves each command on the phone with Allow once, Allow for turn or Deny. It keeps a person in the approval loop when the reviewer is away from the desk.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and read the CLI documentation. For Claude Code configuration walkthroughs, see our practical Claude Code security guide and Claude Code and AI coding agent security basics.

FAQ

Is Claude Code safe to use at work?

Yes, once configured for work: a commercial plan, managed settings with locked rules, the sandbox on with credential and network limits, restricted MCP servers and plugins, telemetry to your own collector, and human review of every pull request.

Does Anthropic train on code I send through Claude Code?

Not under commercial terms (Team, Enterprise, API and third party platforms), unless the customer opts in to a program such as the Development Partner Program. On Free, Pro and Max plans it depends on the user's privacy setting.

Is Claude Code safe on a personal computer?

The same controls apply, but personal machines usually have weaker endpoint protection and more unrelated secrets, and company code on a consumer account falls under consumer terms. Use a work machine and account for work code.

Can Claude Code read my .env file?

Yes, unless you stop it. Auto mode allows it by default. Add Read deny rules, keep real secrets out of working trees, and remember that anything read is written to the local transcript.

Does Claude Code run commands without asking?

In auto mode, yes for actions the classifier approves. In Manual mode, only built in read only commands. With the sandbox on, sandboxed commands can also run without a prompt by default because the OS boundary stands in for approval.

Is the Claude Code sandbox enough on its own?

No. It covers shell commands, not file tools, MCP servers, hooks or plugins, and it filters by hostname without inspecting TLS. For stronger isolation, run the whole process in a dev container or VM.

Can my company control Claude Code settings centrally?

Yes, through the claude.ai admin console, MDM, Windows registry policy or a managed-settings.json file. Locks such as allowManagedPermissionRulesOnly and allowManagedMcpServersOnly stop developers widening policy.

Is Claude Code HIPAA compliant?

Anthropic says a BAA extends to Claude Code under the HIPAA configuration on Claude for Enterprise or with zero data retention, with exclusions such as IDE extensions, cloud sessions and third party providers. Your own PHI safeguards on laptops remain your job.

Should we ban Claude Code instead?

A ban tends to push usage onto personal accounts and unmanaged machines, with no settings, no telemetry and consumer terms. A managed rollout usually leaves you with more control.

Quick check

Sources

• Anthropic, Claude Code docs: Security
• Anthropic, Claude Code docs: Data usage
• Anthropic, Claude Code docs: Configure permissions
• Anthropic, Claude Code docs: Permission modes
• Anthropic, Claude Code docs: Configure the sandboxed Bash tool
• Anthropic, Claude Code docs: Deploy managed settings
• Anthropic, Claude Code docs: Control MCP server access for your organization
• Anthropic, Claude Code docs: Manage Claude Code plugins for your organization
• Anthropic, Claude Code docs: Monitoring usage with OpenTelemetry
• Anthropic, Claude Code docs: Explore the .claude directory
• Anthropic, Claude Code docs: Zero data retention
• Anthropic, Claude Code docs: Set up Claude Code (local mode) for a HIPAA-ready organization
• Anthropic, Claude Code docs: Legal and compliance
• OpenAI, Codex docs: Agent approvals and security

Last reviewed: 22 October 2026. Claude Code changes often; check Anthropic's linked documentation for current defaults and version requirements.