What It Took to Actually Govern Claude Code Across Our Engineering Team

TL;DR

• Claude Code's attack surface is bigger than most teams realize - two CVEs in early 2026 showed that cloning a repo is enough to get your API keys stolen or run arbitrary code on a developer's machine


• The four gaps we found: unmanaged API keys, no centralized traffic visibility, no filesystem controls, and MCP servers running completely ungoverned


• Fixing all four required more than just patching - it needed a different mental model for how a terminal-based AI tool should be treated

A few months ago our security team flagged something in an audit: we had 60+ engineers using Claude Code, and our "governance" for it was essentially nothing. API keys were in .bash_profile files. There was no way to see what models people were hitting, what it was costing, or who had access to what. When someone left the company, we had no clean way to revoke their Claude Code access without hunting down which machine they'd set their key on.

We'd done all the right things for Claude.ai — SSO, domain capture, admin console, the works. But Claude Code is a different beast. It's not a web app. It runs in a terminal with the developer's full filesystem permissions, and it authenticates with an API key, not a browser session. None of our web-layer controls touched it.

The audit was uncomfortable. Then the CVEs made it urgent.

The wake-up call: two CVEs that changed how we thought about Claude Code

In early 2026, Check Point Research published findings on two vulnerabilities in Claude Code — CVE-2025-59536 and CVE-2026-21852 — that made me realize we'd been thinking about this wrong.

CVE-2025-59536 (CVSS 8.7): A malicious .claude/settings.json in a repository could execute arbitrary shell commands before Claude Code even showed a trust dialog. In earlier versions, hooks defined in that file ran at startup — before the user was asked to confirm anything. Cloning an attacker's repo and running claude in it was enough to get RCE on a developer's machine.

CVE-2026-21852 (CVSS 5.3): This one hit differently. Claude Code uses an environment variable called ANTHROPIC_BASE_URL to decide where to send API requests. A malicious repo could override that via its settings file, redirecting all traffic — including the authentication header carrying the developer's API key — to an attacker-controlled server. The attacker proxies requests to the real Anthropic API so nothing looks broken. The developer notices nothing. The attacker has your key.

Both are patched now (CVE-2025-59536 in v1.0.111, CVE-2026-21852 in v2.0.65). But the thing that stuck with me wasn't the specific vulnerabilities — it was the underlying assumption they exposed. We'd all been treating .claude/settings.json as passive config. It's not. In an agentic tool that can run shell commands and call external APIs, repo-level config is part of the execution layer. Same threat model as a malicious package.json postinstall script. We just weren't thinking about it that way yet.

After the CVE disclosure, my team did a sweep of our repos and found three that had .claude/settings.json files with non-standard ANTHROPIC_BASE_URL overrides. None of them were malicious — developers had put them there for legitimate local testing. But they also would have redirected traffic for anyone else who cloned those repos. We removed them and added a CI check. Then we started working on the actual governance problem.

Gap 1: API keys were completely unmanaged

This was the most embarrassing one to admit. Every developer using Claude Code had either:

a) Their own personal Anthropic key (which meant their personal billing, no audit trail, and no way to revoke on offboarding)

b) A shared team key that lived in a shared .env somewhere (which is worse)

The fix seems obvious in retrospect — issue keys through the Anthropic Admin Console with explicit expiry, store them in AWS Secrets Manager or HashiCorp Vault, and never let them touch .bash_profile or shell history. Rotate quarterly, revoke immediately on offboarding.

But the deeper fix was routing Claude Code through a gateway so the Anthropic key never lived on developer machines at all. With as the single endpoint for all MCP server access. In managed-settings.json:

{

  "allowedMcpServers": [

    { "serverUrl": "https://<your-mcp-gateway-url>/*" }

  ],

  "strictKnownMarketplaces": []

}

Setting strictKnownMarketplaces to an empty array blocks marketplace-sourced MCP server installations. Developers can no longer add random MCP servers from the Claude marketplace — any new server has to go through our review process and get registered in the gateway.

What we got from the gateway itself: each developer authenticates once, and the gateway handles downstream auth to GitHub, Jira, and everything else. RBAC controls which teams can access which tools. Every tool invocation generates an audit trace with the developer's identity, the tool name, the request and response, and the latency. We can see exactly what Claude touched during a session, not just which model it called.

The Virtual MCP Servers feature turned out to be genuinely useful for our security team's access: we set up a "security tools" endpoint that exposes only the Sentry and Datadog tools relevant to security workflows, separate from the broader set of tools available to product engineers. Agents only see what they're supposed to see.

What the end state looks like

Six months after the audit, our setup is:

Identity: SSO + domain capture for Claude.ai. All Claude Code keys are gateway virtual keys issued through TrueFoundry, rotated automatically, revoked on offboarding via a single dashboard action.

Routing: ANTHROPIC_BASE_URL pushed via MDM to all developer machines, pointing at TrueFoundry AI Gateway. Per-developer daily token limits. Per-team budget caps. Model allowlist (we've restricted certain high-cost models to specific teams that have a justified need).

Sandboxing: managed-settings.json deployed via MDM with the permission deny-list and sandbox enabled. allowManagedPermissionRulesOnly and allowManagedHooksOnly both true.

MCP: TrueFoundry MCP Gateway as the single MCP endpoint. All downstream servers registered and approved. Tool-level RBAC. Full audit trail exported to Datadog.

Audit logging: Everything flows through the gateway to Datadog via OpenTelemetry. 90-day retention. We get a weekly summary of spend by team, model, and application, and an alert if any developer's usage spikes more than 3x their 7-day average.

Is it perfect? No. BYOD is still a gap — we don't have MDM coverage on contractor machines, which means ANTHROPIC_BASE_URL enforcement is honor-system for that population. If anyone has solved BYOD Claude Code governance cleanly, I'd genuinely like to hear how. Drop it in the comments.