Setting Up Claude Code for Enterprise Teams

Arc 2 starts today. For the next seven days I’m going deep on Claude Code — how I use it, where it works, where it doesn’t, and how to deploy it responsibly in enterprise contexts.

Let’s start at the beginning: getting it set up properly for a team.

This is where most rollouts go wrong. An engineer discovers Claude Code, starts using it personally, it’s great, they tell the team, someone creates a shared account, and six weeks later the security team finds out and asks uncomfortable questions.

The right way to do this is boring but important.

---

What Enterprise Setup Actually Involves

Rolling out Claude Code at enterprise scale touches four distinct concerns. Most teams nail one or two and skip the others.

Authentication and access control Data handling and security posture Cost management and rate limits Governance and acceptable use

Each one has real decisions in it. Let me go through them.

---

Authentication and Access Control

At the individual level, Claude Code authenticates via API key. In an enterprise context, you don’t want individual engineers managing their own API keys scattered across machines and environment files.

What you want instead:

Centralised key management. API keys should be provisioned through a secrets manager — AWS Secrets Manager, Azure Key Vault, HashiCorp Vault — not hardcoded into developer environments. If someone leaves, you rotate one key in one place, not hunt down keys across twenty laptops.

Role-based access. Not everyone on a team needs the same Claude Code access tier. Developers writing code have different needs from architects reviewing designs or managers wanting summaries. Claude’s API tiers map to capability and cost — know what each role actually needs.

SSO integration. If your organisation uses Okta, Azure AD, or similar, you want Claude Code access federated through it. Anthropic’s enterprise offerings support this. Set it up. Managing a separate identity silo for AI tools is how you end up with shadow IT.

Audit logging. Know who is using the tool, when, and for what. Not to surveil engineers — to have defensible answers when the security team asks, and to catch misuse or policy violations early.

---

Data Handling and Security Posture

This is where enterprise security teams have the most questions, and where the honest answers matter.

What data leaves your environment?

When an engineer uses Claude Code, the contents of the code they share — files, snippets, questions — are sent to Anthropic’s API. This is the same fundamental model as any cloud API call. If you wouldn’t send a particular piece of data to a third-party API, you shouldn’t send it to Claude Code either.

That means: no customer PII in prompts, no production credentials, no unpublished IP that your legal team would classify as trade secrets without a proper data handling agreement in place.

Does Anthropic train on your data?

For enterprise API usage, Anthropic’s default is that your inputs are not used to train models. Verify this with your specific contract. This is a question your legal and security teams will ask — have the answer ready.

Data residency.

If your organisation has requirements about where data is processed — GDPR for EU data, sovereign cloud requirements, etc. — confirm whether Anthropic’s API endpoints meet those requirements. This is a blocker for some organisations and a non-issue for others. Know which one you are before you roll out.

Code scanning and secrets detection.

Put guardrails in place to prevent engineers from accidentally pasting API keys, database credentials, or PII into Claude Code prompts. This is a tooling problem as much as a policy problem. Pre-commit hooks that catch secrets before they get into prompts are worth the setup time.

---

Cost Management and Rate Limits

Claude Code costs money per token. At individual scale this is negligible. At team scale across hundreds of engineers, it adds up and needs to be managed.

Set up spend alerts. Anthropic’s API console lets you configure alerts at spend thresholds. Set them. Unexpected cost spikes usually mean someone wrote a loop that’s calling the API repeatedly, or a shared integration is misbehaving.

Understand your token usage patterns. Long context windows — entire files, large codebases — are expensive. Engineers who develop a habit of pasting entire repositories into every prompt will burn through budget fast. Set expectations about efficient prompting (more on this in Day 10).

Rate limit by team or role if needed. If you’re on a usage-based plan, you can manage costs by limiting which teams or roles have access to higher-context operations. Not always necessary, but useful to know you can.

Budget per team. Treat AI tooling spend like any other infrastructure cost. Give teams a budget, make it visible, let them optimise. Hidden costs create the wrong incentives.

---

Governance and Acceptable Use

This is the part engineering leaders skip because it feels like paperwork. It’s not.

Write an acceptable use policy. It doesn’t have to be long. It needs to answer: what can Claude Code be used for? What’s off-limits? How do you handle AI-generated code in production? What’s the policy on sharing proprietary code with the API?

The engineers who misuse the tool are usually not doing it maliciously — they just don’t know the boundaries. A clear policy, communicated properly, handles most of it.

AI-generated code and IP. Have your legal team weigh in on the organisation’s position on AI-generated code. What’s the policy on copyright? How is it documented in pull requests? This varies by organisation and jurisdiction, but having a clear position before it becomes a dispute is much better than after.

Human review requirements. Establish clearly that AI-generated or AI-assisted code gets the same code review as human-written code. AI tools can produce plausible-looking code with subtle bugs. The review process is a safety net — don’t let engineers skip it because “the AI wrote it.”

---

Rollout Strategy

Don’t flip the switch for everyone on day one.

Start with a pilot group — five to ten engineers who are enthusiastic, technically strong, and good at giving feedback. Run it for four to six weeks. Let them find the edges, develop team-specific best practices, and build the internal knowledge base.

Then expand to early adopters. Then everyone.

This isn’t slow — it’s how you end up with a rollout that actually sticks. Mass rollouts of AI tools that skip the pilot phase tend to result in low adoption because engineers don’t know how to use the tool well and conclude it’s not useful.

---

The Checklist Before You Go Wide

Before rolling Claude Code out to the whole team:

• API keys in secrets manager, not on developer machines
• Audit logging configured
• Data handling policy confirmed with security and legal
• Secrets/PII detection in place for prompts
• Spend alerts and budget tracking set up
• Acceptable use policy written and communicated
• AI-generated code review policy established
• Pilot group completed with learnings documented

None of this is glamorous. All of it prevents the conversation you don’t want to have six months later.

---

Day 7 of the 30-Day AI Engineering series. Previous: 11 Years In, AI-Augmented.