Three things stop a Claude Code rollout at the sign-off
Claude Code rollouts stall at sign-off on three things: nobody can attribute spend, permissions are inherited from a repository model nobody audited, and no policy states what the agent may execute. Pexon solves the first and the third — OpenTelemetry cost metrics per developer, managed settings developers cannot override — and documents the permission gap for whoever owns it.
The pilot works. That is why it proves nothing.
A pilot team is one repository, one budget line nobody looks at and one enthusiast watching every command before it runs. Take the same setup to forty developers and three questions arrive at once, none of which the pilot ever had to answer. This page is written for the person who has to sign that off, not for the developer who wants to try it.
Nobody can attribute the spend
One invoice line, no split by team, no split by repository. Finance asks what it costs per developer per month and the honest answer is that nobody instrumented it, so the budget conversation ends before it starts.
Permissions come from a repo model nobody audited
The agent acts with the permissions the developer already had. In most organisations that grant grew over years of tickets and leavers, and it has never been read end to end. Claude Code does not create that problem. It is the first thing that makes it visible.
No policy for what the agent may execute
Read-only is fine. The argument is about the rest: shell commands, network fetches, pushes to a protected branch, MCP servers somebody added in a project file last month. Without a written rule, the rule is whatever each developer clicks at 18:00.
Two of the three. We do not pretend about the second.
Spend attribution and execution policy are engineering problems with an engineering answer, and we build both: a telemetry pipeline that produces a cost figure per team, and a managed settings policy that a developer cannot switch off. Both are shipped, tested and handed over with the runbook.
The repository permission model is not ours to fix. Who may read which repository, and which of those grants outlived the person they were issued to, is an identity and ownership question inside your organisation — and rewriting it is a project with its own sponsor. What we do is make it visible: we produce the list of what the agent can currently reach through each developer, and hand it to whoever owns access. That is an honest scope, and it is the part most vendors quietly promise and then do not deliver.
Token counts do not survive a budget meeting. What survives is euros per developer per month, next to the seat cost, split by team, next to the same figure from the month before. That conversion is the point of the telemetry work — the metric Claude Code emits is already in USD, so the missing piece is the collector, the currency conversion and the team dimension, not the instrumentation.
The telemetry already exists. Nobody has collected it.
Claude Code emits OpenTelemetry metrics out of the box. It does not ship a collector, a dashboard or a policy for what may be attributed to a named person — which is why most rollouts have the data and no answer. These are the metric names, verbatim from the vendor documentation:
- claude_code.cost.usage — cost in USD, carrying model and query_source
- claude_code.token.usage — tokens, split the same way
- claude_code.session.count and claude_code.active_time.total — adoption, not spend
- claude_code.commit.count and claude_code.pull_request.count — output, if you want the ratio
- claude_code.code_edit_tool.decision — how often the agent's edits are accepted
We stand up the collector inside your tenant, aggregate to team level by default, and keep per-user attribution only where a works council agreement or equivalent policy already covers it. A telemetry stack that identifies individual engineers without that agreement does not get argued with. It gets switched off.
A policy a developer cannot switch off
Anthropic documents five settings scopes, and managed settings is the only one that cannot be overridden — it outranks command line arguments, local, project and user settings. That is the file the security review should be reading. On Linux and WSL it is /etc/claude-code/managed-settings.json; on macOS it lives under /Library/Application Support/ClaudeCode/; on Windows it is the HKLM\SOFTWARE\Policies\ClaudeCode registry key. A starting point that survives contact with a real team:
{
"$schema": "https://json.schemastore.org/claude-code-settings.json",
"permissions": {
"deny": ["Bash(curl *)", "Read(./.env)", "Read(./secrets/**)"],
"ask": ["Bash(git push *)"],
"disableBypassPermissionsMode": "disable"
},
"forceLoginMethod": "claudeai",
"forceLoginOrgUUID": "<your-organisation-uuid>",
"env": {
"CLAUDE_CODE_ENABLE_TELEMETRY": "1",
"OTEL_METRICS_EXPORTER": "otlp",
"OTEL_EXPORTER_OTLP_PROTOCOL": "http/protobuf",
"OTEL_EXPORTER_OTLP_ENDPOINT": "https://otel-collector.internal:4318"
}
}Two details that decide whether this holds. Deny and ask rules apply immediately, but allow rules in a project settings file only take effect once the workspace trust dialog has been accepted — so grants are opt-in and restrictions are not. And trust verification is disabled when Claude Code runs non-interactively with the -p flag, which is exactly how it runs in CI, so the CI path needs its own answer rather than an assumption.
Five questions, and where the answer actually is
| The review asks | Where the answer lives | Owner |
|---|---|---|
| Which organisation may a session authenticate into? | forceLoginMethod and forceLoginOrgUUID in managed settings. Claude Code exits at startup if the active credential belongs to a different organisation. | Platform |
| What may the agent run without a human? | permissions.deny and permissions.ask rules, plus disableBypassPermissionsMode set to “disable” so bypass mode is not an option. | Security |
| Can a developer override that locally? | No, if the policy ships as managed settings: that scope sits above command line arguments, local, project and user settings. | Platform |
| What did each team spend last month? | claude_code.cost.usage and claude_code.token.usage exported over OTLP to a collector you run, attributed by organization.id and user.email. | Finance |
| Which MCP servers are in scope, and who reviewed them? | The project .mcp.json and your own assessment. Anthropic states it does not security-audit or manage any MCP server. | Security |
If the model requests may not leave your cloud boundary at all, the identity and logging questions above are answered one layer down, at the deployment: Claude in your own cloud tenant covers Bedrock and Azure, the role model and where invocation logs land.
Sources: Anthropic, Claude Code settings (settings file paths and precedence) and OpenTelemetry metrics and events (metric names and attributes). Both read 4 August 2026. Vendor documentation changes; the configuration above is a starting point we verify against the current release in every engagement, not a fact about your estate.
Where a Claude Code rollout gets built
claude code
Claude Code Enterprise Rollout: Three Controls That Hold
A Claude Code rollout needs three controls: login pinned to your organisation, spend attributed per team, and an execution policy a developer cannot switch off.
Claude Code Security Review: The 12-Artefact Evidence Pack
A Claude Code security review asks for evidence, not a demo. The 12 artefacts that answer it: permission policy, sandbox boundary, MCP inventory, injection scope.
Claude Code Training for Engineering Teams
Claude Code training over five days: permissions, review discipline, what to delegate and what never to. On your own codebase, not a sample repo.
Questions the sign-off asks
What actually blocks a Claude Code rollout past the first team?
Three things, and none of them is model quality. Spend arrives as one invoice line nobody can split by team. The agent inherits whatever repository permissions the developer already had, which usually nobody has audited. And there is no written policy for what the agent may execute without a human. The pilot never surfaces any of the three, because a pilot has one team, one repository and one enthusiast watching the terminal.
How do we attribute Claude Code spend to a team or a developer?
Claude Code emits OpenTelemetry metrics, including claude_code.cost.usage in USD and claude_code.token.usage in tokens. Standard attributes on those metrics include organization.id, user.email and session.id, and cost metrics additionally carry model and query_source. Set CLAUDE_CODE_ENABLE_TELEMETRY and an OTLP exporter, point it at a collector you run, and spend becomes a figure per team instead of one line in a bill.
Can a developer switch off a permission policy we set centrally?
Not if it is deployed as managed settings. Anthropic documents five settings scopes, and managed settings sit above command line arguments, local, project and user settings and cannot be overridden. On Linux and WSL the file is /etc/claude-code/managed-settings.json, on macOS it is under /Library/Application Support/ClaudeCode/, on Windows it is the HKLM\SOFTWARE\Policies\ClaudeCode registry key. Anything you leave out of that file is negotiable in practice.
What does a security review ask for that a pilot cannot answer?
Which organisation a session may authenticate into, what the agent may execute without a human approving it, whether the developer can override that locally, what each team spent, and which MCP servers are in scope. The last one matters because Anthropic states plainly that it reviews connectors against listing criteria but does not security-audit or manage any MCP server, so that assessment is yours to do.
Does per-developer telemetry survive a works council conversation?
Only if you decide it deliberately, before you switch it on. Claude Code attaches user.email and user.account_uuid to metrics by default, and OTEL_METRICS_INCLUDE_ACCOUNT_UUID defaults to true. We default to team-level aggregation at the collector and keep per-user attribution only where a works council agreement or an equivalent policy already covers it, because a telemetry stack that identifies individual engineers gets switched off.
Do we need Claude for Enterprise, or is the Console enough?
It depends on whether you need to enforce configuration centrally. Anthropic documents Claude for Enterprise as adding SSO, domain capture, role-based permissions, a compliance API and managed policy settings for organisation-wide Claude Code configuration. The Console route bills by API and offers a Claude Code role and a Developer role for key creation. If your security review asks who can change the permission policy, that answer is easier on the plan that ships managed policy settings.
Not a sales call. An architecture call.
Thirty minutes with the architect who would actually run the engagement.