Claude Enterprise Security: A Complete Guide to Governing Claude Code at Scale

Introduction

In early 2026, Check Point Research disclosed CVE-2025-59536 - a CVSS 8.7 vulnerability in Claude Code that allows remote code execution through malicious project configuration files before any trust dialog appears. A second CVE, CVE-2026-21852, demonstrated how an attacker can redirect all Claude Code traffic to an attacker-controlled server by manipulating the ANTHROPIC_BASE_URL environment variable, silently exfiltrating API keys and conversation content.

These are not theoretical risks. They are documented, reproducible attack chains that affect any organization that has deployed Claude Code without centralized governance.

Claude Code is now running on developer machines across thousands of enterprises. Most of those deployments share the same characteristics: developers authenticate with personal Anthropic accounts, API keys live in environment variables or .bash_profile, there is no audit trail of what code context flows to Anthropic's servers, and there is no mechanism to revoke access when an engineer leaves the organization.

The security problem isn't Claude Code itself. It's the assumption that a developer tool requires developer-level governance.

This guide covers the six control layers every platform engineering and security team needs to deploy Claude Code safely at enterprise scale from SSO and identity to MCP governance, sandboxing, audit logging, and compliance. It also covers where TrueFoundry's AI Gateway and MCP Gateway fit as the centralized enforcement layer across all of them.

Claude Code's Enterprise Attack Surface

Before addressing controls, it's worth understanding why Claude Code's attack surface is broader than a standard SaaS tool.

Claude Code operates in the developer's terminal with the same permissions as the local user. It can read files, execute shell commands, connect to external services, and — through MCP servers — interact with databases, internal APIs, and SaaS tools. This is what makes it productive. It is also what makes an uncontrolled deployment a significant security exposure.

There are four primary attack vectors:

1. File system access. Without explicit deny rules, Claude Code can read .env files, SSH keys, credentials stored in ~/.aws/credentials, and any file the local user has access to. In a typical developer environment, this means access to secrets that were never intended to leave the machine.

2. Shell execution. Claude Code can run arbitrary bash commands in the developer's user context. A malicious prompt, either directly injected or arriving through an MCP tool's response can trigger shell commands without explicit per-command approval unless disableBypassPermissionsMode is set.

3. ANTHROPIC_BASE_URL manipulation (CVE-2026-21852). If an attacker can modify the environment where Claude Code runs — through a malicious .claude/settings.json in a repository, a compromised dotfile, or a hook injection — they can redirect all traffic to a server they control. Every prompt, response, and API key transmitted during that session is captured.

4. MCP tool misuse and prompt injection. MCP servers connect Claude to external systems. Without a governance layer, developers can connect Claude to any MCP server — including malicious ones with tool descriptions designed to alter Claude's behavior. Content retrieved by MCP tools from external sources (web pages, documents, API responses) can contain injected instructions that Claude executes silently.

Understanding these four vectors is the prerequisite for understanding why the controls below exist.

Step 1: Lock Identity Before Anything Else

The most consequential security decision for a Claude rollout is whether developers authenticate with personal accounts or enterprise-controlled identities. Personal accounts mean no audit trail, no access revocation, and no visibility into usage. Enterprise SSO means every Claude interaction is attributable, revocable, and auditable from a single place.

SSO Configuration

Claude supports SAML 2.0 and OIDC with any compliant identity provider — Okta, Azure AD (Entra ID), Auth0, and Google Workspace. Configure SSO in the Claude Admin Console before any broad rollout.

Two settings matter most:

• Require SSO for Console — forces admin authentication through your IdP
• Require SSO for Claude — forces all Claude.ai web logins through your IdP, preventing personal account fallback

Enable domain capture alongside SSO. Once domain capture is active, any sign-in attempt with a corporate email address routes to the enterprise workspace automatically. Employees cannot use personal accounts with corporate email addresses — the identity boundary is enforced at the provider level.

Map your IdP groups to Claude roles at provisioning time:

Revoking a user in your IdP immediately blocks access across all interfaces — web and CLI. This is the baseline you need for any production rollout.

API Key Management for Claude Code

SSO covers interactive web authentication. Claude Code authenticates via API keys — and these require a separate governance approach.

• Never allow developers to use personal API keys in a corporate context. Issue all Claude Code keys through the Admin Console with explicit scope and expiry.
• Store keys in a centralized secrets manager — AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault. Keys should never live in .bash_profile, shell history, or committed configuration files.
• Rotate keys quarterly at minimum, and revoke immediately on suspected compromise or employee offboarding.
• For organizations using TrueFoundry's AI Gateway, developers receive scoped virtual keys from the gateway — the underlying Anthropic API key never leaves the gateway's secrets manager. This eliminates the risk of direct key exposure entirely.

Step 2: Route All Claude Traffic Through a Gateway

The single most effective control you can add to a Claude Code deployment is routing all traffic through a centralized gateway via  ANTHROPIC_BASE_URL. This gives your platform team a single enforcement point for authentication, model access control, rate limiting, budget management, and observability regardless of which developer, machine, or application is making the request.

Why Gateway Routing Matters

Without a gateway, every Claude Code session authenticates directly to Anthropic's API. There is no centralized visibility into what models are being used, how many tokens are being consumed, or whether requests contain sensitive data. There is no way to enforce budget limits, block access to unapproved models, or revoke access without deactivating the developer's entire Anthropic account.

With a gateway, you control all of that from one dashboard.

TrueFoundry AI Gateway acts as the unified proxy layer. Point Claude Code at the gateway:

export ANTHROPIC_BASE_URL=https://<your-truefoundry-gateway-url>

‍From that point forward, the gateway enforces:

• Model access control - only models explicitly allowlisted in the gateway policy are accessible
• Rate limits and budget caps - per-developer and per-team token limits
• Full request tracing - every prompt and response logged with user attribution
• Fallback routing - if one provider is unavailable, the gateway retries against a configured fallback.

Enforcing Gateway Routing Across Your Fleet

Setting ANTHROPIC_BASE_URL on one machine is straightforward. Enforcing it consistently across hundreds of developer machines is the real challenge. There are three approaches, each with different trade-offs:

The recommended posture for corporate-managed device fleets is MDM + TrueFoundry AI Gateway. The MDM pushes a managed-settings.json to system-level paths that developers cannot modify, and the gateway enforces policy on every request:

• macOS: /Library/Application Support/ClaudeCode/managed-settings.json
• Linux: /etc/claude-code/managed-settings.json

Important: Server-managed settings from the Claude Admin Console are bypassed when ANTHROPIC_BASE_URL is set. If you route through TrueFoundry, use MDM-deployed managed-settings.json for model routing configuration.

For full integration instructions, see the TrueFoundry Claude Code integration guide.

Step 3: Govern Every Tool Claude Can Touch

This is the control layer most organizations skip — and the one with the highest blast radius if ignored.

MCP (Model Context Protocol) servers connect Claude to external systems: GitHub, Jira, Slack, internal databases, file stores, and custom APIs. Every MCP server a developer connects to is a new attack surface. Without centralized governance, the tool layer is where prompt injection becomes a systemic risk rather than an application-level concern.

What Happens Without MCP Governance

Without centralized MCP controls, your Claude deployment faces:

• Prompt injection through tool responses. A malicious web page, document, or API response retrieved by an MCP tool can contain injected instructions. Claude processes this content as context — and may execute embedded commands silently, before any user review.
• Credential sprawl. Each MCP server a developer connects to directly requires its own authentication credentials, stored locally on their machine.
• Shadow IT. Developers install public MCP servers without security review. There is no audit trail of which tools were invoked, by whom, or what data was accessed.
• Data exfiltration via tool chains. An injected instruction can chain multiple tool calls — reading a sensitive file, then writing its contents to an external API — without triggering any explicit permission dialog.

The MCP Gateway Pattern

The correct architecture is to route all MCP server access through a centralized gateway and allowlist only that gateway URL in your managed settings. This gives you a single enforcement point regardless of how many MCP servers your organization uses.

TrueFoundry MCP Gateway is purpose-built for this pattern:

• Centralized MCP registry - register and manage all approved MCP servers in one place. Developers connect to the Gateway instead of managing individual server connections locally.
• Unified authentication - developers authenticate once with a TrueFoundry API key or your IdP token. The gateway handles outbound auth to each downstream server.
• Role-based tool access - control which users and teams can access which MCP servers and individual tools within a server.
• Pre- and post-execution guardrails - apply checks before tool calls execute and validate responses before they reach Claude's context.
• Full audit trail -every tool invocation traced with user attribution, request/response payloads, and latency data. Exportable via OpenTelemetry to your SIEM.

Configure your managed settings to allowlist only the gateway:‍


{
  "allowedMcpServers": [
    { "serverUrl": "https://truefoundry-mcp-gateway.your-company.com/*" }
  ],
  "strictKnownMarketplaces": []
}

Setting strictKnownMarketplaces to an empty array blocks all marketplace-sourced MCP server installations. Developers cannot add servers from the Claude MCP marketplace unless your admin explicitly approves them through the gateway registry.

For a deeper look at the MCP security architecture, see TrueFoundry MCP Gateway documentation and Claude Code prompt injection risks.

Step 4: Sandbox Claude Code on Developer Machines

Identity and gateway controls govern what Claude can access at the network level. Sandboxing governs what it can do on the local machine. Both are necessary - a gateway doesn't prevent Claude from reading a local .env file before the content is transmitted in a prompt.

The Baseline managed-settings.json

The following configuration represents a secure baseline for most enterprise Claude Code deployments. It blocks the highest-risk local operations, requires explicit approval for destructive actions, and prevents developers from overriding the policy:

{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "deny": [
      "Bash(curl:*)",
      "Bash(wget:*)",
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(**/secrets/**)",
      "Read(**/.ssh/**)",
      "Read(**/credentials/**)"
    ],
    "ask": ["Bash(git push:*)", "Write(**)"]
  },
  "allowManagedPermissionRulesOnly": true,
  "allowManagedHooksOnly": true,
  "transcriptRetentionDays": 14,
  "sandbox": {
    "enabled": true,
    "network": {
      "httpProxyPort": 8080,
      "socksProxyPort": 8081
    }
  }
}

Each setting serves a specific security purpose:

OS-Level Sandboxing

Claude Code's native sandbox enforces filesystem and network isolation at the OS level - independently of the permission rules above. The sandbox prevents Claude from accessing files or network destinations outside explicitly defined boundaries, even if a permission rule was bypassed.

Enable sandboxing for all developers. For organizations routing through TrueFoundry, configure the network proxy ports to align with your gateway's ingress:‍


{
  "sandbox": {
    "enabled": true,
    "network": {
      "httpProxyPort": 8080,
      "socksProxyPort": 8081
    }
  }
}

Also set "allowUnsandboxedCommands": false to disable the escape hatch that allows commands to run outside the sandbox. This forces all shell commands to run sandboxed, or to be explicitly listed in excludedCommands by an admin.

Never run Claude Code as root. Ensure developers run it under their own user accounts with the minimum required filesystem permissions. A sandboxed Claude Code running as root defeats the sandbox entirely.

Step 5: Build an Audit Trail You Can Actually Use

Audit logging is not useful if it captures the wrong data, stores it in the wrong place, or requires manual effort to query. The goal is a complete, attributable, queryable record of every Claude interaction - LLM calls and MCP tool invocations — that can be exported to your SIEM and retained for your compliance window.

What to Capture

TrueFoundry Gateway Observability

When all Claude Code traffic routes through TrueFoundry AI Gateway, you get request-level traces across both LLM and MCP layers without additional instrumentation. Every request is logged with full user attribution — developer identity, model selected, token counts, latency, cost, and the gateway routing decision.

Key observability capabilities:

• Request tracing - every API call logged with caller identity, model, provider, and response metadata
• MCP trace correlation - tool invocations correlated with the parent LLM request that triggered them
• Cost attribution - real-time token spend broken down by developer, team, model, and application
• Anomaly detection - usage spikes, repeated denied actions, and unusual tool access patterns surfaced in dashboards

All traces export to any OpenTelemetry-compatible platform — Grafana, Datadog, Splunk, or your existing SIEM. See the TrueFoundry OpenTelemetry export documentation for setup instructions.

Retain audit logs for a minimum of 90 days to meet SOC 2 requirements. For HIPAA-regulated workloads, follow your BAA terms for minimum retention periods.

Step 6: Set Data Retention Policies Before Sensitive Data Enters the System

The most expensive data governance mistake is discovering after the fact that regulated data was processed without the appropriate contractual and technical controls in place.

Retention Defaults

By default, Anthropic may retain prompts and outputs for safety and quality improvement. Enterprise plans include options to reduce this significantly. Set conversation retention to a maximum of 30 days at Organization Settings → Data and Privacy in the Admin Console.

For Claude Code CLI, local session transcripts are stored on the developer's machine at ~/.claude/. Use transcriptRetentionDays in your managed settings to auto-delete after 7–14 days.

Zero Data Retention (ZDR) for HIPAA

If your organization processes Protected Health Information (PHI) with Claude, a Zero Data Retention (ZDR) addendum is required before any PHI enters any Claude interface. ZDR prevents Anthropic from storing prompts and outputs beyond what is needed to serve the request — prompts are not retained after the response and session data is not used for training.

ZDR must be requested through your Claude account team and requires a contractual addendum. Do not introduce PHI to any Claude interface until the addendum is confirmed active.

GDPR Data Residency

For GDPR-regulated workloads requiring EU data residency, route Claude traffic through AWS EU regions via Bedrock or Google Vertex AI with Private Service Connect. TrueFoundry's AI Gateway supports routing to both — the gateway policy can enforce that requests from specific teams or applications only reach EU-region endpoints.

Step 7: Map Your Compliance Requirements

Enterprise Reference Architecture: Secure Claude Deployment

A production-grade Claude Code deployment at enterprise scale looks like this:

Developer machine > MDM Enforced managed-settings.json -> Truefoundry AI Gateway -> Truefoundry MCP Gateway -> Model Providers (Anthropic / Bedrock / Vertex)

Each layer handles a specific set of controls:

MDM Layer: Pushes managed-settings.json and managed-mcp.json to system-level paths that developers cannot modify. Sets ANTHROPIC_BASE_URL to the TrueFoundry gateway. Configures sandbox and deny rules. Locked with macOS schg immutable flag on managed devices.

TrueFoundry AI Gateway: Receives all Claude Code LLM requests. Validates developer identity via scoped virtual key. Enforces model access policy. Applies rate limits and budget caps. Routes to the appropriate model provider. Logs request metadata with full attribution.

TrueFoundry MCP Gateway: Receives all MCP server requests. Validates developer identity. Checks tool-level RBAC. Applies pre- and post-execution guardrails. Routes to approved MCP servers. Logs every tool invocation with full payload.

Model Providers: Anthropic direct, AWS Bedrock (for VPC isolation and CloudTrail logging), or Google Vertex AI (for GCP-native data residency). The application layer and the developer never needs to know which provider served a given request.

Observability Layer: All gateway traces export to your OTEL-compatible SIEM via TrueFoundry's OpenTelemetry integration, providing unified visibility across LLM and MCP layers in whatever observability platform your organization already uses.

For more on how this architecture handles multi-team AI deployments, see Claude Code Governance: How to Govern Agent Rollouts with an AI Gateway.

Enterprise Claude Security Deployment Checklist

Conclusion

Claude Code is a legitimate productivity multiplier for engineering organizations. It is also the broadest attack surface most engineering teams have introduced to their developer environments in the last several years. File system access, shell execution, network connectivity, and extensible tool integrations — all running with developer-level permissions, all sending context to external APIs, all configurable through files that can be placed in any project repository.

The good news is that the controls exist. SSO, gateway routing, MCP governance, sandboxing, and audit logging are all implementable with tools that exist today. The organizations that will avoid security incidents are the ones that treat Claude deployment as an infrastructure decision from the start — not a configuration afterthought once something goes wrong.

The six steps in this guide represent the minimum viable security posture for any enterprise running Claude Code at scale. TrueFoundry's AI Gateway and MCP Gateway provide the centralized enforcement layer that makes these controls operational without requiring each development team to implement governance independently.

Frequently Asked Questions

What is Claude enterprise security?

‍Claude enterprise security refers to the set of controls that govern access, protect data, and provide visibility across Claude deployments in an organization. It spans identity (SSO, API key management), model routing (gateway-enforced access control), tool governance (MCP gateway), sandboxing (local permission rules and OS isolation), and compliance (audit logging, data retention, ZDR). Without these controls, Claude Code running on developer machines has access to sensitive files and external networks with no organizational oversight.

How do I prevent Claude Code from reading .env files and SSH keys?

‍Add explicit deny rules to your managed-settings.json and deploy it at the system level via MDM. The deny rules "Read(**/.env)", "Read(**/.env.*)", and "Read(**/.ssh/**)" block these file reads outright. Pair this with allowManagedPermissionRulesOnly: true to prevent project-level settings in repositories from overriding these rules. See TrueFoundry's Claude Code integration guide for the full baseline configuration.

Do I need an AI gateway to secure Claude Code?

Not strictly — but without one, you cannot achieve centralized governance at scale. An AI gateway gives you a single enforcement point for model access control, rate limiting, budget caps, and audit logging across all developers and applications. Without it, these controls must be implemented and maintained in every individual Claude Code configuration, which is operationally fragile and produces inconsistent enforcement. For teams with more than a handful of developers, a gateway is the only practical approach.

What is an MCP gateway and why does it matter?

‍An MCP gateway is a centralized control layer between Claude and the external tools it can access — databases, APIs, SaaS integrations, file systems. Without one, developers connect Claude to MCP servers individually, with no centralized visibility, no role-based access control, and no audit trail of what tools were invoked or what data was returned. Prompt injection through MCP tool responses is one of the highest-severity attack vectors in agentic deployments — an MCP gateway with guardrails is the primary defense. TrueFoundry's MCP Gateway is covered in detail in the MCP Gateway documentation.

What is TrueFoundry's role in Claude enterprise security?

TrueFoundry provides the infrastructure control plane that sits between Claude Code and your model providers. The AI Gateway centralizes authentication, model routing, rate limiting, budget enforcement, and request-level observability. The MCP Gateway centralizes tool access control, guardrails, and tool invocation auditing. Together, they give platform and security teams the enforcement layer needed to run Claude Code at enterprise scale with auditable, consistent governance without requiring every development team to implement controls independently.

Learn more at truefoundry.com/ai-gateway and truefoundry.com/mcp-gateway.