Governing Claude at Enterprise Scale: Identity, Claude Code & Cost

A handful of seats on Claude Teams becomes hundreds of people, engineers leaning on Claude Code all day, and a finance team asking a fair question nobody can answer cleanly: who is spending what, on which project, and who approved it? That is where Claude stops being a subscription and becomes infrastructure — and infrastructure needs governance: real identity, tiered access, governed developer access, and cost control. This guide answers the questions enterprises actually hit, and is honest about which controls are native and which you build yourself.

The problems enterprises keep hitting

If you are governing a Claude rollout, you have probably run into some of these. Each is solvable, and several are "build-it-yourself" gaps worth knowing up front:

• SSO works, but SCIM won't provision users — or group changes aren't landing on the right roles.
• You need to connect Claude to Entra ID or Okta and map directory groups to Claude access.
• Leavers still have access; you want automatic de-provisioning.
• Different teams and seniority levels need different access — and non-engineers shouldn't have Claude Code at all.
• Everyone defaults to the most expensive model; you need to curb model sprawl and cost.
• Claude Code spend is a black box — you can't attribute it per project or repo.
• You got a surprise bill, and the only "control" blocked requests outright with no warning.
• You want a 75%-of-budget alert and a daily usage report, and can't find where to turn them on.
• Budget-increase requests are a free-for-all, not tied to a manager's sign-off.
• You're outgrowing Teams and aren't sure when Enterprise is required — or what it means for your data.

The rest of this guide is the map, in the order of any enterprise agent control plane: identity, tiered access, governed dev access, cost control.

Teams vs Enterprise: when do you need to upgrade — and what about your data?

Claude Enterprise is what unlocks the controls this guide depends on: single sign-on via SAML 2.0 and OIDC, SCIM provisioning, native groups and custom roles, and the admin surface that governs the rest. If you need directory-driven identity, tiered access, or per-workspace spend controls, that is your signal to upgrade. The migration is low-drama: from claude.ai/upgrade you choose Upgrade an existing organization, and chat history, projects, memberships, and unused credits carry over in place.

Two facts belong on the migration ticket. The upgrade is not reversible — a one-way door, so confirm billing and ownership first. And some capabilities start toggled off on Enterprise — skills, code execution, and Claude Design — so re-enabling the ones you want is a day-one admin task. On data: enterprise plans are where data-governance controls live, but retention and training terms change, so point your security team to Anthropic's data-residency and zero-data-retention docs for current terms. The upgrade steps are in Anthropic's Teams-to-Enterprise guide.

How do you connect Claude to Entra ID or Okta (and fix SCIM that won't provision)?

Identity is the foundation everything sits on — the same principle we apply to agents in zero-trust identity for AI agents, now applied to people. Configure SSO first (SAML 2.0 or OIDC in the admin identity settings), which covers Entra ID, Okta, and similar providers. That order is also the most common SCIM gotcha: SCIM is Enterprise-only and requires SSO configured first, so if SCIM "won't provision," verify SSO is fully in place before anything else. With SCIM live, your IdP becomes the source of truth — users and groups provision and de-provision automatically, so a leaver loses Claude access the moment HR disables them upstream.

The subtle trap is roles. Groups are native, managed through the Admin API with a source type of direct or scim, and SCIM groups are read-only via the API because your directory owns them. But roles are attached in the claude.ai admin settings — not in your IdP. So when "SCIM group changes aren't reflecting the right roles," the fix is almost always in Claude's role bindings, not Entra or Okta: SCIM syncs membership; the role lives in Claude. Anthropic's user-management docs are the reference.

How do you give different teams different models and tools?

"Can we stop non-engineers using Claude Code?" and "Can we restrict which models a team uses?" are the same question, and the honest answer is there is no single toggle. You compose a tier from two mechanisms: custom roles in the claude.ai admin settings, and Claude Code managed settings per group on top — permissions.deny rules to disable Claude Code where it doesn't belong (with permissions.defaultMode and disableAgentView to shape the rest), and an availableModels array to scope a group's models — backed by org-wide model restrictions enforced server-side. That is also how you curb the "everyone defaults to the most expensive model" problem: set the menu per group instead of hoping people self-restrain.

Picture three illustrative tiers — Standard, Advanced, Premier (examples, not fixed Claude tiers): each gets its model set via availableModels and its Claude Code posture via permissions.deny. Managed settings arrive three ways, highest priority first: server-managed from the claude.ai admin console, file-based (/etc/claude-code/managed-settings.json on Linux/WSL, C:\Program Files\ClaudeCode\managed-settings.json on Windows), or OS-level policy. The summary: tiers are groups + roles + managed settings, not one switch — composed once, enforced consistently. See Anthropic's admin-setup and model-config docs.

How do you give engineers Claude Code without losing cost control?

Engineering is where spend concentrates and attribution usually breaks. Claude Code authenticates via Claude Enterprise login (the default and recommended path), Claude Console API keys, or cloud providers — and the default behavior is the thing to understand. By default, Claude Code auto-creates its own "Claude Code workspace" and mints per-user keys there; it does not route usage to a per-project workspace. That's fine to start, and it's exactly why, months later, you can't tell finance what the billing-service work cost versus the data-platform work.

For true per-project isolation, use the Console API key route: create a Console workspace per project (each with its own spend and rate limits), mint a workspace-scoped API key, and have engineers run Claude Code with that key exported as ANTHROPIC_API_KEY. The wrapper that makes this ergonomic is the launcher: pick a project, load its workspace key, start Claude Code pointed at the right budget. As a reference pattern, not production code:

#!/usr/bin/env bash
# claude-launch PROJECT — start Claude Code against a project's own workspace budget
project="$1"                            # e.g. billing-service
key=$(lookup_workspace_key "$project")  # fetch the project's workspace-scoped key from your vault
export ANTHROPIC_API_KEY="$key"         # usage now bills that project's Console workspace
exec claude                             # launch Claude Code with per-project cost + rate isolation

The trade-off is real: the API-key route buys per-project cost and rate isolation but sits outside Anthropic's default managed Claude Code login flow — you own key distribution (keep keys in a vault, never a repo) in exchange for clean attribution. To keep people inside your org, Claude Code supports org login gating via forceLoginMethod (claudeai) and forceLoginOrgUUID. It's the same govern-at-the-boundary instinct from governance at runtime; the authentication and workspaces docs have the specifics.

Why did we get a surprise Claude bill — and how do we prevent it?

Per-project workspaces give you the unit of accounting; the last piece is making cost a control, not a monthly shock — the discipline in FinOps for autonomous AI agents. The native building blocks: the Usage & Cost API (raw HTTP, admin key) returns tokens by model, workspace, and key at 1-minute, 1-hour, or 1-day buckets via GET /v1/organizations/usage_report/messages, and USD daily via GET /v1/organizations/cost_report — your per-team, per-project attribution. The Spend Limits API is the enforcement lever: limits are hierarchical (user, group, seat-tier, org), and when one is hit, requests are blocked, not flagged. That block-with-no-warning is the "surprise" — the control worked; the early warning was missing.

So say the quiet part plainly: Anthropic does not natively send daily usage emails, 75%-of-budget alerts, or automated approvals of increase requests — each is a small job that polls the Usage/Cost API and acts through the Spend Limits API. A daily usage email and a threshold alert that fires before requests get blocked are simple to build. For increase requests, members click Request more usage and admins approve or deny via the Spend-Limit-Increase-Requests API — which you can wrap in a budget-approval agent that reads the linked ticket, confirms the manager's sign-off, and only then approves, denying or escalating when evidence is missing. That is a deterministic governance pattern — policy, evidence, decision, audit — not a model guessing at budgets. Adapt it, log every decision, keep a human in the loop, and act only through the Admin API, Usage & Cost API, and Spend Limits API a human admin would.

Full visibility: who's doing what, across both planes

Enforcing a budget assumes you can see what's happening — and seeing all of it takes two reporting planes, because Claude runs on two surfaces. The Claude apps are where end users work (chat, projects, Claude Code in the app, Design, Cowork); the developer platform is where API and Console-key Claude Code usage lives. An org running both surfaces needs both planes — either one alone is a partial picture.

Plane one — the Analytics API (Claude Enterprise). This reports end-user activity in the Claude apps: org-wide engagement, adoption, and cost across products; active users (DAU/WAU/MAU); per-user messages, sessions, and artifacts; for Claude Code, sessions, commits, PRs, lines of code, and tool actions; token usage by model per user; per-user cost in USD; and skills and connectors adoption. It is Enterprise-only, raw HTTP with no SDK, and it uses a dedicated Analytics API key with the read:analytics scope, created in claude.ai by the Primary Owner and sent as X-Api-Key — a different key and control plane from the Console Admin key. Endpoints live under /v1/organizations/analytics/ (summaries, users, usage_report, user_usage_report, cost_report, user_cost_report, skills). Engagement data lags about a day; cost and usage about four hours (up to 24); history is available from January 1, 2026. See Anthropic's Analytics API guide, the API reference, and the usage-analytics dashboard overview.

Plane two — Usage & Cost and Claude Code Analytics (the platform). On the Console side, the Usage & Cost API reports token usage and USD cost by model, workspace, API key, and service tier, while the Claude Code Analytics API reports per-user daily developer productivity — sessions, lines added and removed, commits, PRs, tool actions, tokens, and estimated cost by model (via GET /v1/organizations/usage_report/claude_code). Both are raw HTTP with no SDK and authenticate with an Admin API key (sk-ant-admin...) or an org:admin OAuth token, sent as x-api-key. Usage & Cost data is fresh to about five minutes and Claude Code to about an hour, and Usage & Cost is also available through observability partners such as CloudZero, Datadog, Grafana, Harness, Honeycomb, and Vantage.

Two reporting planes for full Claude visibility

Reporting plane	What it shows
Claude apps — Analytics API (Enterprise; X-Api-Key, read:analytics, created in claude.ai)	End-user activity across chat, projects, Claude Code, Design, and Cowork: DAU/WAU/MAU, per-user messages, sessions, and artifacts, Claude Code sessions/commits/PRs/lines of code/tool actions, tokens by model, per-user USD cost, and skills & connectors adoption. Engagement ~1 day, cost/usage ~4h; data from 2026-01-01.
Developer platform — Usage & Cost + Claude Code Analytics (Admin key sk-ant-admin... or org:admin OAuth; x-api-key)	Programmatic API and Claude Code: tokens and USD by model, workspace, API key, and service tier; Claude Code per-user sessions, lines added/removed, commits, PRs, tool actions, tokens, and estimated cost. Usage & Cost ~5 min, Claude Code ~1h; also via CloudZero, Datadog, Grafana, Harness, Honeycomb, Vantage.

Note: Claude Code used via Amazon Bedrock is not reflected in the Enterprise Analytics API — a documented blind spot.

Two honesty notes. The planes use different keys created in different places — the Analytics key in claude.ai (Primary Owner, read:analytics), the Admin key in the Console (sk-ant-admin...) — so wiring both is a small setup task, not one credential. And that Bedrock gap matters: if engineers run Claude Code via Amazon Bedrock, account for that usage separately, because it will not show up in the Enterprise Analytics API. Everything here is HTTP-only, which is the point: these two planes are exactly the raw material the daily usage report, the 75%-of-budget alerts, and the budget-approval agent above poll. Visibility is the input; enforcement is the output.

A governed Claude deployment, end to end

Read the four moves as one throughline. Identity (SSO + SCIM) makes every user and group real and revocable. Tiered access (groups + roles + managed settings) gives each team exactly the models and tools it needs. Per-project dev access (Console workspaces + the launcher) puts a budget and rate limit where spend actually happens. And visibility plus cost governance (the Analytics and Usage/Cost APIs feeding daily reports and 75% alerts, Spend Limits that block, and an approval agent that checks evidence) turns budgets into enforced controls with an audit trail. That is what separates a Claude subscription from a governed Claude deployment — the same operating model behind the seven pillars of production-ready agentic AI.

How SPHR helps

SPHR builds and governs production AI for enterprises across the USA, Brazil, Australia, and Japan. We move teams from Claude Teams to a governed Enterprise deployment — SSO and SCIM wired to Entra ID or Okta, access tiers from groups, roles, and managed settings, per-project Console workspaces with a launcher, full usage visibility across both reporting planes, and cost governance that blocks overruns and approves increases on evidence, not vibes. As an Anthropic partner working model-agnostic and multi-cloud, we set it up to hold as you scale. If you are outgrowing Claude Teams, let's govern your Claude rollout.

Frequently asked questions

How do you connect Claude Enterprise to Microsoft Entra ID or Okta?

Configure single sign-on first, in the claude.ai admin identity settings — Claude Enterprise supports SAML 2.0 and OIDC, which covers Entra ID, Okta, and similar providers. SCIM provisioning is Enterprise-only and requires SSO to be configured first, so the order matters: SSO, then SCIM. With SCIM live, your identity provider becomes the source of truth for users and groups, and de-provisioning a leaver upstream removes their Claude access automatically.

Why won't SCIM provision users in Claude, and how do you map groups to roles?

The most common cause is order: SCIM is Enterprise-only and requires SSO configured first, so it will not provision until SSO is in place. Groups are native, managed through the Admin API with a source type of direct or scim, and SCIM groups are read-only via the API because your directory owns them. Roles, though, are attached in the claude.ai admin settings — not in the IdP — so if group changes are not landing on the right access, check the role bindings in Claude, not your identity provider.

How do you stop non-engineers from using Claude Code or expensive models?

There is no single toggle. You compose access from custom roles defined in claude.ai and Claude Code managed settings applied per group: permissions.deny rules disable Claude Code for groups that should not have it, and an availableModels array scopes which models a group may use, backed by org-wide model restrictions enforced server-side. Managed settings can be delivered from the admin console, a managed-settings.json file, or OS-level policy.

How do you isolate Claude Code cost per project?

By default Claude Code creates its own workspace and mints per-user keys there; it does not auto-route to a per-project workspace. For isolation, create a Console workspace per project — each with its own spend and rate limits — mint a workspace-scoped API key for it, and run Claude Code with that key set as ANTHROPIC_API_KEY, usually via a small launcher wrapper. The trade-off is that this API-key route sits outside Anthropic's default managed Claude Code login flow.

Why does Claude block requests at the spend limit with no warning, and how do you add alerts?

Spend limits set through the Spend Limits API are hierarchical — user, group, seat-tier, org — and enforcement is a hard block when a limit is hit, not a warning. Anthropic does not natively send threshold alerts or daily usage emails, so a 75%-of-budget warning and a daily usage report are build-it-yourself: poll the Usage and Cost API and act before the block lands. Budget-increase requests are handled through the increase-requests API, which you can wrap in an approval agent that checks for a manager's sign-off first.

How do I see what users are doing in Claude?

You need two reporting planes, because Claude runs on two surfaces. On Claude Enterprise, the Analytics API reports end-user activity in the Claude apps — active users (DAU/WAU/MAU), per-user messages, sessions, and artifacts, per-user cost, and Claude Code sessions, commits, PRs, and lines of code. On the platform, the Usage and Cost API and the Claude Code Analytics API cover the developer side — API and Claude Code usage by model, workspace, key, and user. Together they give complete visibility; each alone is only part of the picture.

Does Claude have a usage or analytics API?

Yes — several, and they are HTTP-only with no SDK. On Claude Enterprise, the Analytics API exposes org-wide engagement, adoption, and cost across the Claude apps, using a dedicated key with the read:analytics scope created in claude.ai. On the platform, the Usage and Cost API reports tokens and USD by model, workspace, and key, and the Claude Code Analytics API reports per-user developer productivity; both use an Admin API key. One caveat: Claude Code used via Amazon Bedrock does not appear in the Enterprise Analytics API.

Product capabilities described here reflect Anthropic's public documentation for Claude Enterprise, Claude Code, workspaces, and the Admin, Usage & Cost, and Spend Limits APIs as of 2026; verify current behavior in the linked docs before you build. The launcher and budget-approval agent are reference patterns to adapt, not turnkey products.