Claude Code in a company: the team, permissions, cost and security

Claude Code in a company is not a question about a licence but about three decisions: which account, which permissions, and what leaves the company. Each is settled before the first developer types the first command. The board usually asks the head of IT three things — should our developers be using this, what does a seat cost per person, and where does the code go — and those are the three we answer below, in the order a team has to resolve them.

We read the facts about plans, prices and settings from Anthropic’s documentation on 6 September 2026; Claude Code changes every few days (version 2.1.263 was current that day), so we give dates rather than promises. This is written for teams inside companies, not for the hobbyist developer, and it is not an installation guide — there are a dozen or more of those. Nor is it a comparison with Cursor and Copilot, or a tour of features. It is what the company settles: the account, permissions, the CLAUDE.md file, data retention, and the point at which Claude Code is the wrong choice.

What Claude Code is — in three sentences

Anthropic describes Claude Code as an agentic coding tool that reads your codebase, edits files, runs commands and integrates with development tooling. It runs as a terminal program (macOS, Linux, Windows and WSL), as an extension for VS Code, Cursor and JetBrains, as a desktop app, in the browser, and inside GitHub Actions and GitLab. The local surfaces — terminal, editor plugins and the desktop app — read the same CLAUDE.md, the same settings and the same MCP servers. Browser sessions and runs in GitHub Actions and GitLab execute on a different machine: they see what is in the repository but do not inherit local settings or locally configured MCP servers, so the deny rules on your computer do not cover them. Most of these surfaces require a Claude subscription or a Console account; the desktop app requires a paid subscription.

For a company, the two important words in that definition are “runs commands”. A chat window a developer pastes a snippet into is a confidentiality problem. A tool that installs packages, runs git push or executes a database migration script by itself is a permissions problem — the same kind as any other agent with access to company systems. That is why most of this text is about permissions rather than about the model.

One sentence about the model is needed all the same: since 1 September 2026 the default model in Claude Code is Claude Fable 5.1. It returns in the section on data retention, because it is not as neutral as it sounds.

Which account to run Claude Code on: Pro, Team, Console or Enterprise

This is the first decision and the one Polish teams most often skip. The typical scenario: a developer signs in with the private Pro account they have anyway, and works on company code. The differences between accounts are not differences in features — they are differences in the terms on which the company processes its own code. The Free plan does not include Claude Code, so the choice starts at Pro.

A developer on a private Pro account working on company code puts the company on consumer terms the company does not control. Whether that code goes into model training is decided by a setting in their private profile; the company sees neither sessions nor spend; when the employee leaves, the account leaves with them, and the history of conversations about the code goes too. That is the argument for a company account — not the Team plan’s feature list. On commercial terms (Team, Enterprise, API) Anthropic states that it does not train models on code and prompts from Claude Code unless the customer chooses to share the data.

Organisations that need to enforce this rather than merely recommend it have the managed-settings keys forceLoginMethod and forceLoginOrgUUID; they block sign-in to accounts outside the organisation on every machine covered by the policy. Without them, “we only use the company account” stays a wish.

What Claude Code costs per person — and how to work it out

Anthropic publishes prices in US dollars only and before tax; every figure below is net, in USD, per the Anthropic pricing page of 6 September 2026. Pro is 20 USD a month (17 USD billed annually), Max 100 or 200 USD. Team is 25 USD for a standard seat (20 USD annually) and 125 USD for a premium seat (100 USD annually). Self-serve Enterprise is 20 USD per seat plus usage at API rates. The API rates themselves: Fable 5.1 costs 10 USD per million input tokens and 50 USD per million output tokens, Opus 5 — 5 and 25 USD, Sonnet 5 — 2 and 10 USD. Searches for “claude pro pricing” usually land on a comparison of the chat plans; we do not repeat those here — we did that in Copilot, ChatGPT or Claude for business.

The seat price is not the ceiling, though. On Team and Enterprise each seat carries a usage allowance — a number of tokens and requests — that resets on a five-hour and a weekly window and is shared with chat. Those limits are tight under heavy agentic work and can stop a developer halfway through a task. Reserve credits billed at API rates are often a necessity for heavy users, not merely an option. Once the base allowance is exhausted, an administrator has to switch those credits on and set a spend limit for the organisation, a group or one person. So the ceiling is set by the company, not the vendor — but somebody has to set it.

On its costs page Anthropic gives its own averages from token-billed deployments: around 13 USD per developer per day of active work, 150–250 USD per developer per month, and 90% of users below 30 USD a day. These are the vendor’s numbers, not an independent measurement — treat them as an order of magnitude for a pilot, not as a budget. The analytics dashboard on Team and Enterprise shows accepted lines of code, acceptance rate and active users; Anthropic calls those metrics deliberately conservative. They show the tool is being used — not that it pays.

A worked example — illustrative figures, not a quote. A team of six developers, 20 working days a month:

• Team. 6 × 25 USD = 150 USD a month (120 USD billed annually). If the two heaviest users get premium seats: 4 × 25 + 2 × 125 = 350 USD a month (280 USD a month billed annually) — plus any credits for usage above the allowance, whose ceiling the administrator sets.
• Six private Max 5x accounts. 600 USD a month and consumer terms — the most expensive and at the same time the worst option for a company.
• Console (API) at Anthropic’s averages. 6 × 20 × 13 USD ≈ 1,560 USD a month; the 150–250 USD band gives 900–1,500 USD; the upper case at 30 USD a day is 3,600 USD. For a team of one to five people Anthropic recommends a limit of 200,000–300,000 tokens per minute and 5–7 requests per minute per user.

The conclusion is the same as for any other rollout: start with a pilot of two or three people on Team for four weeks, read /usage, and only then buy seats for everyone. Token billing makes sense when Claude Code runs in CI or in automations with nobody at the keyboard — there is then no one for a seat to belong to.

Permissions: who may run what

The rule from our page on AI agents holds here unchanged: permissions are settled before the model. An agent with a terminal is an agent, whether or not a developer is sitting at it. Claude Code has two layers for this — mode and rules.

Mode decides what the tool asks about:

An Enterprise account and an API key from the Console start in Manual mode; on those accounts the classifier calls made in auto mode count towards token usage. An organisation can switch two modes off centrally: permissions.disableAutoMode and permissions.disableBypassPermissionsMode set to "disable" in managed settings.

Rules allow or forbid specific actions in the form Tool(specifier) — three examples worth having in every repository:

• Bash(npm run test) and Bash(npm run lint) on the allow list — reviewed scripts, no prompt. The pattern Bash(npm run *) would also cover every script added to package.json later, and a script in package.json can run any command at all;
• Read(./.env) and Read(./secrets/**) on the deny list — Claude Code’s file tools will not open the file holding your keys. This is not a system boundary: a Bash subprocess has its own read path, so a hard cut-off has to come from the sandbox described below;
• WebFetch(domain:example.com) — network access limited to named domains.

The precedence is simple and worth memorising: a denial at any level beats an allow at any other, and managed rules cannot be worked around, not even with a command-line flag. On top of that sits a sandbox for Bash commands — file system and network isolation — and a working-directory boundary for writes. The syntax and the tool list are in the permissions documentation.

CLAUDE.md, rules and hooks — an instruction is not a safeguard

Three kinds of file need telling apart before a team starts writing them.

Settings (settings.json) carry the mode, the allow and deny rules, and the hooks. They live in four places of increasing precedence: ~/.claude/settings.json is the user’s personal settings across all projects; .claude/settings.json in the repository is the team’s settings, kept under version control; .claude/settings.local.json is a personal override for one project — Claude Code adds that file to the git exclusions itself when it creates it; and at the top sit managed settings: a managed-settings.json file deployed by MDM, or a policy pulled from the server from the claude.ai console. Managed settings beat everything.

CLAUDE.md is an instruction for the model: architecture, conventions, build and test commands. It can sit at company-policy level (/Library/Application Support/ClaudeCode/CLAUDE.md, /etc/claude-code/CLAUDE.md, C:\Program Files\ClaudeCode\CLAUDE.md), at user level (~/.claude/CLAUDE.md), at project level (./CLAUDE.md or ./.claude/CLAUDE.md), and as an uncommitted CLAUDE.local.md. Anthropic recommends keeping it under 200 lines and moving rules for particular paths into a .claude/rules/ directory with a paths: field in the file header, so they load only where they apply.

And here is the sentence this section exists for. The memory documentation says outright that rules in the settings are enforced by the client regardless of what the model decides, whereas instructions in CLAUDE.md shape its behaviour but are not a hard enforcement layer. Put differently: “don’t touch the prod/ directory” in CLAUDE.md is a request; Edit(prod/**) on the deny list is a block. Anything that must always happen — lint before a commit, a ban on a particular command, a write to an audit log — is written as a hook: a script run on an event, most often PreToolUse, before the tool acts. A good example of a hard safeguard is a PreToolUse hook that intercepts every Bash call and blocks it if the script tries to run, say, docker push or aws s3 cp outside the permitted environment. Hooks have over 30 events and five types (command, HTTP, MCP tool, prompt, agent), and the managed setting allowManagedHooksOnly lets an organisation block user and project hooks.

Our own example of that boundary: the rules of this site that a machine can check — Polish quotation marks, a link to the service page in every post, no links between language versions — are not a request in a prompt but tests in src/lib/blog.ts that break the build. The tool cannot break the rule, because the site then does not build.

Where company code goes — and how long it stays there

A tool is not GDPR-compliant by itself — what is or is not compliant is your use of it. Before anyone asks the compliance question, four simpler ones need answering, and all four are answered by Anthropic’s data usage documentation, as at 6 September 2026.

What leaves the machine. Every prompt, every file Claude Code reads, and the output of every command it runs — encrypted in transit (TLS 1.2 or later) to Anthropic, or to the cloud provider if configured that way. Telemetry metrics never contain code, prompts or file paths, and secrets are stripped from error reports. /feedback is a separate channel: it sends the whole session transcript, which is kept for five years. Worth telling the team, because the command looks harmless.

For how long. On commercial terms, 30 days as standard. On consumer accounts, five years if the user consented to training. Zero data retention (ZDR) is available only to qualifying organisations on the Enterprise plan, not in standard Enterprise, and the Anthropic team switches it on for the whole organisation. It has a price in features: it disables Claude Code in the browser, cloud sessions from the desktop app, remote control, and sending feedback. It also has a price in models: Fable 5.1 and Fable 5 are, per Anthropic, models that require data retention by default, so they are unavailable in a ZDR organisation, and the best alias points at Opus. “Zero retention” and “latest model” can be mutually exclusive today — check that before you promise anything to the board. Sessions flagged as a usage-policy violation may be kept for up to two years even under ZDR. The detail is on the zero data retention page.

What stays on the laptop. Session transcripts sit in plain text in ~/.claude/projects/ for 30 days (the cleanupPeriodDays setting). That is a copy of the code and of every piece of data that passed through the session — on a developer’s disk, outside the repository and outside the backup. Disk encryption and the leaver procedure have to know about that directory.

Who else. Every MCP server connected to Claude Code is a potential recipient of data, and becomes an actual one the moment the model calls its tool: it then gets that call’s arguments — the code fragments, paths or queries the model passed to it — on the server provider’s terms and outside ZDR. It does not get the whole prompt or the whole session, and a server configured but never called gets nothing. Anthropic states, moreover, that it neither audits nor manages any MCP server. A server is also a possible privilege-escalation vector — an approved one may be able to run local shell scripts or query a production database. So the list of permitted servers is a list of data recipients and of high-trust processes, and has to be treated as one. If such a server is to expose your own system’s functions to the agent, the rules by which we build one — permissions enforced on every call, no token passthrough, and acceptance tests — are set out on our AI and MCP integrations page.

GDPR: a repository holds more personal data than you think

Teams say “there’s no personal data in our code” and are usually wrong: test data copied from production, database dumps in fixtures/, logs with email addresses, issue-tracker tickets with customer names. The most effective safeguard is the same one as in all our rollouts — data you never sent needs no guarantees — and in Claude Code it takes a concrete form: Read(...) deny rules for data directories and for .env files, and, where the cut-off has to happen at the operating-system level rather than in the file tools alone, the sandbox for Bash commands.

Remember too that relying on commercial terms (Team, Enterprise, API) means signing a DPA — a data processing agreement — if any personal data could reach the model by accident, even under ZDR. What Anthropic is under the GDPR for a given operation, the processing region, and training “knowingly, not by default” are settled the same way as for any model vendor; we set that out in GDPR and LLM implementation, and how we handle those questions ourselves is on our data security and GDPR page. Whether your plan lets you pick a processing region is a question for your plan’s terms, not for articles — this one included.

AI Act: you are a deployer, and onboarding is an Article 4 measure

A company using Claude Code is a deployer under the EU AI Act, not a provider — which means different and usually far lighter obligations. One of them bears on this text directly: after the July 2026 amendment, Article 4 requires measures that build AI literacy among the people who use the systems. It is an obligation of effort, not of result, but a real one — supervised by national authorities since August 2026. Rolling Claude Code out to a team the way this text describes — the rules, the modes, the review of changes, the conversation about what leaves the company — is exactly such a measure; all that is missing is writing it down. We have collected the dates and what applies today in our AI Act technical compliance sprint.

This is a description of the technical and organisational side, not legal advice — the legal assessment belongs to your lawyer or data protection officer.

How we use Claude Code ourselves — and what does not follow from it

The site you are reading is built with Claude Code. You can check it in the public repository: of 151 commits on the main branch, 79 carry a co-author footer naming a Claude model (as at 6 September 2026), the earliest from March 2026. The repository holds one team skill — synchronising the Polish and English content — and the tests in src/lib/blog.ts mentioned above. Every pull request is read by other models before merging; a human merges.

What the repository does not hold, and why: no CLAUDE.md, no settings, no hooks. We are a one-person company, so the split between personal and team settings collapses here — the configuration is personal and deliberately kept out of version control. In a team that would be the wrong call: .claude/settings.json with its deny rules, and CLAUDE.md, belong in the repository, because that is the only place they bind everyone.

What Claude Code did well: drafting texts in Polish and English in parallel, keeping both versions in sync, checking the SEO and typography rules. What it did not replace: editing the Polish by a native speaker, and a human decision on every question where this site takes a position. It works in Polish — these texts were written that way, and Polish prompts and files cause no trouble — but the terminal interface and the documentation are in English, and “understands Polish” is our observation from practice, not a statement by Anthropic, because we found no such statement.

Why a consultancy that builds automations for clients writes about a developer tool at all: agentic coding shortens the build-and-integrate stage, the third stage in every AI implementation project. It does not shorten the audit, the pilot or the handover — and that is where projects are decided.

When Claude Code is the wrong choice

An honest text has to say this plainly. Claude Code is the wrong choice when:

• Nobody reads the changes. The tool produces code faster than the team can review it; review becomes the bottleneck, and without review what accelerates is the production of technical debt, not of product.
• The team has no repository and CI discipline yet. Without branches, tests and an automated build there is nowhere for the rules in this text to bite. That first, then the agent.
• The code must not reach a US vendor. Then the road runs through Bedrock, Vertex AI or Foundry — with a contract and a region at the cloud provider — or it does not run at all. An “EU region” on its own does not close the transfer question if support staff outside the EEA can reach the data.
• You need zero retention and the latest model at once. Today those exclude each other; decide which requirement is the hard one.
• You are buying “to have AI”, with no owner. This is the commonest pattern from our page on rollouts: the company buys licences, a month later a handful of people use it, a quarter later nobody does. The tool is the last decision in a project, not the first — we write about that in how to implement AI in a company.
• Non-developers expect a chat window. The terminal is a barrier; the desktop app lowers it, but the permissions and the concepts (repository, commit, diff) remain. For people in operations or analytics who want to wire systems together without writing code, an n8n-class tool is often the better start — we described it in our n8n guide.

Checklist before rolling Claude Code out to a team

1. A company account, not a private one. Team, Enterprise or Console; private sign-in blocked by a managed setting, if the policy is to be enforced rather than recommended.
2. The route to the model. Straight to Anthropic, or through Bedrock, Vertex AI or Foundry — a decision about the contract and about who receives the data.
3. Retention. 30 days or ZDR — with full awareness of what ZDR disables and which models it takes away.
4. Baseline permissions in .claude/settings.json. Deny rules for secrets and data, a settled defaultMode, bypass mode disabled centrally. Deny rules cover the file tools, so where a secret must also be out of reach of a Bash subprocess and an MCP server, turn on the sandbox.
5. CLAUDE.md under 200 lines, and hooks for the hard rules. The instruction for the model and the enforcement in two different files.
6. A list of permitted MCP servers — each named as a recipient of data and a potential vector of access to the system.
7. Who reads the changes, and what gates CI has. Without this the rest of the list means nothing.
8. Spend limits and /usage. A four-week pilot with two or three people, then the decision on seats.
9. GDPR. What is really in the repository; commercial terms and the vendor contract read by a lawyer; the record of processing activities updated.
10. Article 4 of the AI Act. Onboarding written up as the AI-literacy measure it already is.

What next

Choosing a tool is the last decision, not the first — including when the tool is Claude Code. Before it you have to name the process, name the number that is meant to change, check the data and settle where the human stands in that process; only then does it follow whether the team needs an agent in the terminal, a chat licence, or something else entirely. How we run such a project from audit to handover is set out on our AI implementation page. If the account, the permissions and retention are already settled and what is missing is a process the team repeats and measures, that is what our page on AI agents for development teams is about. Describe your process to us. We will tell you where we would start — including when the answer is “not yet worth it”.