Skip to main content
Claude is available across three interfaces — Claude.ai (web), Claude Desktop, and Claude Code (CLI) — each with a different attack surface and set of admin controls. This guide covers everything an enterprise admin needs to deploy all three securely.
Configure SSO and domain capture before rolling out any Claude interface to your organization. Identity controls are the foundation everything else builds on.

1. Configure SSO

Configure SSO in the Claude Admin Console to enforce identity controls across web, desktop, and CLI from a single place. Claude supports SAML 2.0 and OIDC with any compliant IdP — including Okta, Azure AD (Entra ID), Auth0, and Google Workspace. Setup guide
1

Connect your IdP

In the Claude Admin Console, configure your SAML 2.0 or OIDC connection. Enable Require SSO for Console and Require SSO for Claude to enforce SSO-based authentication and inherit MFA from your IdP.
2

Enable domain capture

Claim your corporate email domains so that any sign-in attempt with a corporate address is automatically routed to the enterprise workspace — preventing employees from using personal accounts on any interface.
3

Map IdP groups to roles

Use IdP groups to automatically assign Claude roles to users. Revoking a user in your IdP immediately blocks access across web, desktop, and CLI.
RoleCapabilities
Primary OwnerFull admin access including billing, SSO config, and admin role assignment
AdminManage users, configure policies, view audit logs — cannot change billing or ownership
MemberUse Claude within the policies set by admins

API Key Management

Claude Code and programmatic integrations authenticate via API keys — they are required for CLI usage, CI/CD pipelines, and any automation that calls Claude’s API outside of a browser session. SSO covers interactive web and desktop logins, but API keys are the identity layer for everything else.
  • Issue API keys through the Admin Console — developers should never use personal keys in a corporate context
  • Store keys in a centralized secrets manager (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault)
  • Rotate keys quarterly and revoke immediately upon suspected compromise or employee offboarding

2. Configure Models Access

Control which models are available to your organization and how Claude traffic is routed.

Model Restrictions

Prevent developers from switching to higher-cost or unapproved models.
{
  "allowedModels": ["claude-sonnet-4-5", "claude-haiku-4-5"]
}

Proxy Routing

Use your own LLM Gateway to inspect, log and control all Claude traffic at the network layer and governance layer. Set these environment variables on developer machines (Claude docs):
export ANTHROPIC_BASE_URL=https://your-gateway.internal.corp
export HTTPS_PROXY=https://proxy.your-company.com:8080
export ANTHROPIC_DEFAULT_OPUS_MODEL=your-opus-model-equivalent
export ANTHROPIC_DEFAULT_SONNET_MODEL=your-sonnet-model-equivalent
These environment variables apply to Claude Code (CLI) and Claude Desktop only. Model routing for Claude.ai (Web) is controlled at the organization level through the Admin Console.

Enforcing Model Routing Across Developer Machines

Setting environment variables on a single machine is straightforward — the challenge is enforcing them consistently across every developer in your organization. There are 3 approaches, each with different trade-offs.
Push a managed-settings.json file to every machine via your MDM solution (Jamf, Kandji, Mosyle, Intune) and lock it against modification at the OS level. This is Claude Code’s endpoint-managed settings approach (Claude docs).
{
  "model": "sonnet",
  "availableModels": ["sonnet", "haiku"],
  "env": {
    "ANTHROPIC_BASE_URL": "https://your-gateway.internal.corp",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "your-opus-model-equivalent",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "your-sonnet-model-equivalent"
  }
}
System-level paths:
  • macOS: /Library/Application Support/ClaudeCode/managed-settings.json
  • Linux: /etc/claude-code/managed-settings.json
Tamper-resistant and applies immediately at startup with no network dependency. Requires MDM infrastructure and only works on corporate-owned devices.
Recommended approach: Use MDM / endpoint-managed settings on corporate-managed devices for the strongest enforcement. For unmanaged or BYOD devices, use server-managed settings if you route through Anthropic’s API directly, or direct cloud provider if you need network-level control.

Route Through TrueFoundry AI Gateway

TrueFoundry AI Gateway acts as a unified proxy layer between Claude Code and your model providers. Instead of configuring each provider directly, route all Claude traffic through the Gateway to get centralized access control, routing, rate limiting, and cost governance in one place. Point Claude Code at TrueFoundry AI Gateway:
export ANTHROPIC_BASE_URL=https://<your-truefoundry-gateway-url>
Once routed through TrueFoundry, you can connect and access models from multiple providers — not just Anthropic’s direct API. Add provider accounts in the Gateway dashboard and Claude Code can reach all of them through a single endpoint.
Use Virtual Models to create a single model identifier that routes requests across multiple providers with weight-based, latency-based, or priority-based routing — and switch providers without changing any client configuration.
The Gateway enforces access control, rate limits, budget limits, and load balancing with failover on all requests before they reach the underlying provider.

Summary: Model Access Approaches

ApproachEnforcementSecurity LevelKey Trade-offs
MDM + TrueFoundry AI GatewayOS-level settings lock + centralized gatewayVery HighRoute to any model across providers, configure fallback and load balancing, full tracing and guardrails. Requires MDM infrastructure.
MDM + Anthropic DirectOS-level settings lock + direct APIHighSimplest MDM setup — single provider, no gateway needed. Limited to Anthropic models only, no cross-provider fallback or centralized governance.
MDM + AWS BedrockOS-level settings lock + cloud IAMVery HighTraffic stays within your VPC, cloud-native audit logging via CloudTrail. Locked to a single cloud provider, complex IAM setup.
MDM + Google Vertex AIOS-level settings lock + cloud IAMVery HighTraffic stays within your GCP project, cloud-native audit logging. Locked to a single cloud provider, complex IAM setup.
Server-Managed Settings (Beta)Admin Console (client-side)MediumNo MDM required — works on BYOD devices, centralized web UI. Client-side enforcement only (users with sudo can tamper), not available with third-party providers or custom ANTHROPIC_BASE_URL.
Direct AWS BedrockCloud IAM onlyHighNo MDM or gateway needed, VPC-native traffic isolation. No OS-level enforcement — developers can reconfigure locally. Single provider only.
Direct Google Vertex AICloud IAM onlyHighNo MDM or gateway needed, GCP-native traffic isolation. No OS-level enforcement — developers can reconfigure locally. Single provider only.
TrueFoundry AI Gateway (no MDM)Gateway-level controlsHighMulti-provider routing, fallback, tracing, and guardrails without MDM infrastructure. No OS-level enforcement — developers can bypass the gateway locally.

3. Configure Local Tool Access & Sandboxing

Claude Code operates directly in developers’ terminals with the same permissions as the local user — reading files, executing shell commands, and connecting to external services. Claude Desktop can also execute local tools through its sandboxed environment.
The Claude.ai web interface runs entirely in the browser — there is no local code execution. The primary risks are data exfiltration through prompts and shadow IT (employees using personal accounts to bypass corporate controls).Domain capture is the most effective web control. Once enabled, any sign-in attempt with a corporate email address is routed to the enterprise workspace — employees cannot fall back to personal accounts.From the Admin Console you can also configure:
SettingPurpose
File upload restrictionsDisable document uploads if your data classification policies require it
ArtifactsDisable the in-browser code execution environment if developers should not run untrusted code in-browser
Conversation retentionControl how long conversation history is stored and whether employees can export transcripts
Acceptable use noticesDisplay policy notices at login to set expectations on what data may be used with Claude
Restrict network egressAllow Claude to execute code and create and edit docs, spreadsheets, presentations, PDFs, and data reports. Available on web and desktop. Control Claude network access to install packages and libraries in order to perform advanced data analysis, custom visualizations, and specialized file processing. Monitor chats closely as this comes with security risks.
Best practices for web:
  • Enable domain capture and SSO enforcement before broad rollout
  • Communicate clear acceptable-use policies covering what data employees may paste into Claude
  • Classify Claude.ai as a third-party SaaS tool in your DLP tooling — apply the same controls you would to Google Docs or Notion

Sandboxing

Claude Code features native sandboxing that enforces filesystem and network isolation at the OS level (Seatbelt on macOS, bubblewrap on Linux). Instead of asking permission for each bash command, sandboxing creates defined boundaries upfront where Claude Code can work more freely with reduced risk. Claude docs The recommended posture is enabling sandbox for all developers with restrictions on network egress and filesystem writes:
{
  "sandbox": {
    "enabled": true,
    "network": {
      "httpProxyPort": 8080,
      "socksProxyPort": 8081
    }
  }
}
Key sandbox benefits:
  • Filesystem protection — cannot modify system-level files in /bin/, cannot access ~/.bashrc, and cannot read files denied in your permission settings
  • Network protection — cannot contact domains not explicitly allowed, preventing data exfiltration to attacker-controlled servers
  • Prompt injection defense — even if an attacker manipulates Claude’s behavior, the sandbox ensures the system remains secure at the OS level
Set "allowUnsandboxedCommands": false in sandbox settings to disable the escape hatch that allows commands to run outside the sandbox. This forces all commands to run sandboxed or be explicitly listed in excludedCommands.

4. Configure MCP Server Access

MCP (Model Context Protocol) servers connect Claude to external databases, APIs, SaaS tools, and internal services. Every MCP server a developer connects to expands the attack surface. This section covers how to govern which MCP servers your organization allows — a separate concern from local tool access covered above.

Risks of Unmanaged MCP Servers

Without centralized governance, MCP servers introduce prompt injection risks (malicious tool descriptions can alter Claude’s behavior), credential sprawl across developer machines, and shadow IT from ad-hoc installations of unvetted public servers. There is no audit trail of which tools were called, by whom, or what data was returned — and content retrieved by MCP servers from external sources can be weaponized for indirect data exfiltration. The recommended posture is to route all MCP server access through a centralized gateway and allowlist only that gateway URL in Claude’s managed settings. This gives you a single control point — regardless of how many MCP servers your organization uses. TrueFoundry MCP Gateway implements this pattern, purpose-built for enterprise MCP governance:
  • 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 external IdP token (Okta, Azure AD, Auth0). The Gateway handles outbound authentication to each downstream server via API keys, OAuth 2.1, or token passthrough. Learn more
  • Role-based access control — control which users and teams can access which MCP servers and tools, enforcing least-privilege from the dashboard.
  • Tool-level governance — selectively disable individual tools within a server, or aggregate tools from multiple servers into a virtual MCP server exposing only an approved subset per team.
  • Guardrails — apply pre-execution checks, real-time blocking, and post-execution validation on tool calls. Configure user approval workflows for high-risk operations. Learn more
  • Full audit trail — every tool invocation is traced with user attribution, request/response payloads, and latency data — viewable in the dashboard and exportable via OpenTelemetry. Learn more
Configure Claude’s managed-settings.json to allowlist only the gateway URL:
{
  "allowedMcpServers": [
    { "serverUrl": "https://truefoundry-mcp-gateway.your-company.com/*" }
  ],
  "deniedMcpServers": [],
  "strictKnownMarketplaces": []
}
Set strictKnownMarketplaces to an empty array ([]) to block all marketplace-sourced MCP installations unless you have explicitly reviewed and approved them.

Developer Workflow

1

Admin registers MCP servers in TrueFoundry

Register approved MCP servers in the TrueFoundry Control Plane — configuring outbound authentication, access control policies, and guardrails for each server.
2

Developer accesses MCP servers from TrueFoundry UI

Developers log into the TrueFoundry UI to see available MCP servers and copy the ready-to-use connection URL for each.
3

Configure Claude to connect through the Gateway

Add each MCP server as a remote server in Claude’s configuration, pointing to the TrueFoundry Gateway URL:
{
  "mcpServers": {
    "truefoundry-github": {
      "type": "url",
      "url": "https://<your-truefoundry-gateway-url>/mcp/v1/github/mcp"
    },
    "truefoundry-sentry": {
      "type": "url",
      "url": "https://<your-truefoundry-gateway-url>/mcp/v1/sentry/mcp"
    }
  }
}

Automate Developer Setup with MDM

On managed devices, deploy a managed-mcp.json file via MDM to pre-seed every machine with approved gateway-backed MCP servers. When deployed, this file takes exclusive control — developers cannot add or use MCP servers beyond what is defined here.
{
  "mcpServers": {
    "truefoundry-github": {
      "type": "http",
      "url": "https://<your-truefoundry-gateway-url>/mcp/v1/github/mcp"
    },
    "truefoundry-sentry": {
      "type": "http",
      "url": "https://<your-truefoundry-gateway-url>/mcp/v1/sentry/mcp"
    }
  }
}
System-level paths: macOS: /Library/Application Support/ClaudeCode/managed-mcp.json · Linux: /etc/claude-code/managed-mcp.json Combined with allowedMcpServers in managed-settings.json, this creates a fully locked-down MCP configuration. Access control decisions happen at the gateway, so you only need to update the MDM-deployed file when adding or removing entire server integrations.

Overall Managed Settings

Here is a recommended managed-settings.json that combines local tool governance, sandbox enforcement, MCP gateway allowlisting, and model routing:
{
  "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
    }
  },
  "allowedMcpServers": [
    { "serverUrl": "https://mcp-gateway.your-company.com/*" }
  ],
  "deniedMcpServers": [],
  "strictKnownMarketplaces": [],
  "env": {
    "ANTHROPIC_BASE_URL": "https://your-gateway.internal.corp",
    "HTTPS_PROXY": "https://proxy.your-company.com:8080",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "your-opus-model-equivalent",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "your-sonnet-model-equivalent"
  }
}
The primary governance mechanism for Claude Code is managed-settings.json. Policies placed at the system-level path apply to all users on the machine and cannot be overridden by developers. System-level paths:
  • macOS: /Library/Application Support/ClaudeCode/managed-settings.json
  • Linux: /etc/claude-code/managed-settings.json
Claude Code reads settings in the following priority order:
System (managed-settings.json)  ← admin-controlled, highest priority
  └── Project (.claude/settings.json)
        └── User (~/.claude/settings.json)  ← developer-controlled, lowest priority
When allowManagedPermissionRulesOnly is set to true, system-level rules are the only rules that apply — project and user settings cannot add new permissions.

5. Configure Data Retention

By default, Anthropic may retain prompts and outputs for safety and quality improvement. Audit log exports contain metadata only — not chat content or code. Review your enterprise agreement for the full scope of default retention.
Set retention to a maximum of 30 days at Organization Settings > Data and Privacy.
Local session transcripts are stored on the developer’s machine. Use transcriptRetentionDays in managed-settings.json to auto-delete after a set period (recommended 7–14 days):
{
  "transcriptRetentionDays": 14
}
Enterprise add-on that prevents Anthropic from storing prompts and outputs beyond what is needed to serve the request. Prompts are not retained after the response, session data is not used for training, and it applies across all interfaces.ZDR must be requested through your Claude account team — it requires a contractual addendum. Learn more
ZDR must be in place before any Protected Health Information (PHI) or other regulated data is processed with Claude. Do not introduce sensitive regulated data to any Claude interface until the addendum is signed and confirmed active by your account team.

6. Configure Audit Logging and Monitoring

What to Capture

Enterprise audit logging should record every Claude interaction with full user attribution across all interfaces:
InterfaceWhat to Log
WebSession start/end, file uploads, conversation metadata
DesktopMCP server connections, tool invocations, external service calls
CLITool invocations, file access patterns, shell command execution, denied actions
Export logs to your SIEM on a regular schedule. Retain for a minimum of 90 days to meet SOC 2 requirements; longer for regulated industries.

OpenTelemetry Settings

Administrators can configure OpenTelemetry settings for all users through the managed settings file. Claude docs

Using TrueFoundry AI Gateway for Observability

When Claude traffic flows through TrueFoundry AI Gateway, you get built-in observability across both LLM and MCP requests — without additional instrumentation. Request tracing — every request through the Gateway is traced with full attribution (user, model, MCP server, tool).
Metrics dashboard — a unified dashboard provides real-time visibility into model, MCP, and guardrail metrics.
All traces can be exported to any OTEL-compatible platform (Grafana, Datadog, Splunk) for integration with your existing SIEM. Learn more

7. Configure Custom Usage

Usage Limits

Set hard monthly spending limits per user and per team to prevent runaway costs. Admins configure this in the Admin Console under Usage & BillingLimits. Claude docs

Usage Reporting

The Admin Console provides per-user, per-team, and per-model usage breakdowns. Use these to:
  • Identify top consumers for cost optimization conversations
  • Attribute costs to teams for chargeback/showback reporting
  • Detect anomalous usage spikes that may indicate misuse

8. Compliance

Anthropic holds SOC 2 Type II certification, available under NDA. As an enterprise admin, your responsibilities include:
  • User provisioning and deprovisioning — document procedures and test them regularly
  • Audit log retention — retain logs for 90+ days and export them to your SIEM
  • Vendor risk assessment — maintain a current assessment of Anthropic’s security posture and contractual obligations
A Zero-Data-Retention (ZDR) addendum is required before processing Protected Health Information (PHI) with any Claude interface. Request this through your Claude account team — see Zero Data Retention. Do not introduce PHI to any interface until the addendum is signed.
Additional HIPAA requirements:
  • All outputs involving patient data require mandatory human review before use
  • Maintain a complete audit trail of every PHI interaction across all interfaces
  • Document your AI processing use cases in your HIPAA risk analysis
RequirementImplementation
Data residencyDeploy via AWS EU regions or Google Vertex AI with Private Service Connect
Right to erasureUse the Compliance API and documented deletion workflows; coordinate DSARs with Anthropic
Data minimizationConfigure deny rules (CLI) and upload restrictions (Web) to block PII-containing content
Purpose limitationDocument approved AI processing use cases in your Records of Processing Activities