Enterprise Security for Claude: A Practical Governance Guide for Engineering Teams

The three Claude attack surfaces (and why they need different controls)

‍Eight out of ten Fortune 10 companies now use Claude, and over 300,000 businesses run it in production. Two CVEs in the past year proved that a cloned repo is all it takes to exfiltrate API keys or execute code before a trust dialog even appears.

Claude ships across three interfaces — web, desktop, and CLI — and each one has a different attack surface. The web version runs in a browser sandbox, the desktop app connects to local tools, and Claude Code sits in your developers' terminals with the same permissions as their user accounts. It can read files, run bash commands, and connect to external services.

Most enterprise security guides treat these interfaces as one thing, but they are not. Governing Claude well means applying the right controls to each surface, rather than blanket policies that over-restrict developers or leave gaps. The sections below walk through how to do it.

Identity and Access Configuration

SSO should be live before you hand Claude to a single developer — not after, and certainly not "soon."

Claude supports SAML 2.0 and OIDC with Okta, Azure AD (Entra ID), Auth0, and Google Workspace, and you can manage all of it from the Claude Admin Console (see the setup guide). Three settings matter most at this stage.

Critical SSO Configuration Steps

• Enable Require SSO for Console and Require SSO for Claude. Both settings enforce SSO-based authentication and inherit MFA from your identity provider.
• Claim your corporate email domains through domain capture. Once active, any sign-in attempt with a company address automatically routes to the enterprise workspace, preventing employees from reverting to personal accounts across any interface.
• Map your Identity Provider (IdP) groups to Claude roles. Primary Owner gets full admin access, including billing. Admin manages users, policies, and audit logs, but cannot touch billing, and Member uses Claude within admin-defined policies.

Revoking someone in your IdP drops their access across web, desktop, and CLI instantly.

API Key Management

SSO handles interactive logins, while API keys handle everything else — Claude Code sessions, CI/CD pipelines, and any automation hitting the API outside a browser.

You should issue keys through the Admin Console because developers should never use personal keys in a corporate context. Store them in AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault, rotate them quarterly, and revoke them immediately on suspected compromise or when someone leaves the team.

Model Access and Traffic Routing

After identity, the next layer is model access and traffic routing. You need answers to two questions: which models can developers use, and where does their Claude traffic actually flow?

Restricting the Model Set

A simple allowlist in the Admin Console stops developers from switching to higher-cost or unapproved models:

{
"allowedModels": ["claude-sonnet-4-5", "claude-haiku-4-5"]
}

Routing Traffic Through a Gateway

Routing Claude traffic through your own LLM gateway lets you inspect, log, and govern requests at the network layer. You can set these environment variables on developer machines to get started:

export ANTHROPIC_BASE_URL=https://your-gateway.internal.corpexport HTTPS_PROXY=https://proxy.your-company.com:8080

One important detail is that these variables apply only to Claude Code and Claude Desktop. Web routing is controlled at the organization level through the Admin Console.

Enforcing Routing Policies Across Developer Machines

Setting variables on one machine is easy, but doing it across 100 machines and ensuring nobody changes them is the real challenge.

You can enforce routing policies across developers’ machines in three ways:

1. MDM / Endpoint-Managed Settings push a managed-settings.json file to every machine via Jamf, Kandji, or Intune. Claude Code reads the file at startup with no network dependency, and the settings are tamper-resistant at the OS level. The tradeoff is that MDM only works on corporate-owned devices.
2. Server-Managed Settings (Beta) delivers configuration from Anthropic's servers when developers authenticate. No file deployment is needed, and the approach works on BYOD devices. The catch is that enforcement is client-side only, so a developer with sudo can tamper with it. The approach is also incompatible with custom ANTHROPIC_BASE_URL, so if you route through a gateway, this option is off the table.
3. Direct Cloud Provider routes Claude Code to your AWS Bedrock or Google Vertex account. Traffic stays in your VPC with cloud-native audit logging, but the downside is single-provider lock-in and complex IAM setup.

Using a Centralized Gateway for Multi-Provider Routing

Instead of configuring each provider one by one, TrueFoundry AI Gateway gives you a single proxy layer between Claude Code and all your model providers. You can point Claude Code at it with one variable:

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

From there, you add provider accounts in the Gateway dashboard, and Claude Code reaches all of them — Anthropic, Bedrock, Vertex — via a single endpoint. Virtual Models let you create a single model identifier that routes across providers with weight-based or latency-based logic, and you can switch providers without touching any client configuration.

The Gateway also enforces rate limits, budget limits, and access control on every request before it reaches the provider.

Local Tool Access and Sandboxing

The mistake most teams make is treating all three interfaces the same, even though they are fundamentally different in what they can touch.

Claude.ai (Web)

The web interface has no local code execution, so the primary risks are data exfiltration through prompts and shadow IT from personal accounts. Domain capture solves the second problem. 

For the first, classify Claude.ai as a third-party SaaS tool in your data loss prevention (DLP) and AI security tooling and apply the same controls you would to Google Docs or Notion. The Admin Console also lets you restrict file uploads, disable Artifacts, and control conversation retention.

Claude Desktop

The desktop app does not run arbitrary shell commands by default, but local tool integrations let developers connect Claude to scripts, file systems, and other resources. You should review each tool before approval and require explicit human confirmation before execution for anything with write access. Keeping the app current via MDM-enforced auto-update is also essential.

Claude Code (CLI)

Claude Code has the broadest attack surface of the three interfaces. It can read .env files, SSH keys, and credentials, run arbitrary bash commands in the developer's user context, and send code and context to Anthropic's servers for processing.

The following baseline managed-settings.json blocks the most dangerous operations:

{
"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}

Here is what each key setting does:

• disableBypassPermissionsMode stops developers from using --dangerously-skip-permissions to override safety controls.
• allowManagedPermissionRulesOnly locks out project-level and user-level permission overrides entirely.
• deny rules block operations outright with no override possible.
• ask rules require explicit developer approval before each execution.

One more thing worth emphasizing: Claude Code should never run as root under any circumstances.

Enabling Native Sandboxing

Claude Code's native sandbox enforces filesystem and network isolation at the OS level, using Seatbelt on macOS and bubblewrap on Linux. Anthropic's own internal testing found that sandboxing reduces permission prompts by 84% while maintaining stronger execution boundaries. You should enable it for all developers:

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

The sandbox prevents modification of system-level files, blocks contact with domains you have not allowed, and limits the blast radius of prompt injection attacks. You should also set "allowUnsandboxedCommands": false to close the escape hatch that would otherwise let commands run outside the sandbox.

MCP Server Governance

MCP servers connect Claude to external databases, APIs, and SaaS tools, and every new server a developer adds expands the attack surface. Without centralized control, you end up with credential sprawl, unvetted public servers running on developer machines, and no audit trail of which tools were called or what data returned.

The solution is to route all MCP access through a centralized gateway and allowlist only that gateway URL.

What TrueFoundry MCP Gateway Provides

TrueFoundry MCP Gateway handles enterprise MCP governance through a single control plane:

• Centralized MCP registry that lets you register and manage all approved servers in one place, so developers connect to the Gateway instead of managing individual server connections locally.
• Unified authentication where developers authenticate once with a TrueFoundry API key or IdP token (Okta, Azure AD, Auth0), and the Gateway handles outbound auth to each downstream server.
• Role-based access control that governs which users and teams can reach which servers and tools, enforcing least-privilege from the dashboard.
• Tool-level governance that lets you disable individual tools on a server or aggregate tools from multiple servers into a virtual MCP server that exposes only an approved subset per team.
• Guardrails that apply pre-execution checks, real-time blocking, and post-execution validation on tool calls.
• Full audit trail where every tool invocation is traced with user attribution, request/response payloads, and latency data.

You can lock it down in managed-settings.json:

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

The empty strictKnownMarketplaces array blocks all marketplace-sourced MCP installations. On managed devices, you can deploy a managed-mcp.json via MDM to pre-seed machines with approved servers, and once deployed, developers cannot add servers beyond those defined in the file.

Data Retention and Compliance

Anthropic may retain prompts and outputs by default for safety and quality improvement, but you have three levers to control retention.

Retention Settings by Interface

For Claude.ai, you can set retention to a maximum of 30 days at Organization Settings > Data and Privacy. For Claude Code, use the transcriptRetentionDays setting in managed-settings.json with a value of 7-14 days as a sensible default.

Zero Data Retention (ZDR)

For regulated workloads, you should request ZDR through your Claude account team. ZDR prevents Anthropic from storing prompts or outputs beyond what is needed to serve the request, but it requires a contractual addendum. You should not process PHI or other regulated data until the addendum is signed and confirmed active.

Compliance Frameworks

• SOC 2 Type II certification is held by Anthropic and is available under NDA. Your responsibility includes documented provisioning/deprovisioning procedures, 90+ day log retention, and a current vendor risk assessment.
• HIPAA compliance requires ZDR plus mandatory human review of all outputs involving patient data, along with a complete audit trail of every PHI interaction.
• GDPR compliance requires data residency (AWS EU regions or Vertex with Private Service Connect), documented deletion workflows via the Compliance API, and deny rules to block PII-containing content.

Audit Logging and Cost Controls

You should export audit logs to your SIEM on a regular schedule and retain them for a minimum of 90 days for SOC 2 or longer for regulated industries. What to capture varies by interface:

• Web requires logging of session start/end events, file uploads, and conversation metadata.
• Desktop requires logging of MCP server connections, tool invocations, and external service calls.
• CLI requires logging of tool invocations, file access patterns, shell command execution, and denied actions.

When Claude traffic flows through TrueFoundry AI Gateway, every request is traced with full user attribution across both LLM and MCP requests. A unified dashboard provides real-time metrics, and all traces export to Grafana, Datadog, or Splunk via OpenTelemetry.

Administrators can also configure OpenTelemetry settings natively in the managed settings file for direct telemetry export from Claude Code.

For costs, set hard monthly spending limits per user and per team in the Admin Console. Without these caps, a misconfigured pipeline can burn through your budget overnight. Per-user and per-model breakdowns are useful for chargeback reporting, anomaly detection, and broader AI cost observability.

Conclusion

Securing Claude is not one decision but a stack of them — identity, model routing, sandboxing, MCP governance, data retention, audit logging, and cost controls — each applied differently depending on the interface. The web version needs DLP controls and domain capture. The desktop app needs a tool-by-tool review. Claude Code needs a locked-down managed-settings.json deployed via MDM with native sandboxing enabled.

The common thread across all three is that you should route traffic and MCP access through a centralized gateway you control. One endpoint, one policy set, and one audit trail. TrueFoundry AI Gateway provides that layer for both LLM traffic and MCP server governance, with built-in access control, rate limiting, guardrails, and observability.

Start with SSO and domain capture today, then enforce managed settings across your fleet, and route everything through a gateway you control. The CVEs are real, and the exposure grows with every developer who opens Claude Code.