s/agents-development

Enterprise Rollout

Revision {n}

Title diff

Previous revision
Selected revision
1
 
1
Enterprise Rollout

Body diff

Previous revision
Selected revision
1
## Enterprise Rollout
1
 
2
 
3
Rolling out agent coding to ten developers is easy: everyone installs, everyone experiments. Rolling it out to three hundred is different. Licenses, auth, governance, training, metrics, compliance — and the small but real risk that an underexposed developer runs the agent with no guardrails and leaks something.
4
 
5
This page covers the phased rollout pattern that works, the managed settings mechanism that backs it, and the metrics that tell you whether it is working.
6
 
7
## Governance first, install second
8
 
9
Before anyone runs `claude`, answer:
10
 
11
1. **Who authenticates how?** Personal Claude Pro / Max, Claude for Teams, Claude for Enterprise SSO, Bedrock, Vertex, Microsoft Foundry. Pick one path and document it.
12
2. **What are the hard limits?** Which files are off-limits? Which commands (`curl`, `wget`, `git push --force`)? Which directories are production (`infra/prod/**`)?
13
3. **Who writes the rules?** Platform / DevX team owns `managed-settings.json`. Individual teams own `.claude/settings.json` in their repos.
14
4. **What happens if something goes wrong?** Incident process, rollback, responsibility.
15
5. **What metrics do you track?** See the end of this page.
16
 
17
If you cannot answer these in writing, you are not ready for 300 users.
18
 
19
## Authentication options
20
 
21
| Option | Best for | Trade-off |
22
| --- | --- | --- |
23
| **Claude for Enterprise** | Mid and large orgs | SSO, domain capture, role-based permissions, managed policy settings, compliance API |
24
| **Claude for Teams** | Smaller teams (< 50) | Self-serve, admin dashboard, shared billing, no SSO enforcement |
25
| **Claude Console** | API-billed orgs | Per-user API keys via Console, optional SSO |
26
| **Amazon Bedrock / Vertex AI / Microsoft Foundry** | Orgs with existing cloud commit | Uses cloud provider credentials; data stays in your cloud |
27
 
28
For CI and scripts, generate a long-lived OAuth token with `claude setup-token` and set `CLAUDE_CODE_OAUTH_TOKEN` in the environment.
29
 
30
## Managed settings
31
 
32
Managed settings is the enforcement mechanism. It sits above every other settings layer — user, project, and CLI overrides cannot weaken it.
33
 
34
**File-based delivery (most common):**
35
 
36
- macOS: `/Library/Application Support/ClaudeCode/managed-settings.json`
37
- Linux / WSL: `/etc/claude-code/managed-settings.json`
38
- Windows: `C:\Program Files\ClaudeCode\managed-settings.json`
39
 
40
There is also a drop-in directory alongside each of those paths, `managed-settings.d/`, where independent teams can drop policy fragments. Files merge alphabetically — use numeric prefixes (`10-telemetry.json`, `20-security.json`) to control order.
41
 
42
**Other delivery options:**
43
 
44
- Server-managed settings from the Claude.ai admin console (Enterprise only).
45
- macOS MDM via `com.anthropic.claudecode` preferences domain (Jamf, Kandji, Intune).
46
- Windows Group Policy / Intune via `HKLM\SOFTWARE\Policies\ClaudeCode`.
47
 
48
## A baseline managed policy
49
 
50
The following is a reasonable starting point. Adjust to your environment — don't copy-paste blind.
51
 
52
```json
53
{
54
  "forceLoginMethod": "claudeai",
55
  "forceLoginOrgUUID": "YOUR-ORG-UUID",
56
  "permissions": {
57
    "deny": [
58
      "Read(./.env)",
59
      "Read(./.env.*)",
60
      "Read(./secrets/**)",
61
      "Bash(curl *)",
62
      "Bash(wget *)",
63
      "Bash(git push --force*)"
64
    ],
65
    "disableBypassPermissionsMode": "disable"
66
  },
67
  "allowManagedPermissionRulesOnly": false,
68
  "sandbox": {
69
    "enabled": true
70
  },
71
  "env": {
72
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
73
    "OTEL_METRICS_EXPORTER": "otlp"
74
  },
75
  "companyAnnouncements": [
76
    "Welcome to agent coding at Acme — read the internal guide: docs.acme.com/ai"
77
  ]
78
}
79
```
80
 
81
Key settings worth knowing:
82
 
83
- `forceLoginMethod` + `forceLoginOrgUUID` — lock users to your org.
84
- `allowManagedPermissionRulesOnly` — when true, only rules in managed settings apply; project and user allow lists are ignored.
85
- `disableBypassPermissionsMode` — prevents anyone from running with all permission prompts off.
86
- `sandbox.enabled` — forces sandboxed Bash execution.
87
- `env` — inject org-wide environment vars, including telemetry.
88
- `companyAnnouncements` — cycled at session start. Good place to link to internal docs.
89
- `availableModels` — restrict which models users can select.
90
- `blockedMarketplaces` + `strictKnownMarketplaces` — lock down plugin sources.
91
 
92
A managed `CLAUDE.md` at the same path delivers org-wide behavioral guidance that developers cannot exclude.
93
 
94
## The phased rollout
95
 
96
**Phase 0: alignment (1 week).**
97
Sign off on the governance questions above. Pick the auth method. Decide which team owns managed settings.
98
 
99
**Phase 1: platform team pilot (2 weeks).**
100
Ten to twenty people who already live in the terminal. Goals:
101
 
102
- Validate the auth flow.
103
- Build the initial `managed-settings.json`.
104
- Write starter `CLAUDE.md` templates for two or three of your most common repo types.
105
- Discover the hooks you actually need (lint gate, test gate, secret scanner).
106
 
107
Ship nothing to the wider org yet.
108
 
109
**Phase 2: early adopters (4 weeks).**
110
Fifty to a hundred developers who opted in. Goals:
111
 
112
- Stress-test the guardrails. What do they work around? What do they complain about?
113
- Collect the "the agent did something weird" stories. Most will be CLAUDE.md gaps.
114
- Write the internal guide: how to install, how to write a good prompt, how to use plan mode, how to debug when the agent does not follow instructions.
115
- Set up telemetry dashboards.
116
 
117
**Phase 3: broad rollout (ongoing).**
118
Open to everyone. Keep the following running:
119
 
120
- A dedicated channel (Slack, Teams, whatever) for questions.
121
- Weekly office hours with the platform team.
122
- A shared list of known-good hooks and CLAUDE.md snippets.
123
- An updated `managed-settings.json` as new risks surface.
124
 
125
## Telemetry
126
 
127
Claude Code supports OpenTelemetry metrics. Set `CLAUDE_CODE_ENABLE_TELEMETRY=1` and route to your OTLP collector. Useful signals:
128
 
129
- **Adoption.** Active sessions per week, unique users.
130
- **Tool usage.** Top 20 tool calls, ratio of Read vs Edit vs Bash, MCP server usage.
131
- **Blocks.** How often hooks fire exit 2. How often permission denies hit. What commands get blocked.
132
- **Context use.** Session length, compactions per session, context size at end.
133
- **Model mix.** Opus vs Sonnet vs Haiku. Cost trendline.
134
- **Errors and retries.** `system/api_retry` events, reasons.
135
 
136
Watch for: hooks that fire *too* often (either the rule is wrong or developers are fighting it), sharp Opus cost spikes, blocked commands trending up in one team (that team needs training or different rules).
137
 
138
## Training, not just docs
139
 
140
A twenty-page wiki is less effective than a one-hour internal talk. The talk should cover:
141
 
142
- The mental model shift (see [Getting Started](/s/agents-development/wiki/getting-started)).
143
- Writing a good prompt vs a vague prompt.
144
- Using plan mode before big changes.
145
- How to read the permission prompt and when to say no.
146
- How to escalate when the agent does something weird.
147
 
148
Record it. Re-run it quarterly.
149
 
150
## Compliance and audit
151
 
152
For regulated environments:
153
 
154
- `cleanupPeriodDays` controls session log retention.
155
- `allowedHttpHookUrls` restricts where HTTP hooks can send data.
156
- `sandbox.network.allowManagedDomainsOnly: true` forces WebFetch through an admin-controlled allowlist.
157
- OpenTelemetry logs every tool use, model call, and retry — plug into your SIEM.
158
- `ConfigChange` hook fires when settings are modified mid-session; use it to audit or block drift.
159
 
160
## Common mistakes orgs make
161
 
162
1. **Shipping without managed settings.** Everyone runs with `bypassPermissions` and the first incident is a CV-shaped hole in someone's week.
163
2. **Writing managed settings too tightly.** If developers can't do their normal work, they will work around you — alt accounts, shadow installs, VMs.
164
3. **No CLAUDE.md templates.** Every team writes a bad one and the agent behaves badly across the org.
165
4. **No feedback channel.** Developers hit the same problems twice. You never hear about them.
166
5. **Rolling out to 300 people in one day.** Always phase.
167
 
168
---
169
 
170
## Sources
171
 
172
- [Claude Code settings reference](https://code.claude.com/docs/en/settings)
173
- [Permissions and managed-only settings](https://code.claude.com/docs/en/permissions)
174
- [Authentication options](https://code.claude.com/docs/en/authentication)
175
- [Memory and managed CLAUDE.md](https://code.claude.com/docs/en/memory)
176
- [OpenTelemetry monitoring](https://code.claude.com/docs/en/monitoring-usage)
177
- [MDM starter templates](https://github.com/anthropics/claude-code/tree/main/examples/mdm)
© 2026 HeyUpBuilt with Laravel, Vue and Tailwind.