TL;DR
- Claude Code resolves settings through a precedence stack - managed settings beat everything else and can't be overridden by CLI flags, project settings, or user settings - which makes the managed settings file the real enforcement point, not a suggestion.
- Server-managed settings (configured once in the admin console, no file deployment needed) are available on Team (Claude Code 2.1.38+) and Enterprise (2.1.30+) plans; audit logs and the Compliance API are Enterprise-only.
- Managed settings and audit logs cover the CLI and VS Code surface - Claude Desktop and claude.ai (the web app) are separate surfaces with different or nonexistent governance hooks, and MCP servers need their own access story on top of all of it.
The precedence stack is the actual mechanism
Per Claude Code's own settings docs, when the same setting shows up in more than one place, managed settings win, full stop - they can't be overridden by anything, including a developer editing their own local config. Below that: local, project, and user settings apply in descending priority, so a project-level rule beats a personal default but loses to whatever the managed file says.
That single fact is why managed settings, not developer training or a wiki page, are the actual governance layer. A rule that says "don't run destructive shell commands" or "block network access from tool calls" only means something if it's enforced somewhere a developer can't turn it off.
Managed settings can be deployed three ways: server-managed (configured in the claude.ai admin console, delivered to clients automatically at sign-in and re-polled hourly, no file deployment required), MDM/OS-level policies (a macOS managed-preferences domain or a Windows registry key, pushed through Jamf, Intune, or Group Policy), or file-based (managed-settings.json dropped into a system directory, with a managed-settings.d/ folder for teams to layer independent policy fragments without editing one shared file). Worth knowing: managed settings parse tolerantly - an invalid entry gets stripped with a warning instead of disabling the rest of your policy, which matters when multiple teams are contributing rules to the same fleet.
Which plan you're on actually matters here
Server-managed settings require Team (Claude Code 2.1.38 or later) or Enterprise (2.1.30 or later) - they're not available on Free, Pro, or Max. Audit logs go a step further: per Anthropic's own documentation, they're Enterprise-only, and an export aggregates the trailing 180 days of activity into a downloadable link that's live for 24 hours. The Compliance API sits behind the same Enterprise gate, and it's the difference between pulling a manual CSV export periodically and streaming audit events into a SIEM continuously.
If you're evaluating Claude Code governance for a team on anything below Team or Enterprise, there's nothing to configure yet - that's the first thing to check before writing any policy at all.
Where this stops covering you
Managed settings and audit logs are built around the CLI and VS Code extension. Two other surfaces need separate handling:
Claude Desktop uses a different managed-preferences mechanism (its own bundle identifier, separate from Claude Code's), so a policy written for the CLI doesn't automatically apply there.
claude.ai, the web app, is the hardest surface, and it's worth being precise about why: it's not just that no one has built an endpoint setting for it, it's that Anthropic doesn't allow proxying claude.ai traffic through an external gateway at all. There's no config file, no environment variable, no supported way to redirect it. The admin console's SSO, domain capture, and org-level policies are the only sanctioned levers on this surface - anything past that means intercepting traffic at the OS network layer on a managed device, which is a different (and more invasive) thing than the officially supported routing the CLI gets.
MCP servers are their own problem independent of which surface is calling them. Every MCP server a developer wires up is a new set of credentials and a new piece of attack surface - unvetted servers bring prompt-injection risk and, without a central registry, no audit trail of which tools were actually called or what data came back. The common recommendation is to route all MCP access through one gateway and allowlist only that gateway's URL in managed settings, rather than letting individual developers point Claude Code at arbitrary MCP endpoints.
Where a gateway fits into this - TrueFoundry's take specifically
This section is TrueFoundry-specific, so read it as one real implementation rather than the only way to do this. TrueFoundry's own mapping of what it can govern per Claude surface looks like this:
| Capability | Claude Web | Claude Desktop / Cowork | Claude Code (CLI / VS Code) | Claude Code Max |
|---|---|---|---|---|
| Proxy and govern models | - | Yes | Yes | Yes |
| Proxy and govern MCP servers | - | Yes | Yes | Yes |
| MDM setup | - | - | Yes | Yes |
Claude Web is the explicit exception in that table, for the reason above - Anthropic doesn't permit routing its traffic through an external gateway, so the only governance available there is SSO, domain capture, and Admin Console policy, not a gateway integration.
For Claude Code and VS Code, TrueFoundry sets ANTHROPIC_BASE_URL inside managed-settings.json, deployed and immutably locked via an open-source binary (tfy-local-ai-setup) pushed over MDM on macOS, Linux, and Windows, refreshing the gateway token on a schedule so it doesn't go stale. MCP access gets routed the same way: allowlist only the MCP Gateway's URL, and let the gateway handle RBAC, tool-level restrictions, and the audit trail instead of trusting each developer's own MCP configuration. Once traffic is behind the gateway, you get the same controls regardless of which Claude surface it came from: RBAC over users/teams/virtual accounts, per-user and per-team rate and budget limits, failover across providers via virtual models, PII/prompt-injection/content-moderation guardrails, and full request tracing.
Claude Code Max is a specific wrinkle worth naming: if you're on an Anthropic Max subscription, Claude Code reserves the Authorization header for your own Anthropic session, so the gateway authenticates separately via an x-tfy-api-key header instead of taking over that header entirely. Practically, that means developers keep signing in with their own Max subscription and Claude Code keeps working the way they're used to, while the gateway still gets usage visibility, quotas, RBAC, logs, and guardrails on top - governance without asking anyone to change their day-to-day workflow.
The honest limitation
None of this stops someone from just using a personal Claude account outside the managed fleet entirely, on a device MDM doesn't cover. Governance here is strong on the surfaces it reaches and has a real blind spot on the ones it doesn't - which is worth saying plainly rather than implying full coverage.
What's the surface your org hasn't figured out governance for yet - Desktop, the web app, or MCP servers specifically?
Top comments (0)