AI Transformation8 Oct 202617 min read

How to set up Claude Code safely for a business team

Ten steps to set up Claude Code for a business team: company accounts, permission modes, managed settings, hooks, sandbox, GitHub, hosting and training.

John Kelleher
How to set up Claude Code safely for a business team

To set up Claude Code safely for a business team, put everyone on company accounts, decide which permission modes they may use, and enforce that with managed settings and hooks rather than instructions in a CLAUDE.md file. Then give the work what a software team would have: a GitHub organisation the company owns, checks on every change, a secrets manager, hosting with test and live environments, backups and training.

This guide is for businesses where people who are not developers, often in operations, finance or sales, are building internal tools with Claude Code. The Anthropic settings below come from its public Claude Code documentation, checked on 8 Oct 2026. Claude Code changes quickly, so check the linked pages before relying on a setting name. If you would rather have the whole thing done for you, our Claude Code setup service for business teams does it as a fixed-price project. If you are still deciding whether the tool fits your business at all, start with our explainer on Claude Code for business.

What makes a Claude Code setup safe?

The controls that matter are the ones a person cannot switch off by accident or talk Claude out of. Claude Code's layers of control do not carry the same weight.

ControlWhat it doesIs it enforced?Who sets it
Permission modesDecide what Claude can do without asking firstYes, but a person can switch modes unless the organisation removes themUser, project or organisation
Permission rules (allow, ask, deny)Allow or block specific tools, commands and file pathsYes, for Claude's own tools and the shell commands it recognisesUser, project or organisation
Managed settingsApply company policy above every other settings levelYes. Staff cannot override them, although a few documented settings let a stricter personal value applyAdministrator
HooksRun your own script at set points, and can block an actionYes, every timeUser, project or organisation, or managed only
SandboxOperating-system limits on the files and websites shell commands can reachYes, for shell commands onlyUser, project or organisation
CLAUDE.mdInstructions Claude reads at the start of each sessionNo, Claude treats it as contextAnyone who can edit the repository, plus an optional company-wide file

Ten steps to set up Claude Code for a business team

1. Put everyone on company accounts

Anthropic's terms depend on the plan. Its Commercial Terms of Service apply to Team, Enterprise and Claude API users, and its Consumer Terms of Service apply to Free, Pro and Max users. A colleague building a company tool on a personal Pro account is working under consumer terms. Anthropic's own administrator guide names Claude for Teams or Enterprise as its default recommendation for organisations, and says that on Team, Enterprise and API plans it does not train models on your code or prompts. Our post on whether Claude is safe for business covers data protection, and our guide to Claude plans and pricing in the UK covers what the seats cost.

Once company seats exist, stop people signing in with anything else. The managed settings forceLoginMethod and forceLoginOrgUUID restrict sign-in to a chosen method or to your Anthropic organisation.

2. Decide which permission modes your team may use

A permission mode sets what Claude can do in a session without asking first. Anthropic documents six:

Mode (config value)What runs without askingAnthropic's suggested use
Manual (default)Reading files onlyReviewing every action, sensitive work
acceptEditsReading, editing files and common file commandsIterating on code someone is reviewing
planReading, plus commands the auto mode classifier approves where auto mode is availableExploring a codebase before changing it
autoEverything, with a second model checking actions in the backgroundLong tasks with fewer prompts
dontAskReading and pre-approved tools, with anything else refusedLocked-down scripts and CI
bypassPermissionsEverythingIsolated containers and virtual machines only

The default has changed. On Claude Code 2.1.283 or later, auto mode is the starting mode for interactive terminal and VS Code sessions, so someone installing it today will not be asked before most actions. Anthropic states that auto mode does not guarantee safety and should not replace review of sensitive operations. It says bypassPermissions gives no protection against prompt injection or unintended actions, and should only run in isolated environments without internet access.

We recommend blocking bypassPermissions for everyone with permissions.disableBypassPermissionsMode. Auto mode is a judgement call. Manual mode asks before most actions, but Anthropic's best-practice guide observes that after enough approvals people click through instead of reviewing. For low-risk internal tools we would usually keep auto mode and rely on the deny rules, hooks and sandbox in steps 3 to 5. Where the tool touches customer or financial data, remove it with permissions.disableAutoMode. A repository cannot choose either mode as the starting mode for terminal sessions: Claude Code ignores a project settings file that asks for auto or bypassPermissions.

3. Enforce the rules with managed settings

Managed settings are the company's policy. Claude Code applies them above every other level, so no user, project or command-line value overrides them, with a few security-sensitive exceptions that Anthropic lists. There are three ways to deliver them:

  • The claude.ai admin console, which requires a Team or Enterprise plan. Claude Code fetches the policy at startup and refreshes it hourly.
  • Device management, as a macOS configuration profile or a Windows registry value pushed through a tool such as Jamf, Intune or Group Policy.
  • A file called managed-settings.json in a system folder on each machine.

Lists such as deny rules merge across levels, so staff can add their own deny rules but cannot remove the company's. A short starting policy:

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./secrets/**)"],
    "disableBypassPermissionsMode": "disable"
  },
  "allowManagedHooksOnly": true,
  "sandbox": { "enabled": true }
}

That stops Claude's file tools reading the .env file and secrets folder in the project it is working in, removes bypass mode, limits hooks to company-approved ones and turns the sandbox on. To check it has landed, a team member runs /status inside Claude Code and looks for "Enterprise managed settings" on the Setting sources line.

4. Use hooks for anything that must always happen

It is tempting to write rules such as "never touch the .env file" into CLAUDE.md. Anthropic's documentation says of CLAUDE.md and Claude's auto memory: "Claude treats them as context, not enforced configuration." It advises a PreToolUse hook to block an action whatever Claude decides, and its best-practice guide describes CLAUDE.md as advisory and hooks as deterministic.

A hook is a script Claude Code runs at a fixed point, such as before a file edit. Anthropic's hooks guide shows a hook on the Edit and Write tools that blocks changes to .env, package-lock.json and anything in .git by exiting with code 2. Claude is told why the edit was refused and can adjust. PreToolUse hooks run before the permission-mode check in every mode, so a hook that blocks an edit still blocks it in bypassPermissions mode.

Keep CLAUDE.md for coding conventions and project context. A company-wide CLAUDE.md at the managed policy path cannot be excluded by individual settings, but it is still context. The same applies to Claude Skills, which our post on rolling out and governing Claude Skills covers.

5. Turn on the sandbox and know its limits

The sandbox is an operating-system boundary around the shell commands Claude runs, limiting which files and network domains they can reach. It is off by default. A user turns it on with /sandbox, and a company can enforce it through managed settings. It runs on macOS, Linux and WSL2. On native Windows, Claude Code runs commands unsandboxed.

It closes gaps that permission rules leave open. Anthropic notes that deny rules on file reads do not stop a Python or Node script that opens the file itself, and that denying Claude's web fetch tool does not stop curl if shell commands are allowed. Anthropic also states that the sandbox reduces risk without being a complete isolation boundary. Claude's file tools, hooks and MCP servers run outside it, and allowing broad domains such as github.com can create a path for data to leave. Keep the domain allowlist short. By default Claude can also ask to rerun a command that failed in the sandbox outside it, and in auto mode a classifier model makes that decision instead of a person. Setting sandbox.allowUnsandboxedCommands to false removes the option.

6. Put the code in a GitHub organisation the company owns

Code on one laptop or a personal GitHub account leaves with the person. Create a GitHub organisation in the company's name, make two people in the business owners, and add builders as members. Then protect the main branch. GitHub's branch protection rules can require a pull request with approving reviews before merging and require status checks to pass, and they block force pushes and branch deletion by default. Changes to the live version then go through a reviewed pull request, and every change leaves a record. For private repositories, GitHub offers protected branches on its paid plans (GitHub Team or Enterprise Cloud for an organisation) and not on GitHub Free.

7. Add automatic checks to every change

Anthropic offers several review tools, and each covers a different part of the work:

  • /security-review checks the diff between the current branch and the default branch on origin for risks such as injection, authentication issues and data exposure. It needs an origin remote, which step 6 gives you.
  • The security guidance plugin has Claude review its own changes while it works. Anthropic notes that none of its layers block writes or commits, and that the review can miss issues.
  • The Claude Code GitHub Action runs Claude in your repository's workflows, including a review workflow on pull requests. Quick setup through /install-github-app needs admin access to the repository. The Claude GitHub App takes a fixed set of permissions, including write access to contents, pull requests and workflows, and GitHub does not let you accept only part of it. Anthropic documents a custom GitHub App as the alternative if your policy needs fewer permissions.

Anthropic says to store keys as GitHub Secrets, grant the workflow only the permissions it needs and review Claude's changes before merging. For a secret shared across repositories it recommends a Claude Console API key, because an OAuth token is tied to the subscription of the person who created it.

Add GitHub's own checks alongside: secret scanning and push protection, which stops hardcoded credentials reaching the repository, and Dependabot alerts for vulnerable dependencies. For private repositories in an organisation, secret scanning needs GitHub Secret Protection enabled on GitHub Team or Enterprise Cloud, so check what that costs before relying on it.

All of these read source code. Anthropic's documentation says its reviews read the code in your checkout, not a running site or deployed service. Our post on what Claude Code's security review checks goes through the gap that leaves.

8. Keep secrets out of the code

Passwords and API keys belong in a secrets manager, which supplies them to each environment so they never sit in the code. We usually use Doppler. With the deny rules from step 3 and the hook from step 4, Claude cannot read or edit the project's .env file, and push protection from step 7 blocks any push that contains a secret GitHub recognises. If a key has already been pasted into code or a chat, rotate it: deleting the text does not make the key safe again.

9. Host with test and live environments and backups

Every change should reach a test environment first and go live only when it merges to the protected main branch. Keep the live database backed up, and test a restore before you need one. Hosting, domain and database accounts should all belong to the business, with no part of the live service billed to one person's card. We usually use Railway for this kind of tool.

10. Train the people building, and write it down

The controls only help if the builders understand them. Training should cover branches and pull requests, how to read the findings from the automatic checks, how to release and roll back a change, and when to stop and ask an engineer. Anthropic's free Claude Code 101 course on Claude Academy is a reasonable first step for the tool itself. Record the setup, who owns each account and the rules people follow, and reflect it in your AI policy. Our AI policy template for UK businesses is a starting point.

What this setup does not cover

These steps govern new work. They do not tell you whether an app your team has already built, and may already be using, is safe. Older code can still contain exposed keys, missing access checks or careless handling of personal data. If the tool holds personal, financial or customer data, have it reviewed before you move it into the new setup. Our vibe code audit does that for one app at a fixed price, and our risk guide for AI-built apps helps you judge how much review a given tool needs. If the question is a specific tool a colleague has built, see what to do when a colleague builds an app with AI.

How SpotDev can help

SpotDev Ready to Build covers this ground as one fixed-price project for Claude Code, Codex or Cursor: the coding tool configured with security rules, a GitHub organisation in your company's name, AI pull request review with dependency and secret scanning, a secrets manager, hosting with test and live environments and backups, documentation, and training for up to two people. It costs from £4,000 plus VAT for one builder and one app, and you pay tool subscriptions directly to the vendors. See Ready to Build for what is included and to request a quote.

Frequently asked questions

Can staff use their personal Claude accounts for company work in Claude Code?

It is better not to. Anthropic's Consumer Terms apply to Free, Pro and Max plans, and its Commercial Terms apply to Team, Enterprise and API users. Company seats let you deliver managed settings from the claude.ai admin console and restrict sign-in to your organisation, so the rules apply to everyone. Code written on a personal account is also harder for the business to recover when that person leaves.

Is a CLAUDE.md file enough to stop Claude Code doing something risky?

No. Anthropic's documentation says Claude treats CLAUDE.md as context and not as enforced configuration. Claude usually follows it, but nothing guarantees that. For anything that must always hold, such as never editing a .env file, use a PreToolUse hook, deny rules in managed settings and the sandbox. Keep CLAUDE.md for coding conventions and project context.

Which Claude Code permission mode should a business team use?

Block bypassPermissions for everyone through managed settings, because Anthropic says it offers no protection against prompt injection or unintended actions. Auto mode is now the starting mode on recent versions, and Anthropic says it does not guarantee safety. Keeping it for low-risk internal tools can be reasonable when deny rules, hooks and the sandbox are in place. Remove it where the work touches customer or financial data.

Do we need a Team or Enterprise plan to use managed settings?

Only for the admin console route. Anthropic says delivering managed settings through the claude.ai admin console requires a Team or Enterprise plan. Managed settings can also be delivered through device management, such as Jamf or Intune, or as a managed-settings.json file on each machine. Cloud sessions do not read a file on a laptop, so they need the admin console route.

Does setting up Claude Code safely make an app we have already built safe?

No. The setup controls how new work is done. An app built before it may still contain exposed keys, missing access checks or poor handling of personal data, and the review tools read source code without testing the running app. If the app holds real customer or financial data, have an engineer review it before moving it into the new setup.

Sources

Written by

John Kelleher

John is the founder and the Chief Executive at SpotDev.

LinkedInWebsite

Related articles