Remote teams
Agreements for AI coding tools in a remote team
Let your remote team use Claude Code only with business accounts, put the rules in the repository and keep production keys out of the tool's reach.
Before a remote team points Claude Code or a similar tool at your code, agree on a few things: which accounts the team uses, what the tool may not read, how AI-written code goes through review and what you keep track of. Put those agreements in the repository itself, so they apply to everyone who checks out the code, wherever they sit.
Work with business accounts
The first decision is who arranges the licences and under which account. Do not let developers work on client code with a personal subscription, because the terms differ per account type.
Anthropic does not use inputs and outputs from its commercial products, such as Claude for Work and the API, to train models by default. GitHub, on the other hand, has used interaction data from Copilot Free, Pro and Pro+ for training since 24 April 2026, unless the user opts out. Copilot Business and Enterprise are not affected.
So agree that everyone works with a business account, preferably under the client's organisation. That also lets you enforce settings centrally. In Claude Code you do that with managed settings, which developers cannot override in their own files.
Put the rules in the repository
Claude Code reads the CLAUDE.md file in the repository at the start of every session. That is where you write down conventions, the build and test commands and the folders the tool should stay out of. Many other tools read AGENTS.md, and Claude Code can read that file too.
CLAUDE.md gives the tool context but does not enforce anything. Anything that must never happen goes into .claude/settings.json as a permission rule. A deny rule such as Read(./.env) keeps the tool away from your env file. Commit the settings file so the rule applies to the whole team.
Keep secrets out of reach
An AI coding tool reads files and sends their content to the model, so anything in the working directory can end up in a prompt. Keep production keys out of the repository and off local machines. Developers use their own development keys, with as few permissions as possible.
Also agree that nobody pastes a key into a chat with the tool to test something quickly. If it happens anyway, rotate the key right away. Our developers work on managed, encrypted laptops with centrally managed accounts. That covers the device, but the keys themselves need their own management, described in the post on managing secrets and API keys.
Review stays human work
Whoever opens the pull request owns the code. Whether it was typed by hand or generated makes no difference to the review. "Claude wrote that" is not an answer to a review comment. That is why I already ask candidates during screening how they check generated code.
AI tools make it easy to change a lot at once, so agree on a maximum pull request size and ask for a plan before larger changes. In review, look out for tests that test nothing and for changes outside the scope of the ticket. Also check that every function and option the code calls actually exists. Erik wrote more about code review in a remote team.
Licences and other people's code
Licences come up in two ways here. The first is the licence for the tool itself, which you settled with the accounts. The second is the licence of the code the tool suggests, because a model can return code that closely resembles existing open source.
GitHub Copilot has a setting for this. You either block suggestions that match public code, or allow them and get a reference to the source, including its licence. An organisation can set this centrally. With other tools that check is the reviewer's job. My advice is to search for any large block of code that looks suspiciously complete and generic before you merge it, and to run a licence check on your dependencies in CI.
What you keep track of
Decide whether AI help is visible in commits. By default Claude Code adds an attribution line to commits and pull requests, and the attribution setting lets you change or remove it. Pick one approach for the whole team, otherwise the git history tells you nothing.
Track usage and cost as well. Claude Code can export metrics through OpenTelemetry, such as sessions, tokens, cost, commits and pull requests. Prompt text is not included by default. I think that is a sensible default: you see what it costs and how it is used without reading along with every question a developer asks.
When a production bug comes from code a tool wrote, note it in the post-mortem and sharpen the rules in CLAUDE.md, so the tool does not make the same mistake again.
Sources
Frequently asked questions
Can a developer use Claude Code on a client's codebase?
Yes, if the client agrees and the team uses business accounts. Record in the repository what the tool may not read, and send all code through the same review.
How do you stop an AI coding tool from reading secrets?
Keep production keys out of the repository and off local machines. In Claude Code, deny rules in .claude/settings.json stop the tool from reading files such as .env.
Do Anthropic or GitHub train models on my code?
Anthropic does not train on inputs and outputs of its commercial products by default. GitHub has used interaction data from Copilot Free, Pro and Pro+ for training since 24 April 2026 unless users opt out. Business and Enterprise are excluded.
About the author
Milos
Tech lead and general manager, Novi Sad
Milos runs our office in Novi Sad, both technically and as general manager. He is a software and AI engineer with ten years of experience.
More from Milos
