Claude Code enterprise rollout: managed settings, per-developer keys, budgets and logs

A Claude Code enterprise rollout is the work of giving every engineer Anthropic’s coding agent while the organization keeps control of five things: who is making each request, what it costs, which models and providers it reaches, which tools and MCP servers the agent can use, and whether there is a log to answer for it later. Anthropic’s plans and managed settings cover part of that. A gateway with one credential per developer covers most of the rest, and extends the same controls to Codex CLI and Cursor. This guide sets out the decisions in order, from Anthropic’s organization setup documentation and the Codex and gateway docs as published in October 2026, and walks through ai-coding-agent-governance, an MIT-licensed agent skill that turns them into a phased rollout plan.

TL;DR

• Pick the billing path first. Claude for Teams and Enterprise are per-seat with admin-console controls; the Claude Console and Amazon Bedrock, Google Cloud or Microsoft Foundry bill per token and need their own spend controls.
• Managed settings are the enforcement layer. Delivered by the admin console, MDM or a managed-settings.json file, they override every user and project setting.
• Give every developer and every CI pipeline its own credential. A shared provider key makes attribution, budgets and offboarding impossible.
• A gateway such as Bifrost puts budgets, model allowlists, MCP tool access and request logs on that credential for Claude Code, Codex CLI and Cursor at once, and allowedProviders stops Claude Code from bypassing it.
• Roll out in phases with exit criteria: baseline, policy, gateway, keys, a two-week pilot, team-by-team rollout, then close the bypasses.

What a governed rollout controls

Governance for coding agents means each control is decided once, centrally, and enforced on every machine. Agents are heavy model consumers: one session can make many model calls, read most of a repository, run shell commands and start MCP servers. Left to defaults, each developer decides all of that alone.

The ai-coding-agent-governance skill frames the job as six controls, each with the question it answers:

Security controls such as permission modes, the sandbox and hooks are covered in The Frontier Wire’s guide to Claude Code security. This piece is about the rollout and governance process around them.

Claude Code plans for teams and enterprise

Claude Code reaches an organization through one of five providers, and the choice decides billing, authentication and which admin controls exist. Anthropic’s provider guidance recommends Claude for Teams or Enterprise by default, with the Claude Console for API-first teams and the three clouds for organizations that want to inherit existing cloud compliance and billing.

Seat prices, usage windows and per-token rates are in The Frontier Wire’s guide to Claude Code pricing; Claude usage covers how plan limits are metered.

Two caveats shape mixed deployments. Some features, including cloud sessions, Code Review and Remote Control, need a claude.ai account and are unavailable through Console keys or cloud credentials alone. And on Teams and Enterprise, usage draws from each member’s seat allowance, which resets on a rolling five-hour window and a weekly window; past it, members continue only if usage credits are on, with spend limits set at the organization, group or member level.

Managed settings and how they reach machines

Managed settings are the organization’s Claude Code policy. Anthropic’s documentation says Claude Code applies them above every other level, so no user, project or command-line value overrides them, and a set of managed-only keys locks entire categories such as permission rules, hooks and MCP servers.

Four mechanisms deliver them, checked in priority order:

Anthropic notes that endpoint-managed settings are stronger on MDM-enrolled devices, because the OS protects the file, while server-managed settings suit organizations without MDM. Arrays such as permissions.deny merge across levels, so developers can extend a managed list but not shorten it; availableModels from a managed source replaces lower layers outright. To verify, run /status on one machine: the Setting sources line should read Enterprise managed settings with the winning source in parentheses.

The docs also list what a developer can still change. A managed model is a default, not a lock, so restricting models needs availableModels. A local administrator can edit the managed file itself, which is why MDM tooling redeploys it on a schedule. And managed settings bind Claude Code only: a developer calling the API from another tool is outside them.

Per-developer credentials versus a shared key

A shared provider key is the most common starting point and the worst one: every request looks the same, one leak exposes the whole organization, and offboarding means rotating the key for everyone. The fix is one credential per developer and per pipeline, with the provider key held only on a gateway.

Anthropic’s gateway rollout sequence has four steps: deploy the gateway with the provider credential, issue each developer a gateway credential “so usage is attributed to the developer and offboarding revokes one credential,” distribute the base URL and credential through managed settings and secrets tooling, and have each developer confirm the configuration. To make the gateway the only destination, set allowedProviders to ["customEndpoint"] and pin ANTHROPIC_BASE_URL in the managed file’s env block; Claude Code then refuses a session pointed anywhere else. It requires Claude Code v2.1.285 or later.

Credentials change billing. While a gateway credential or apiKeyHelper is active, requests stop using the developer’s subscription and are billed per token to whoever owns the provider key behind the gateway. Teams that want to keep Team or Enterprise seat billing can still route through a gateway for logging and budgets: Bifrost’s subscription mode has developers sign in with /login and sends the virtual key in an x-bf-vk header instead.

Deliver keys through a secret manager, not chat. Claude Code’s apiKeyHelper runs a command that prints the credential, so the key can come from Vault or a keychain and never sit in a settings file. Never put a credential in a project .claude/settings.json, which is committed.

Data residency with Bedrock, Vertex and Foundry

Data residency for Claude Code means requests reach Claude through a cloud region the organization approves. There are two ways: point Claude Code directly at Amazon Bedrock, Google Cloud’s Agent Platform or Microsoft Foundry, or point it at a gateway that holds only regional cloud credentials.

The direct route is simple. Claude Code’s Bedrock setup uses CLAUDE_CODE_USE_BEDROCK=1, AWS credentials and a region, and allowedProviders: ["bedrock"] can restrict a machine to it. The costs are in the admin docs: claude.ai-only features are unavailable, Enterprise organization model restrictions do not reach these providers so availableModels must carry them, and per-user attribution needs OpenTelemetry, Anthropic’s self-hosted Claude apps gateway or another gateway.

The gateway route keeps one developer configuration and moves the residency decision server-side. The governance skill’s per-tool reference maps Claude Code’s sonnet, opus and haiku aliases through ANTHROPIC_DEFAULT_SONNET_MODEL and its siblings to models such as bedrock/global.anthropic.claude-sonnet-4-6, and warns that leaving CLAUDE_CODE_USE_BEDROCK or CLAUDE_CODE_USE_VERTEX set sends Claude Code straight to the cloud, bypassing the gateway. For strict residency, a Bifrost virtual key can list only the regional provider; a key is deny-by-default for providers, so anything not listed is refused.

One limit applies to both routes: Anthropic’s gateway documentation states it does not support routing Claude Code to non-Claude models through any gateway. Mixing in other model families is possible at the gateway, but it is the organization’s support burden.

Budgets and rate limits

A Claude Code budget is a hard cap on what one person, team or pipeline can spend in a period. Anthropic reports that across enterprise deployments the average cost is around $13 per developer per active day and $150 to $250 per month, with 90% of users under $30 a day. The tail is what budgets are for.

Where the cap lives depends on the provider. Teams and Enterprise set spend limits in the admin console. The Console sets workspace limits, and Anthropic publishes per-user rate limit recommendations that fall as teams grow, from 200,000 to 300,000 tokens per minute per user for one to five users to 10,000 to 15,000 for more than 500, because fewer users run concurrently. On cloud providers, budgets live in the cloud billing console, which caps the account rather than the developer.

Per-developer caps on API or cloud billing need a gateway. Bifrost budgets attach to a virtual key, a team or a customer, and a request must pass every level. The skill’s design rule is two budgets per developer key, a daily cap and a monthly cap, plus a requests-per-minute limit, because “a runaway loop can spend the whole month in an afternoon” under a monthly budget alone. It also says to set limits after two weeks of data, around the 90th percentile of observed daily spend, rather than guessing. For the cost-reduction side (model choice, caching, context hygiene) see the sibling guide to LLM cost optimization and the explainer on LLM cost control with a gateway.

MCP servers and plugins

By default any developer can connect any MCP server, and a stdio server started with npx -y <package> runs code from npm with the developer’s credentials. A governed rollout decides which servers exist and enforces that on the client and, ideally, at the tool level.

On the client, Claude Code’s managed MCP patterns range from a fixed managed-mcp.json to an allowlist with allowManagedMcpServersOnly. Match entries by serverUrl or serverCommand, not serverName, which is a user-chosen label. Plugins carry MCP servers and hooks too, so strictKnownMarketplaces belongs in the same policy.

At the tool level, the skill’s pattern is one gateway MCP endpoint (https://<gw>/mcp) as the only allowlisted server, with tool access following the developer’s key. Bifrost’s MCP tool filtering gives each virtual key only the MCP clients and tools in its mcp_configs, enforced when tools are listed and when they run. A pipeline key might get get_issue and list_pull_requests from a GitHub server and nothing else. The sibling guide to MCP best practices and the survey of MCP gateways go further.

Codex CLI and Cursor in the same rollout

Most engineering organizations end up with more than one agent, and each enforces policy differently. The goal is the same credential, budget and log for every agent, which is easiest when all of them point at one gateway.

Codex CLI has its own admin layer. OpenAI’s managed configuration guide describes requirements.toml, delivered from /etc/codex/requirements.toml, macOS MDM or the cloud, which constrains approval policy, sandbox mode, web search, managed hooks, which MCP servers users can enable and which plugin marketplace sources they can add. The model provider is set in config.toml, which the governance skill says to ship through the same MDM channel and treat edits as drift. Its per-tool reference is specific: Codex needs a named [model_providers.bifrost] entry with base_url ending in /openai/v1, because setting only OPENAI_BASE_URL can leave Codex on its built-in provider, and developers who signed in with ChatGPT must run /logout first.

Cursor is the outlier. Its custom endpoint is a per-user Override OpenAI Base URL setting, and Bifrost’s Cursor guide notes the gateway must be publicly reachable, because Cursor’s backend makes the call. The skill’s per-tool reference adds that requests to Cursor’s own hosted models are billed and routed by Cursor, not the gateway, so policy has to say whether those are allowed. The comparison of AI gateways for Claude Code, Codex and Cursor covers each client’s connection in depth.

Coding agents in CI

Agents in CI, such as review bots, test fixers and migration runs, need the same controls with tighter limits, because nobody is watching the session. Each pipeline gets its own credential, separate from any human’s, with a small daily budget and an expiry for one-off jobs.

The skill’s CI rules: one virtual key per pipeline or repository, stored as a CI secret; an expires_at on keys for one-off migrations (Bifrost rejects expired keys for inference and MCP while keeping them visible for audit); an explicit tool list and no bypass mode on shared runners; and x-bf-dim-repo or x-bf-dim-workflow headers so CI spend separates from interactive use. A budget or rate-limit rejection should end the job with a clear message, not trigger a retry loop. Its GitHub Actions sketch:

- name: Agent review
  env:
    ANTHROPIC_BASE_URL: https://bifrost.internal.example.com/anthropic
    ANTHROPIC_AUTH_TOKEN: ${{ secrets.BIFROST_VK_CI_REVIEW }}
  run: claude -p "Review the diff in this PR for correctness issues" --allowedTools "Read,Grep,Glob"

Anthropic’s GitHub Actions cost guidance adds --max-turns and workflow-level timeouts.

Measuring adoption and value

Measuring a Claude Code rollout means tracking adoption, spend and delivery outcomes per team, weekly, against a baseline taken before the rollout. Usage alone shows activity, not value.

Anthropic’s analytics dashboard for Teams and Enterprise shows lines accepted, suggestion accept rate, daily active users and sessions, and, with the GitHub app installed, pull requests shipped with Claude Code assistance. Anthropic suggests reading those alongside DORA metrics. Contribution metrics cover only the claude.ai organization, not Console or cloud traffic.

Gateway logs fill the gaps and cover every agent. The skill’s list: active developers per week (distinct keys with requests), cost per active developer, the top ten spenders (“usually a misconfigured loop or the wrong default model”), cost per merged pull request touched by an agent, model mix, and friction counts such as budget rejections and 403 model-not-allowed errors. In Bifrost, virtual key metadata such as owner, team and cost center is copied onto every log entry and cannot be overridden by request headers. The sibling guide to LLM observability covers the telemetry side.

A phased rollout plan

The governance skill’s rollout-checklist.md turns these decisions into phases, each with an exit criterion that must be met before the rollout widens:

The policy template in that file fits on one page, which is the point: developers read it.

The ai-coding-agent-governance skill

ai-coding-agent-governance is an MIT-licensed Agent Skill from the build-with-ai-hq organization for rolling out Claude Code, Codex CLI, Cursor, Gemini CLI, GitHub Copilot and OpenCode with control over spend, models, providers, data, MCP tools and logs. It is on GitHub and skills.sh, and it uses Bifrost as the default control point.

Its description triggers on phrases such as “we got a surprise AI bill”, “developers share one Anthropic/OpenAI key”, “use Bedrock or Vertex for data residency”, “lock down which MCP servers people can run”, “managed settings for Claude Code” and “measure AI coding adoption and ROI”. The SKILL.md holds the audit commands (raw keys in shell profiles and repositories, agent configs, managed policy, MCP servers), the eight-step rollout plan, a managed-settings.json example, CI rules, metrics and a seven-step verification. Three references load on demand:

• per-tool-setup.md: exact gateway configuration for Claude Code (static key, vault-backed apiKeyHelper, subscription mode, model alias mapping), Codex CLI, Gemini CLI, Cursor, Copilot and OpenCode, with curl checks and pitfalls per agent.
• rollout-checklist.md: the phased plan above, owners, the policy template and an exit-criteria summary.
• virtual-keys-per-developer.md: team creation, roster-based provisioning in bash, Python and TypeScript, multi-provider keys for residency, MCP allowlists per key, expiry, rotation, offboarding and weekly spend reports.

In a test install on October 28, 2026, The Frontier Wire installed it with skills CLI 1.7.4 into an empty repository for Claude Code, Codex and Cursor. The lint_skills.py linter from the sibling agent-skills-for-teams skill reported no errors or warnings, so its SKILL.md body sits within the Agent Skills recommendation of 5,000 tokens, with the longer material (per-tool setup, the rollout checklist and a CI example) kept in references/. The skill was not run against a live gateway or fleet for this article.

npx skills add build-with-ai-hq/ai-coding-agent-governance --list
npx skills add build-with-ai-hq/ai-coding-agent-governance -a claude-code -a codex -a cursor -y
npx skills add build-with-ai-hq/ai-coding-agent-governance -g -y   # user-wide
npx skills update ai-coding-agent-governance

Example prompts: “Roll out Claude Code and Codex to the platform team with per-developer budgets.” “Developers share one Anthropic key; plan the migration.” “Write managed settings that pin Claude Code to our gateway.” “Set up a CI key for our review bot with a $5 daily cap.” The sibling skill agent-skills-for-teams, covered in the guide to agent skills for teams, handles distributing the skills themselves.

Limits of this guide

This guide covers the governance process, not Claude Code’s security controls or pricing, which have their own articles. It relies on vendor documentation read in October 2026; Claude Code’s managed keys change between releases, and the skill itself says to re-check the settings reference before shipping. Nothing here was measured on a production fleet. Bifrost is one gateway option; Anthropic’s Claude apps gateway and other gateways cover parts of the same ground.

A Claude Code enterprise rollout succeeds when every request has a name on it, every name has a budget, and the configuration that enforces both cannot be edited away on a laptop. Anthropic’s plans and managed settings provide the second half; per-developer credentials on a gateway provide the first, and carry it across Codex CLI and Cursor. The phased plan matters as much as the tooling: a baseline, a pilot with exit criteria, then closing the bypasses. Teams that want the checklist inside their agent can run npx skills add build-with-ai-hq/ai-coding-agent-governance.