Claudeのエンタープライズセキュリティ：エンジニアリングチームのための実践的なガバナンスガイド

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.corp
export 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 仮想MCPサーバー チームごとに承認されたサブセットのみを公開する。
• ガードレール ツール呼び出しに対して、実行前チェック、リアルタイムブロック、実行後検証を適用する。
• 完全な 監査証跡 すべてのツール呼び出しが、ユーザーの帰属情報、リクエスト/レスポンスのペイロード、およびレイテンシーデータとともに追跡される。

managed-settings.jsonでロックダウンできます。

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

空のstrictKnownMarketplaces配列は、マーケットプレイスから提供されるすべてのMCPインストールをブロックします。管理対象デバイスでは、MDM経由でmanaged-mcp.jsonを展開して、承認済みサーバーをマシンに事前に設定できます。一度展開されると、開発者はファイルで定義されたサーバー以外を追加できません。

データ保持とコンプライアンス

Anthropicは、安全性と品質向上のため、プロンプトと出力をデフォルトで保持する場合がありますが、保持を制御するための3つの手段があります。

インターフェース別の保持設定

Claude.aiの場合、保持期間を最大30日に設定できます。場所は 組織設定 > データとプライバシー。Claude Codeの場合、managed-settings.jsonのtranscriptRetentionDays設定を、妥当なデフォルトとして7～14日の値で使用してください。

データ保持ゼロ (ZDR)

規制対象のワークロードの場合、リクエストする必要があります ZDR Claudeアカウントチームを通じて行われます。ZDRは、リクエストの処理に必要な範囲を超えてAnthropicがプロンプトや出力を保存することを防ぎますが、契約上の追加条項が必要です。追加条項が署名され、有効であることが確認されるまで、PHIやその他の規制対象データを処理すべきではありません。

コンプライアンスフレームワーク

• SOC 2 Type II 認証はAnthropicが取得しており、NDAに基づき提供可能です。お客様の責任には、文書化されたプロビジョニング/デプロビジョニング手順、90日以上のログ保持、および最新のベンダーリスク評価が含まれます。
• HIPAA 遵守にはZDRに加え、患者データを含むすべての出力に対する必須の人間によるレビュー、およびすべてのPHIインタラクションの完全な監査証跡が必要です。
• GDPR 遵守には データレジデンシー (AWS EUリージョンまたはPrivate Service Connectを使用したVertex)、コンプライアンスAPIを介した文書化された削除ワークフロー、およびPIIを含むコンテンツをブロックするための拒否ルールが必要です。

監査ログとコスト管理

監査ログは定期的にSIEMにエクスポートし、SOC 2の場合は最低90日間、規制対象業界の場合はそれ以上の期間保持する必要があります。取得すべき内容はインターフェースによって異なります。

• Web では、セッションの開始/終了イベント、ファイルのアップロード、および会話のメタデータのログ記録が必要です。
• デスクトップ では、MCPサーバー接続、ツール呼び出し、および外部サービス呼び出しのログ記録が必要です。
• CLI では、ツール呼び出し、ファイルアクセスパターン、シェルコマンド実行、および拒否されたアクションのログ記録が必要です。

Claudeのトラフィックが以下を介して流れる場合 TrueFoundry AI Gateway、すべてのリクエストは、LLMとMCPの両方のリクエストにわたって、完全なユーザー属性とともにトレースされます。統合ダッシュボードはリアルタイムのメトリクスを提供し、すべてのトレースはGrafana、Datadog、またはSplunkにエクスポートされます。 OpenTelemetry。

管理者は、 OpenTelemetryの設定 をマネージド設定ファイル内でネイティブに設定し、Claude Codeから直接テレメトリをエクスポートすることもできます。

コストについては、厳格な月間 支出制限 を管理コンソールでユーザーごと、チームごとに設定します。これらの上限がないと、設定ミスのあるパイプラインが一晩で予算を使い果たしてしまう可能性があります。ユーザーごと、モデルごとの内訳は、チャージバックレポート、異常検出、およびより広範な AIコストの可視性に役立ちます。

Here's The Evaluation Framework

Criteria	What should you evaluate ?	Priority	TrueFoundry
Identity, Access Control & Secret Protection
Central authentication	Does every model and tool request go through SSO, workload identity, service accounts, or scoped gateway keys?	Must have	✅ Supported: SSO, workload identity, and scoped gateway keys.
SSO and IdP integration	Does the platform integrate with SAML, OIDC, Okta, Azure AD, or Google Workspace and sync roles from the IdP?	Must have	✅ Supported: SAML, OIDC, IdP role sync.
Role-based access control	Can RBAC restrict models, providers, tools, environments, and logs by user, team, and application?	Must have	✅ Supported: fine-grained RBAC at every resource level.
Virtual API keys	Can API keys be generated and scoped to individual apps with configurable expiration and access controls?	Must have	✅ Supported: scoped virtual keys with expiration policies.
Provider key isolation	Can applications call models without receiving raw provider keys, and can keys be rotated without app redeploys?	Must have	✅ Supported: centralized provider keys, zero-downtime rotation.

LLM Gateway Security Checklist

A practical guide used by platform & infra teams

結論

Claudeのセキュリティ確保は、単一の決定ではなく、ID管理、モデルルーティング、サンドボックス化、MCPガバナンス、データ保持、監査ログ、コスト管理といった複数の要素の積み重ねであり、これらはインターフェースによって適用方法が異なります。ウェブ版にはDLP制御とドメインキャプチャが必要です。デスクトップアプリにはツールごとのレビューが必要です。Claude Codeには、MDM経由でデプロイされ、ネイティブサンドボックスが有効化されたロックダウンされたmanaged-settings.jsonが必要です。

これら3つすべてに共通するのは、トラフィックとMCPアクセスを、自身が管理する一元化されたゲートウェイ経由でルーティングすべきだということです。1つのエンドポイント、1つのポリシーセット、そして1つの監査証跡。 TrueFoundry AI Gateway は、LLMトラフィックとMCPサーバーガバナンスの両方にそのレイヤーを提供し、アクセス制御、レート制限、ガードレール、可観測性を内蔵しています。

今日からSSOとドメインキャプチャを開始し、その後、フリート全体にマネージド設定を適用し、すべてを自身が管理するゲートウェイ経由でルーティングしてください。CVEは現実のものであり、Claude Codeを開く開発者が増えるたびにリスクは増大します。