Claude Code for Teams: Rules, Review and Security

Alone, an agent is a tool. In a team it is also a set of agreements: who answers for what it did, and what it is allowed near in the first place.

What must not be delegated

The list is short, and it is not about code quality.

Production. No access to the live database, no infrastructure keys, no ability to deploy. The agent does not distinguish reversible actions from irreversible ones.

Secrets. Keys, tokens, dumps with personal data. Anything that entered context has gone to the model provider. That is not a hypothetical risk, it is a description of how the tool works.

Decisions nobody will review. If a change has no reviewer, it should not be an agent change. That rule is about accountability, not distrust of the model.

Client data under NDA, where the contract forbids passing it to third parties. The model provider is a third party, and so is any reseller in the access chain - see access and payment.

Sandboxing and permissions

Three levels, weakest to strongest:

Permissions in config. A list of what needs no confirmation: tests, build, reads. Everything else asks. Enough for ordinary work on your own machine.

Directory and network restrictions. The agent sees only the project and cannot send data outward at will. A sensible level for a project with sensitive data.

An isolated environment. A container or a separate machine where full access is safe because there is nothing there to lose. This is the only mode where allowing everything is reasonable. What that looks like in practice: sandbox your coding agent.

A team rule: running in allow-everything mode outside a sandbox should not be an individual developer’s decision. It is a team agreement, because the consequences reach past their machine.

Reviewing agent code

It differs from ordinary review in two ways.

The author did not read the code the way they read their own. Reviewers normally lean on the assumption that the author thought about every line. That support is missing here, and part of the work shifts to review.

The errors are of a different kind. Agents rarely make syntax errors and often make plausible ones: handled the wrong case, duplicated an existing function under a new name, fixed the symptom instead of the cause. Those survive a quick skim.

What helps:

• A reasonable change size. A thousand-line diff is not reviewed, it is scrolled.
• Tests written in a different pass from the code. Otherwise they encode the same wrong assumption.
• Demanding a verifiable result. Not “done” but the test output. The same principle as with subagents.
• An explicit label on the pull request saying the change is agent-written. It changes how carefully people read.

Shared skills and configs

What belongs in the repository:

• The project description. Stack, commands, conventions, prohibitions. One file for everyone, maintained like code.
• Skills for procedures: releases, migrations, adding an entity. This is how you make the agent behave the same way for the whole team.
• Project permission settings, so a newcomer does not start in the most dangerous mode by default.
• MCP server configuration, where it is shared.

What does not belong: keys and personal preferences. The first is a security matter, the second is taste and has no business in a shared repository.

A practical note: config in the repository means that cloning somebody else’s project also brings their agent settings. Review them the way you would review their build scripts.

How to start the rollout

An order that works:

1. One person tries it on non-production work and writes down what happened.
2. A project description and a baseline permission set land in the repository.
3. The team agrees on review rules and labelling.
4. Only then does the tool go out to everyone.

The reverse order - hand it to everyone and figure it out as you go - usually ends with a few poorly reviewed changes in the shared repository and trust in the tool collapsing before it has shown its value.

If you want that rollout done quickly and with a defined outcome, it is part of what I do on projects: setting up the process, not just the tool. Details on the services page.