Claude Code for Teams and Enterprise

The decision that comes first

Most organisations overthink this. The question that matters is narrow: where does model inference run, and who is billed for it? Everything else — permissions, standards, rollout — is the same regardless of the answer.

For most organisations the answer is Claude for Teams or Claude for Enterprise. It requires no infrastructure, includes Claude on the web alongside Claude Code in one subscription, and centralises billing. You only need a cloud provider deployment if you have a specific reason: data residency, existing committed spend, or a procurement process that will not accept a new vendor.

If nobody can articulate that reason, take the simple option.

Deployment options compared

One line in that table decides it for many teams: only Teams and Enterprise include Claude on the web. Every cloud provider option is Claude Code alone. If your people also want the chat interface, a provider deployment means buying it separately.

Prompt caching is enabled by default everywhere, so that is not a differentiator.

Teams and Enterprise plans

Claude for Teams is self-service, with collaboration features, admin tools, and billing management. Right for smaller teams that want to start this week.

Claude for Enterprise adds the things a security review asks about: SSO and domain capture, role-based permissions, compliance API access, and managed policy settings for pushing configuration organisation-wide.

That last item is usually the deciding factor rather than SSO. Managed settings are how you enforce a permission rule that a developer cannot switch off locally, and until you have them, every security standard you write is a convention.

Running through a cloud provider

If you do need one, the setup is genuinely straightforward. For Amazon Bedrock and Google Cloud's Agent Platform, run claude and choose 3rd-party platform at the login prompt for an interactive wizard.

Verify what a session is actually using rather than assuming:

/status

which shows the provider, base URL, and proxy in effect. Worth running on a colleague's machine during rollout — configuration that is set organisation-wide and silently not applied is a common and expensive surprise.

Pin your model versions

This is the single most overlooked item on this page.

On any cloud provider deployment, pin specific model versions:

ANTHROPIC_DEFAULT_OPUS_MODEL
ANTHROPIC_DEFAULT_SONNET_MODEL
ANTHROPIC_DEFAULT_HAIKU_MODEL
ANTHROPIC_DEFAULT_FABLE_MODEL

Without pinning, model aliases resolve to Claude Code's built-in default for that provider. That default can lag the newest release, and it may not be enabled in your account at all — which produces a failure that looks like a Claude Code bug and is a provisioning gap.

Pinning also means you decide when people move to a new model, rather than finding out because someone's results changed on a Tuesday.

Proxies and LLM gateways

Two different things that are often confused, and can be used together.

A corporate proxy routes traffic through an HTTP/HTTPS proxy, for security monitoring or network policy. Configure with HTTPS_PROXY or HTTP_PROXY.

An LLM gateway sits between Claude Code and the provider, handling authentication and routing. Use it for centralised usage tracking across teams, custom rate limits or budgets, or central auth. Configure with ANTHROPIC_BASE_URL, or the provider-specific variants — ANTHROPIC_BEDROCK_BASE_URL, ANTHROPIC_AWS_BASE_URL, ANTHROPIC_VERTEX_BASE_URL, ANTHROPIC_FOUNDRY_BASE_URL.

If your finance team wants per-team attribution, the gateway is the answer, not the provider's billing console.

Managed settings and policy

Security teams can configure managed permissions that local configuration cannot override. This is the mechanism that turns a policy into a control.

The distinction is worth being precise about, because it decides where each of your rules belongs:

Managed settings also carry subagent definitions at the highest precedence, and can force-enable or force-disable plugins — a --plugin-dir cannot override those. So an approved plugin set is enforceable, not merely recommended.

Keep the human-readable version in CLAUDE.md alongside the enforced version. A developer who hits a wall and cannot see why will work around it; one who can read the reason usually will not.

Organisation-wide CLAUDE.md

Company-wide standards can be deployed to a system path:

These load alongside repository-level and personal files rather than replacing them, so scope each layer deliberately.

The mistake to avoid is putting too much here. An enterprise file is loaded into every session of every developer on every project, forever. It should contain only what is true everywhere: security requirements, licensing constraints, review requirements. Anything project-specific belongs in that project's file, and anything that reads as a procedure belongs in a skill. The CLAUDE.md guide covers why length is the main failure mode — and the enterprise file is where that failure compounds fastest.

Central MCP configuration

MCP connects Claude Code to your ticketing system, error logs, and internal services. Anthropic's own recommendation is that one central team configures the servers and commits a .mcp.json into the codebase, so everyone benefits without each developer wiring it up.

This is good advice for a reason beyond convenience: an MCP server is a capability grant. Centralising the configuration means one team reviews what is connected, rather than a long tail of individual setups nobody has audited. Claude Code and MCP covers the scopes and the security position in detail.

The other org-wide surface worth standardising early is CI. Claude Code and GitHub covers organisation-level app installation, shared secrets, and reusable workflows.

What a security review will ask

Five questions come up almost every time. Having answers ready shortens the process considerably.

"Where does our code go?" Depends entirely on the deployment you chose, which is why that decision comes first. A Bedrock or Foundry deployment keeps inference inside your existing cloud relationship and its data agreements; a Teams or Enterprise plan is covered by Anthropic's terms. Pick one and be able to name it.

"What can it do to our systems?" Whatever your permissions allow. This is where managed settings matter: the answer should be a policy file you can show, not a description of what developers have been asked to do.

"Can a developer turn the controls off?" Not if they are in managed settings. That is the entire point of the distinction, and it is usually the answer that ends the conversation.

"What about secrets?" Your ordinary controls apply, and the specific new risk is worth naming: an agent will happily write a working script that hard-codes a token, because that is the shortest path to what was asked. State the rule explicitly in your organisation-wide CLAUDE.md — read credentials at runtime, never hard-code, never print in full, never commit.

"Can we audit usage?" Yes, and the mechanism depends on deployment: the usage dashboard on Teams and Enterprise, CloudTrail on AWS, Cloud Audit Logs on GCP, Azure Monitor on Azure. An LLM gateway gives you a single view across all of them, which is usually what the question is really asking for.

Keeping cost predictable

The pattern that surprises finance teams is that spend is uneven. A developer doing a large refactor costs many times one answering questions, and neither is wrong.

Three levers, in order of effectiveness:

An LLM gateway with budgets and rate limits. The only mechanism that gives you central control and per-team attribution rather than after-the-fact reporting.

Model routing by task. A subagent set to model: haiku for mechanical passes costs a fraction of the session model, and the routing is per agent so nobody has to think about it. This is the cheapest real saving available and most teams never configure it.

Prompt caching, which is already on. Enabled by default across every deployment option. Worth knowing so nobody spends a sprint implementing it.

One thing not to do: cap usage so tightly that people stop using the tool for real work. The failure mode of an over-restricted rollout is quiet abandonment, which costs the whole investment rather than a slice of it.

Rolling it out without it stalling

Anthropic's guidance here matches what actually works.

Invest in documentation first. The tool is only as good as the context it has. A repository with no CLAUDE.md gives every developer the same bad first experience, and first experiences decide adoption.

Make installation one click. If your environment is custom, a scripted install is the difference between adoption and a pilot that quietly ends.

Start people on guided usage. Codebase questions, small bug fixes, asking for a plan before code. Let people build judgement about when to trust it before they run it agentically. Developers who start with "build the whole feature" and get a bad diff often conclude the tool does not work.

Configure permissions before broad rollout, not after an incident.

On building skills across the team: Anthropic runs a role-based certification programme, and some organisations use it to give a rollout structure and a shared vocabulary. It is worth knowing what it does and does not cover before budgeting for it — see is there a Claude Code certification?

One thing to add from experience: pick a first project with a verifiable outcome. A migration you can test, an audit you can measure, a bug with a reproduction. Adoption arguments are won by evidence, and "it felt faster" is not evidence.

Pitfalls

Unpinned models on a cloud provider

Aliases resolve to a provider default that can lag or be unavailable in your account. Pin them.

An enterprise CLAUDE.md that becomes a wiki

Every line is paid for by every developer on every request. Keep it to what is true everywhere.

Policy that exists only as documentation

If it matters, it belongs in managed settings. A rule in a document is a suggestion with formatting.

Choosing a cloud provider by default

It is more work and drops Claude on the web. Choose it for a reason you can state.

Assuming configuration applied

Run /status on a real machine. Silently unapplied settings are the expensive kind.

Rolling out with no shared standards

Ten developers with ten conventions produce a codebase that reads like ten codebases. Agree the standards before the volume arrives, not after.

Where to go next

The organisation-wide layer sits on top of the same building blocks everyone uses: CLAUDE.md for persistent context, skills for procedures, subagents for isolation and tool limits, and plugins for distributing an approved set. For what teams should actually be doing with it, see the complete website workflow and the prompt library.

Sources and further reading

• Claude Code: enterprise deployment overview — provider comparison, best practices, model pinning
• Claude Code: security — managed permissions
• Claude Code: memory — the enterprise CLAUDE.md paths
• Claude Code: LLM gateways
• Claude Code: MCP