DE
Contact us

Three controls decide whether a Claude Code rollout survives team two.

Pexon rolls Claude Code out across an engineering organisation on three controls: login pinned to your Anthropic organisation, spend attributed per team from a daily per-user usage report, and an execution policy shipped as managed settings developers cannot override. Repository permissions stay with whoever owns access; Pexon documents what the agent can reach.

Where the spend actually lands

The vendor report does not see every deployment path

Deployment pathWhat Anthropic’s usage report showsWhere you attribute it instead
Claude Console, API billingOne record per user per day from the Claude Code Analytics API, with estimated cost in cents USD broken down by model.Join the actor email address to the group membership in your identity provider — the report has no team dimension of its own.
Claude for Enterprise on claude.aiPer-user engagement, usage and cost through the Claude Enterprise Analytics API, plus the analytics dashboard and a CSV export.An Analytics API key carrying the read:analytics scope, created by a Primary Owner. Anthropic does not offer that API on the Teams plan.
Amazon Bedrock, Google Cloud or Microsoft FoundryNothing. Anthropic states the Claude Code Analytics API tracks usage on the Claude API only and excludes these deployments.The cloud account running the inference: invocation logs and cost allocation tags on the invoice your finance team already reconciles.
One shared API key behind CI or a gatewayOne record for the key rather than for the people: the actor is an api_key_name instead of an email address.A key per developer or per pipeline, or a gateway that stamps a team key onto every request before it leaves your network.
Any of the above, in real timeNot covered. The usage report is a daily aggregate and deliberately withholds data younger than about an hour.OpenTelemetry: claude_code.cost.usage exported over OTLP to a collector running inside your own tenant.

The first spend dashboard in a rollout is usually empty, and the reason is almost never the collector. It is that the deployment path chosen for security reasons is one the vendor report does not cover. Decide this row before you build the pipeline, not after.

Row three is the reason this page and the deployment page are separate engagements. If inference has to run inside your own boundary, attribution moves to the cloud invoice and the login pin moves to IAM, because neither key in the managed settings file reaches a cloud provider session.

The first call

For the first row, the whole spend pipeline starts as one scheduled call. An Admin API key, one UTC day per request, and a cursor when the organisation is larger than the page size:

curl "https://api.anthropic.com/v1/organizations/usage_report/claude_code?starting_at=2026-09-01&limit=1000" \
  -H "anthropic-version: 2023-06-01" \
  -H "x-api-key: $ADMIN_API_KEY"

# -> data[].actor.email_address              who
# -> data[].model_breakdown[].estimated_cost  cents USD, per model
# -> has_more / next_page                     cursor, one UTC day per call

The starting point

Nobody signs off a rollout on a demo.

The pilot ran on one repository, one enthusiast and a card somebody expensed. Taking it to the whole engineering organisation puts three questions on the desk of a person who was not in the pilot: what did each team spend, what can the agent reach through a developer's own credentials, and what may it execute without a human approving it.

We run Claude Code on our own delivery work, and none of the three becomes visible until somebody instruments it. A pilot proves the tool works. It proves nothing about whether it can be governed.

What we build

What we ship, and the one thing we hand back instead

01

Login pinned to your organisation

forceLoginMethod and forceLoginOrgUUID deployed as managed settings, so a session holding a personal credential exits at startup instead of being found in a log later. We also close what those keys do not cover: claude setup-token and the GitHub app install enforce only the login method, and cloud provider sessions authenticate against your cloud provider, so both are restricted elsewhere. On Claude for Enterprise this sits next to SSO, domain capture and role-based permissions.

02

Spend attributed per team, not per invoice

Anthropic reports Claude Code cost per user per day, in cents USD and broken down by model. We pull it on a schedule, join the actor email address against the group membership already in your identity provider, and land the result in your own warehouse — because the vendor report has no team dimension, and the team is what finance signs off. Where a daily figure is not fast enough, the OpenTelemetry path runs alongside it.

03

An execution policy that outranks the developer

A managed settings file stating what the agent may run, what it must ask for and what is denied outright, with allowManagedPermissionRulesOnly set so project and user permission rules stop applying, and disableBypassPermissionsMode set so bypass mode is not an option. On devices in your MDM we deploy it through the endpoint-managed file, because Anthropic states plainly that the server-delivered variant is a client-side control rather than a security boundary.

04

An audit trail, and settings that cannot silently drift

A PostToolUse hook delivered in the same policy runs your own audit script after every edit. forceRemoteSettingsRefresh makes startup fail closed instead of running unpoliced while the settings fetch is still in flight. And because the server-managed and endpoint-managed sources do not merge — whichever delivers a key first wins outright — we verify the active source on real machines rather than assuming both files apply.

05

The permission exposure list we hand over

The agent acts with whatever repository access the developer already had. We do not rewrite that access model: it is an identity project with its own sponsor and its own budget. What we produce is the list of what Claude Code can reach today through each developer, per repository, handed to whoever owns access. Most rollouts find out here that a grant nobody has read end to end is the actual blast radius.

What changes

  • Finance gets a euro figure per team per month, next to the seat cost, instead of one line on somebody's card statement.
  • A session authenticating into the wrong organisation stops at startup rather than being discovered during an audit.
  • What the agent may execute becomes a file security can read, review and version, instead of a habit each developer forms at 18:00.
  • The paths the login pin does not cover — setup tokens, the GitHub app install, cloud provider credentials — are closed deliberately rather than by assumption.
  • Whoever owns repository access receives a written list of what the agent reaches today, which turns the third blocker into a scheduled project instead of an open question at sign-off.

Start with the Readiness Blueprint.

€4,900 Two weeks, fixed price

We instrument spend on one team, write the managed settings policy against your real repositories, and produce the permission exposure list.

You end the fortnight with a measurement that is running and a policy file that is deployed, not a slide about either.

All prices are net and exclude VAT.

Sources: Anthropic, Claude Code Analytics API — endpoint, per-user daily records, cents USD, and the exclusion of Bedrock, Vertex and Foundry · server-managed settings — precedence, the no-merge rule, forceRemoteSettingsRefresh, and the client-side-control caveat · Claude Code authentication — which login paths forceLoginOrgUUID does and does not reach. All read 4 August 2026. Vendor documentation moves quickly; every configuration above is re-verified against the current release at the start of an engagement rather than trusted from a page.

Where row three leads

Questions before the rollout is signed

What does a Claude Code enterprise rollout actually deliver?

Three controls and a handover document. Control one pins every developer session to your Anthropic organisation. Control two produces a monthly spend figure per team, not per invoice line. Control three is a managed settings policy stating what the agent may execute, deployed so a developer cannot replace it locally. The handover lists what the agent can currently reach through each developer's own repository access, which is the part we surface rather than fix.

How do we attribute Claude Code spend to a team rather than to a person?

Anthropic reports it per person, so the team dimension is yours to build. The Claude Code Analytics API returns one record per user per day at /v1/organizations/usage_report/claude_code, with an actor field carrying either an email address or an API key name, and an estimated cost per model in cents USD. We pull that daily, join the email address against the group membership already in your identity provider, and store the result so the team roll-up survives someone changing teams. The API itself is free for organisations with Admin API access.

Does Anthropic's spend report cover Claude Code running on Bedrock or Foundry?

No. Anthropic states that the Claude Code Analytics API only tracks Claude Code usage on the Claude API, and that usage through Amazon Bedrock, Microsoft Foundry, Google Cloud or Claude Platform on AWS is not included. If inference runs in your own cloud tenant, attribution comes from that provider's invocation logs and cost allocation tags instead. This is the single most common reason a rollout has a spend dashboard showing almost nothing.

Can a developer switch off a policy we set centrally?

Not through the settings hierarchy: managed settings sit at the top tier and no other level, including command line arguments, can override them, and allowManagedPermissionRulesOnly prevents user and project permission rules from applying at all. But Anthropic is explicit that server-managed settings are a client-side control and not a security boundary, and that on an unmanaged device a user does not need admin or sudo access to bypass them. On devices in your MDM, deploy the policy through the endpoint-managed file for the stronger guarantee.

We set forceLoginOrgUUID. Is that enough to stop a personal account being used?

Close, but not on every path. Anthropic documents that claude setup-token and /install-github-app enforce only forceLoginMethod, so both can mint a token in a different organisation, and that every login path enforces forceLoginMethod only from Claude Code v2.1.212 onwards. Cloud provider sessions such as Amazon Bedrock authenticate against your cloud provider and are not blocked by either key, so those have to be restricted in your cloud IAM policies rather than in Claude Code.

Where does audit logging for Claude Code come from?

From three places, and they answer different questions. Anthropic's compliance API and audit log export cover settings changes, including the account and device that made them, and access is arranged through your Anthropic account team rather than self-serve. A PostToolUse hook delivered in managed settings runs your own script after every edit, which is how you get an internal trail. OpenTelemetry logs cover the session itself. Claude for Enterprise is the plan that lists a compliance API.

What does the rollout cost and how long does it take?

The two-week Readiness Blueprint is fixed at €4,900: we instrument spend on one team, write the managed settings policy against your actual repositories, and hand back the permission exposure list and a costed rollout plan. It is yours to keep, whoever builds it. If you want us to run the rollout afterwards, a delivery pod starts at €7,500 per month. Model consumption is billed to you directly by Anthropic, AWS or Microsoft — we do not resell tokens. All prices are net and exclude VAT.

Next step

Not a sales call. An architecture call.

Thirty minutes with the architect who would actually run the engagement.

Contact us