Claude Code Governance: Building an Enterprise Usage Policy from Scratch

Introduction

Somebody on your team is already using Claude Code. Probably several people. The question isn't whether to allow it—that ship sailed. The question is whether you govern it before something goes wrong, or after.

Claude Code runs in your terminal with full user-level privileges. It reads files, runs bash commands, connects to MCP servers, and sends code context to Anthropic's servers for processing.

Without a usage policy, you've got API keys in Slack channels, no visibility into what the tool accesses, and no audit trail when compliance comes knocking. We've watched this happen at enough organizations to know the pattern.

Why You Need a Policy Before You Need More Seats

Most teams adopt Claude Code bottom-up. A few developers try it, get hooked, and tell their teammates. By the time platform engineering or security gets involved, 30 people are running it with default settings and no guardrails.

Three risks show up fast at that point:

• Shadow AI. Developers on personal Pro or Max accounts send proprietary code to Anthropic under consumer terms. Consumer plans default to opt-in training since October 2025. Your code might end up in training data without anyone realizing it.
• Scattered credentials. Each developer needs an API key. Keys land in .env files, Slack DMs, and dotfiles repos. Revoking access means manually tracking down every copy.
• No audit trail. When an auditor asks, "what did your AI coding tool access last quarter?"—and they will ask—you need an answer better than "we don't know."

A usage policy doesn't kill productivity. It channels it. Get the policy right, and developers work faster, and you can prove what happened.

‍

Step 1: Pick Your Plan and Authentication Model

Your governance options depend entirely on which plan you're on. Here's the honest breakdown:

• Free / Pro / Max: No managed settings. No admin controls. No Compliance API. Consumer terms apply. Not suitable for enterprise governance.
• Team: Self-serve seat management, spend caps, Claude Code analytics. Managed settings supported (v2.1.38+ for Team plans, v2.1.30+ for Enterprise). Good for small teams starting out.
• Enterprise: Everything in Team plus SCIM provisioning, role-based permissions, Compliance API, custom data retention, IP allowlisting, and HIPAA-ready options. The real governance tier.

SSO integration takes about 2-4 hours. You verify domain ownership via DNS TXT record, upload IdP metadata to the Claude Admin Console, and connect Okta, Azure AD, or whatever SAML 2.0 provider you run. Domain capture automatically enrolls new users under your org when they sign up with a company email.

Step 2: Deploy Managed Settings

Here's the core of enterprise governance. The managed-settings.json file enforces organization-wide policies that developers cannot override. Higher-level settings always win.

You have two delivery options:

• Server-managed settings (beta): Configure in Claude.ai Admin Settings > Claude Code > Managed settings. Delivers config from Anthropic's servers when developers authenticate. Works on BYOD devices. The catch: it's client-side only, so someone with sudo access can tamper with it.
• Endpoint-managed settings: Push via MDM (Jamf, Kandji, Intune) to OS-level paths. On macOS: /Library/Application Support/ClaudeCode/managed-settings.json. On Linux: /etc/claude-code/managed-settings.json. Tamper-resistant at the OS level. Stronger guarantee.

Start with a baseline policy that blocks the most dangerous operations:

{
"permissions": {
"disableBypassPermissionsMode": "disable",
"deny": [
"Bash(curl*)",
"Bash(wget*)",
"Read(**/.env)",
"Read(*/.env.)",
"Read(*/secrets/*)",
"Read(*/.ssh/*)" ],
"ask": [
"Bash(git push:*)",
"Write(**)" ]
 },
"allowManagedPermissionRulesOnly": true,
"allowManagedHooksOnly": true,
"cleanupPeriodDays": 14}

disableBypassPermissionsMode is the single most important setting. Without it, any developer can run Claude Code with --dangerously-skip-permissions and bypass every safety check you set up. Block it.

Step 3: Lock Down MCP Servers

Claude Code connects to external tools through MCP servers—Slack, GitHub, databases, and internal APIs. Each connection expands the attack surface. CVE-2025-59536 showed that malicious MCP configs in a cloned repo could execute commands before the trust dialog appeared.

Your policy should include:

• allowManagedMcpServersOnly: true — only MCP servers defined in managed settings can run. Developers can't add their own.
• An explicit allowlist of approved servers (GitHub, your internal tools, whatever you've vetted).
• Read-only access by default for any MCP server that touches production data. Write access requires a separate approval workflow.

For organizations running MCP servers at scale, routing through a centralized MCP gateway with proper access control gives you one chokepoint for authentication, rate limiting, and audit logging across every agent-tool interaction.

Step 4: Set Spend Controls

Claude Code burns through tokens fast during agentic loops. A single runaway session can rack up serious costs overnight. Without limits, nobody notices until the invoice arrives.

Set boundaries at two levels:

• Organization-level caps in the Claude Admin Console. Hard monthly ceiling for total spend.
• Per-user caps to prevent any single developer from consuming disproportionate resources.

Usage-based Enterprise plans bill all Claude Code activity at standard API rates on top of the seat fee. There's no included token allowance. Track per-developer consumption through Claude Code analytics (lines of code accepted, suggestion accept rate, usage patterns) and set alerts before caps are hit.

For more granular control, teams routing through an AI gateway can set per-team and per-project budgets, implement rate limiting, and get consolidated cost dashboards that cover both LLM and MCP usage.

Step 5: Build the Audit Trail

Your auditor doesn't care about what Claude Code can do. They care about what it did. Two tools matter here.

• Claude Code session transcripts. Every action logs locally in ~/.claude/. Useful for individual debugging but terrible for enterprise audit. No central aggregation, no search, no retention policy enforcement.
• Anthropic's Compliance API. Enterprise-only. Gives programmatic, real-time access to usage data and customer content. You can pull logs of who used Claude Code, what queries they ran, and what code was generated, and feed it all into your existing SIEM. Selective deletion lets you enforce retention policies—delete prompt data older than 30 days, for example, to satisfy GDPR requirements.

The practical setup: pipe Compliance API output into Grafana, Datadog, or Splunk via OpenTelemetry. Route LLM and MCP traffic through a centralized gateway for unified tracing with user attribution. Document your review cadence. Auditors want to see that someone looks at the logs weekly—not just that the logs exist.

Step 6: Write the Actual Policy Document

Everything above is a technical configuration. You also need an actual written policy—the thing that sits in your internal wiki, gets reviewed by legal, and gets linked in onboarding docs.

A solid Claude Code usage policy covers:

• Who can use it. Which roles, which teams, and what approval process for new access.
• What data is allowed. Classify what can and can't flow through the tool. PHI, PII, production credentials, and customer data are typically blocked unless specific agreements are in place.
• Which repos are in scope. Not every codebase should have Claude Code access. Repos with regulated data, secrets, or customer-facing infrastructure may need additional controls.
• MCP server governance. Who approves new MCP connections. What the vetting process looks like.
• Incident response. What happens if Claude Code accesses something it shouldn't. Who gets notified. How the session gets investigated.
• Cost ownership. Which team or budget center pays. How overages are handled.

Keep it short. If the policy is 40 pages, nobody reads it. Two pages with clear rules and links to configuration docs are better than a compliance novel.

Step 7: Roll Out in Phases

Don't deploy to 200 engineers on day one. That's how you find out your deny rules break someone's build pipeline on a Friday afternoon.

• Phase 1 (pilot): 5-10 developers. One team, two weeks. Test managed settings, MCP allowlists, and spend caps in real workflows. Collect feedback. Refine before expanding.
• Phase 2 (department): 20-50 developers. Pilot team members become internal champions. Add more repos, more MCP integrations. Monitor spend and adjust caps.
• Phase 3 (org-wide): Push managed settings across the fleet via MDM. Enforce SSO and domain capture. Enable Compliance API integration.

The pilot team will find every sharp edge in your config. Let them. Better to break things with 5 people than 200.

Final Verdict

Enterprise governance for Claude Code is no longer optional. Not when the tool runs with your user permissions, sends code to external servers, and connects to your internal tools through MCP.

The good news: Anthropic built real governance tooling. Managed settings that developers can't override. A Compliance API with real-time access to usage data. SSO, SCIM, spend caps, and sandboxing. The building blocks exist. Your job is to assemble them into a policy that fits your org, deploy it through MDM or server-managed settings, and enforce it from day one—not after the first incident.