Claude Code Security: Risks and Settings to Understand Before Enterprise Adoption

An increasing number of companies are embedding Claude Code into their production development workflows. This tool autonomously generates, edits, and executes code from the terminal, dramatically improving development velocity — but it also introduces security risks that operate on a different scale than traditional coding-assistance tools.

I started my career as a database administrator in financial services and now run an IT company. The principles I was trained on in finance — "least privilege" and "maintain an audit trail" — have remained just as important when introducing AI agents. In fact, because an AI is autonomously executing commands, the privilege design needs to be even more careful than before.

This article walks through Claude Code's security model, permission settings, API key management, access via cloud providers, and the items to verify when adopting it at an enterprise. For the basic features and usage of Claude Code, see What Is Claude Code? The Complete Guide.

Claude Code's Security Model

There's one foundational premise you need to grasp when thinking about Claude Code's security: Claude Code runs with the same privileges as your terminal account.

This might sound obvious, but the implications are serious. If you can sudo in the terminal, Claude Code can, in principle, operate the entire system. If it can access ~/.ssh, it can technically read your SSH private keys. Securing Claude Code is, in effect, the same as revisiting the security of your terminal itself.

Defense-in-Depth Architecture

Anthropic addresses this risk with a defense-in-depth approach. Rather than relying on any single mechanism, they stack multiple layers of defense so that a breach of one layer contains the damage.

Specifically, the layers are:

Permissions system — requires explicit user approval before tools execute
Classifier model — in auto-execution modes, a separate AI model evaluates risk
Sandbox — restricts filesystem and network access at the OS level
Hooks — applies custom rules before the permission check

This multi-layered structure mirrors the security design of financial systems. Authentication, authorization, auditing, and isolation each function independently; if one is breached, the whole system does not collapse. I find this design philosophy resonant precisely because of my financial industry background.

OS-Level Isolation via the Sandbox

Claude Code's sandbox feature provides OS-level process isolation distinct from container technology. Specifically, it applies the following restrictions:

Filesystem access limits — blocks reads and writes outside the project directory and explicitly allowed paths
Network access limits — blocks external communication to domains or ports not on the allowlist
PID namespace isolation — isolates Claude Code processes so they cannot reference or operate on other processes

Recent updates have hardened PID namespace isolation and added credential scrubbing (preventing unintended credential leakage) and PowerShell execution hardening. Each of these narrows the blast radius if Claude Code ever performs an unintended operation.

Sandbox settings are managed in ~/.claude/settings.json:

{
  "permissions": {
    "sandbox": {
      "enabled": true,
      "allowedPaths": [
        "/Users/username/projects",
        "/tmp"
      ],
      "networkPolicy": {
        "allowedDomains": [
          "api.github.com",
          "registry.npmjs.org"
        ]
      }
    }
  }
}

In my own practice I narrow the sandbox allowlist per project to the minimum. The right approach is "expand as needed," not "expand because it's not working."

Data Privacy and SOC 2 Type II Compliance

An unavoidable question in enterprise adoption is: "What happens to the code I send to Claude Code?"

Anthropic has made it explicit that code processed through Claude Code is not used for model training. Per Anthropic's data handling policy, data sent via the API is used only to generate responses and is not included in training datasets.

Anthropic also holds SOC 2 Type II certification. SOC 2 Type II audits the ongoing operational effectiveness of security, availability, processing integrity, confidentiality, and privacy controls by a third party over a period of time. For financial institutions and large enterprises evaluating a service, the presence of this certification is a major decision factor.

Permission Settings and Access Control

The core of execution control in Claude Code is the permissions system. Five modes are available, each with a different tradeoff between security and convenience.

Permission Modes in Detail

default

Requires explicit user approval before every tool execution. Any file edit, command execution, or external API access triggers a prompt.

Claude wants to edit: src/components/Header.tsx
Allow? (y/n/always)

It's the safest mode, but the interruption on every approval has a non-trivial impact on productivity. Even so, I strongly recommend starting here during initial rollout or in strict-compliance environments.

plan

Claude Code first presents an execution plan, and the user approves the plan as a whole rather than each individual operation. It's more efficient than default while still letting you verify the intent up front.

Plan:
1. Read src/utils/auth.ts
2. Add input validation to login function
3. Update tests in src/utils/auth.test.ts

Approve this plan? (y/n)

My team uses plan mode as the default for normal development work. You know what's going to happen before it happens, preventing unintended changes while minimizing approval overhead.

auto

Claude Code executes tools autonomously, but before each execution a separate classifier model performs a risk assessment. The classifier flags and blocks operations like:

Scope violations — actions outside the current working context (e.g., running a database migration in the middle of a frontend change)
Operations against unknown infrastructure — access to servers or services that were not configured
Malicious content — execution of inputs that may contain prompt injection

Auto mode is productive, but the classifier is not guaranteed to be 100% accurate. Because the classifier itself is an AI model, a cleverly crafted prompt injection may in theory slip through. I restrict auto mode to development tasks that can't affect production — writing tests, refactoring, and the like.

acceptEdits

File edits are auto-approved, but shell commands and other operations still require approval. Useful when you want to focus on code modifications, but it does carry the risk of unintended file changes.

bypassPermissions

All permission checks are disabled, and Claude Code operates fully autonomously. This mode is extremely dangerous and should never be used in production. Consider it only in isolated, throwaway test environments.

{
  "permissions": {
    "mode": "bypassPermissions"
  }
}

I occasionally see this applied to production projects. That's the digital equivalent of leaving your front door permanently open. Understand the risk hiding behind the convenience.

How to Pick a Permission Mode

Environment	Recommended mode	Reason
Terminals with access to production	default	Completely prevents accidental impact on production
Normal development work	plan	Balances safety and productivity through plan review
Writing tests / refactoring	auto	Maximizes productivity for low-risk tasks
Isolated CI/CD environments	acceptEdits	Preserves efficiency for automation
Should not be used	bypassPermissions	Security risk exceeds acceptable bounds

Enforcement via Hooks

Claude Code's Hooks feature plays a particularly important role in the security context. Hooks run before the permission check, so rules are enforced even in bypassPermissions mode.

For example, here's a hook that outright forbids connections to production databases:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "command": "bash -c 'if echo \"$TOOL_INPUT\" | grep -qE \"(production|prod-db|prod)\"; then echo \"DENIED: Operations against production are forbidden\" >&2; exit 1; fi'"
      }
    ]
  }
}

PreToolUse hooks fire before tool execution; returning exit code 1 rejects the call. The beauty of this mechanism is that it applies regardless of permission mode. Even if someone mistakenly sets bypassPermissions, the hook guardrail keeps working.

The hooks I habitually configure include:

Reject commands containing production hostnames or database names
Detect and reject destructive operations like rm -rf and DROP TABLE
Restrict reads of sensitive files (.env, credentials.json, private key files)
Detect unintended data exfiltration via external curl or wget

For configuration details and usage examples, see Claude Code Hooks: The Complete Guide.

Safe Management of API Keys and Credentials

Using Claude Code requires an API key, and mishandling that key can lead to serious security incidents.

The Basics of Handling API Keys

The most important principle: never hardcode an API key in code. This is API key management 101, but many projects still violate it. API keys pushed to public GitHub repos are routinely found by scanning bots within minutes and abused — an endless parade of incidents.

Claude Code takes the key via the ANTHROPIC_API_KEY environment variable:

export ANTHROPIC_API_KEY="sk-ant-xxxxxxxxxxxxx"

That said, you should avoid direct entries in .bashrc or .zshrc, since those leave traces in shell history. Instead, use the env section of ~/.claude/settings.json or route through a secret-management tool:

{
  "env": {
    "ANTHROPIC_API_KEY": "sk-ant-xxxxxxxxxxxxx"
  }
}

The permissions on the settings.json file itself also need to be set correctly:

chmod 600 ~/.claude/settings.json

Spend Limit Management in the Anthropic Console

To mitigate the damage of a leaked API key, I strongly recommend setting spend limits in the Anthropic Console. Available controls include:

Daily Limit — maximum spend per day
Monthly Limit — maximum spend per month
Per-key limits — individual caps per API key

Anthropic Console > API Keys > [key name] > Spend Limits
  Daily Limit: $50
  Monthly Limit: $500

In my own ops, I set individual developer keys to $20/day and $200/month. CI/CD keys get their own limits based on usage — the goal is to cap the damage in the event of a leak.

API Key Rotation

API keys should be rotated regularly. I recommend rotating at these moments:

Periodic rotation — every 90 days (quarterly)
Member departure — immediately when a team member leaves or transfers
Suspected leak — immediately revoke and reissue if a key may have been exposed
Permission changes — when changing the permissions tied to a key

The rotation procedure:

Issue a new key in the Anthropic Console
Update environment variables and configuration files with the new key
Verify everything works normally
Revoke the old key
Record the rotation

The critical point: revoke the old key after confirming the new one works. Switching both at once risks downtime.

Key Management Strategy for Teams

For teams using Claude Code, key-management strategy splits into two broad patterns.

Individual keys

Each developer has their own API key. Easy to track usage, and the blast radius of any single leak is limited. The downside is that issuance, management, and rotation overhead scales linearly with headcount.

Shared key + proxy

Access goes through an organization-managed proxy. Individual developers don't hold API keys directly — they manage only proxy credentials. Key management is centralized, but the proxy server itself becomes a new security concern.

I use the individual-key approach. It's more management overhead, but my finance background taught me the hard lesson that shared accounts and shared keys become a problem at audit time. Tracking who did what when demands individual keys.

Using Claude Code via Amazon Bedrock

When an organization's security policy dictates "data must not leave our environment," going through Amazon Bedrock is an option.

Security Benefits of Going Through Bedrock

Using Bedrock brings these security benefits:

Data stays within your AWS account

Using Anthropic's public API means your request data traverses Anthropic's infrastructure. With Bedrock, the data is processed within your VPC and never leaves your AWS account. For industries like finance or healthcare with strict data-residency requirements, this is a deciding factor.

Fine-grained access control via IAM

Because it integrates with AWS IAM, you can leverage your existing AWS permissions regime.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/Department": "Engineering"
        }
      }
    }
  ]
}

This example restricts invocation of Claude models to users with a Department tag of Engineering. You can scope access by department, by project, or even by model version.

Audit logs via CloudTrail

All API calls are recorded in AWS CloudTrail. When, who, which model, and from which region — everything is captured automatically as an audit trail.

{
  "eventSource": "bedrock.amazonaws.com",
  "eventName": "InvokeModel",
  "userIdentity": {
    "arn": "arn:aws:iam::123456789012:user/developer-a"
  },
  "requestParameters": {
    "modelId": "anthropic.claude-sonnet-4-20250514"
  }
}

For someone with a financial-industry background, this automatic audit-log collection is paramount. An environment where you can't go back and trace "who did what" isn't fit for enterprise use at all.

Configuring Claude Code to Use Bedrock

Use Claude Code via Bedrock by setting these environment variables:

export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=us-east-1
export AWS_ACCESS_KEY_ID="AKIA..."
export AWS_SECRET_ACCESS_KEY="..."

That said, IAM roles or instance profiles are preferable to direct access keys. When running from EC2 or ECS tasks, attaching an IAM role eliminates the need to manage keys at all.

export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=us-east-1
# When an IAM role is attached, no keys need to be set

Private Use within a VPC

For even tighter security, use a VPC endpoint to keep Bedrock API access inside your VPC.

# Create a VPC endpoint (AWS CLI)
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-xxxxx \
  --service-name com.amazonaws.us-east-1.bedrock-runtime \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-xxxxx \
  --security-group-ids sg-xxxxx

With this, Bedrock API calls never traverse the internet, and data is physically prevented from leaving the VPC.

Using Claude Code via Vertex AI

For organizations whose primary cloud is Google Cloud, Vertex AI is an alternative. For more on Vertex AI itself, see What Is Vertex AI?.

Security Properties of Vertex AI

Workload Identity Federation

What's notable about going through Vertex AI is support for Workload Identity Federation. This lets you access GCP resources using credentials from an external identity provider (AWS, Azure AD, any OIDC-compliant provider) without issuing or managing service account keys.

{
  "type": "external_account",
  "audience": "//iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID",
  "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
  "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_EMAIL:generateAccessToken",
  "token_url": "https://sts.googleapis.com/v1/token"
}

Service account keys are long-lived credentials that carry high risk if leaked. With Workload Identity Federation, authentication uses short-lived tokens, fundamentally removing key-leakage risk.

Service account-based permissions

Use GCP IAM to control access to Vertex AI:

# Create a service account
gcloud iam service-accounts create claude-code-sa \
  --display-name="Claude Code Service Account"

# Grant the Vertex AI user role
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:claude-code-sa@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/aiplatform.user"

VPC Service Controls

GCP's VPC Service Controls let you restrict access to Vertex AI within a VPC boundary. This is equivalent to AWS VPC endpoints — a network-level control to prevent data exfiltration.

# Create a service perimeter
gcloud access-context-manager perimeters create claude-code-perimeter \
  --title="Claude Code Perimeter" \
  --resources="projects/PROJECT_NUMBER" \
  --restricted-services="aiplatform.googleapis.com" \
  --policy=POLICY_ID

Configuring Claude Code to Use Vertex AI

Environment variables for Claude Code via Vertex AI:

export CLAUDE_CODE_USE_VERTEX=1
export CLOUD_ML_REGION=us-east5
export ANTHROPIC_VERTEX_PROJECT_ID=your-project-id

Authentication follows Google Cloud's standard flows. In a local development environment, use gcloud auth application-default login; in production, use a service account or Workload Identity Federation.

Using Microsoft Foundry

Microsoft Foundry is also supported as a third-party provider. For organizations running primarily on Azure, the ability to integrate with existing Azure AD and RBAC is the main benefit.

Choose the cloud provider based on your existing infrastructure and security policy. Whichever path you pick, the fundamental benefits — data stays within your control, and you can leverage existing permissions and audit-log systems — apply uniformly.

Enterprise Adoption Security Checklist

Here the individual security features cover above are mapped into a concrete adoption process. The checklist below is based on what I use when helping my own company and client companies adopt Claude Code.

1. Choose a Permission Mode

The first thing to decide at adoption time is the permission mode.

Decided the permission mode based on organizational security policy
Set default mode on terminals with access to production
Prohibited bypassPermissions mode organization-wide
Set up an approval flow for permission-mode changes

My recommendation is that everyone start in plan mode, with migration to auto mode considered based on project nature. Allowing auto mode from day one risks incidents before sufficient security awareness is established.

2. Evaluate and Configure the Sandbox

Confirmed the sandbox is enabled
Set the allowed file paths to the minimum
Defined the network access allowlist
Documented the change management process for sandbox settings

3. API Key Operational Policy

Documented the process for issuing, managing, and retiring API keys
Set per-key usage limits (daily / monthly)
Decided key rotation cadence (recommended: 90 days)
Documented the key-invalidation procedure for member departures
Decided how keys are stored (environment variables or secret management)

4. Evaluate VPC Deployment

Confirmed requirements on data residency
Decided between Anthropic direct API / Bedrock / Vertex AI
Decided whether in-VPC private usage is required
Designed the cloud provider's IAM policies
Decided how to collect and retain audit logs

5. Configure Hook-Based Guardrails

Set up hooks that restrict operations against production
Set up hooks that detect and reject destructive commands
Set up hooks that restrict access to sensitive files
Put hook configuration under version control

6. Define Audit Log Requirements

Defined the scope of logs to collect
Decided the log retention period
Designed monitoring and alerting on logs
Established a periodic log-review process

7. Security Training for Team Onboarding

Created materials on Claude Code's security risks
Explained the meaning of permission modes and selection criteria
Shared the rules for handling API keys
Defined incident reporting and response flows
Scheduled periodic security refresher training

Leveraging Enterprise Features

For larger-scale adoption, Claude Code's enterprise features are useful. For pricing details, see Claude Code Pricing: A Full Plan Comparison.

SSO (Single Sign-On)

Integrates with Okta, Azure AD, and SAML 2.0-compliant identity providers. Existing ID management infrastructure can be leveraged as-is, eliminating per-user account management.

SCIM provisioning

Supports SCIM (System for Cross-domain Identity Management), automating user provisioning (create, update, delete). Integrated with HR systems or identity providers, account management can be automated as members join and leave.

Audit logs

Administrator-level audit logging makes organization-wide Claude Code usage visible. You can trace who performed which operations and when.

Custom data retention

Customize the retention period for conversation data to fit the organization's data retention policy. Configurable to match regulatory requirements.

IP allowlisting

Limit access to allowed IP addresses. Restricting to office networks or VPNs reduces unauthorized access risk.

Role-based access control

Set role-based permissions for users within the organization — administrators, developers, viewers — according to their roles.

BYOK (Bring Your Own Key)

BYOK (encrypting data with your own managed keys) is planned for release in the first half of 2026. This lets you use your own KMS (Key Management Service) to encrypt data stored with Anthropic. A long-awaited feature for financial institutions, government agencies, and other organizations that require self-managed encryption keys.

Summary

Security for Claude Code is not a single setting. Choosing the permission mode appropriately, OS-level isolation via the sandbox, rigorous API-key management, configuring Hook guardrails, and leveraging cloud provider security features — combining these layers of defense is what yields enterprise-grade security.

One of the lessons I took from my time in finance: "Security is determined by the strength of its weakest point." You can configure permissions strictly, but if an API key is hardcoded, it's pointless. You can build a VPC-closed environment, but if you don't collect audit logs, you can't trace causes when an incident occurs.

Claude Code is a powerful tool that meaningfully raises development productivity. But precisely because it's powerful, adopting it without security care is risking unrecoverable damage. Use the checklist in this article, design security appropriate to your environment, and reap Claude Code's benefits in full.

If you'd like to discuss security design for adoption, please feel free to reach out via Contact.