Claude Code agency onboarding checklist: what access to give, and what to hold back

When you onboard a Claude Code agency or developer, give them enough access to work on a copy of your site and nothing that can change your live business without your approval. In practice that means write access to branches in a repository you own, full access to a staging copy, read-only or limited roles in analytics and search tools, and no access at all to your domain registrar, billing or payment systems. Production access, if it is needed, comes later, through your normal deploy process, with a named person approving.

Claude Code acts with whatever access the person running it has. It can edit files, run commands and, through MCP connections, use outside tools. So every permission you give a vendor is also a permission their Claude Code sessions can use. Least privilege (giving each account only what its job needs) matters more, not less, when an agent is doing the work.

This checklist covers what to prepare before kickoff, system-by-system access with suggested roles, how to share passwords and keys safely, the Claude Code settings to have in place, and how to plan the end of access from day one.

Before kickoff: what to prepare

1. Name your people. A project owner who approves gates, a technical contact, and a fact owner for content, prices and claims.
2. List systems in and out of scope. Be explicit about what the vendor and Claude Code must never touch, such as payment systems or customer databases.
3. Set up a staging copy if you don't have one. Our guide to setting up a staging copy explains how.
4. Put the site in git in your own organization's account, if it isn't already.
5. Collect working materials: brand rules, approved facts and prices, current redirects, known issues.
6. Agree the access plan in writing, ideally in the scope of work. Our scope-of-work template includes an access table you can reuse.

Access by system

Suggested starting roles are below. Your vendor may need more for specific tasks; ask them to explain why, and grant it for the task rather than by default.

Repository roles and branch protection

GitHub's repository roles run from Read through Triage, Write and Maintain to Admin. Write is recommended "for contributors who actively push to your project." Admin is for "people who need full access to the project, including sensitive and destructive actions like managing security or deleting a repository." A vendor doing ordinary code work shouldn't need Admin.

Then protect the main branch. GitHub's protected branches can require approving reviews and passing status checks before merging, and by default each rule blocks force pushes and branch deletion. Two details matter: the rules don't apply to people with admin permissions by default unless you configure that, and protected branches on private repositories need a paid GitHub plan. With required reviews on, changes reach the main branch only through an approved pull request, which is exactly the review step you want for AI-written code.

CMS roles

On WordPress, the roles documentation describes an Administrator as "somebody who has access to all the administration features within a single site" and an Editor as "somebody who can publish and manage posts including the posts of other users." For content work on a live site, an Editor account may be enough; theme and plugin work belongs on staging. For other platforms, check the platform's own documentation for staff or collaborator roles and grant the narrowest one that fits the task.

Analytics and Search Console

In Google Analytics 4, roles run from Viewer ("Can see settings and data") through Analyst, Marketer and Editor ("Full control of settings at the property level. Can't manage users") to Administrator. In Search Console, permissions are Owner, Full user ("view rights to all data and can take some actions") and Restricted user ("simple view rights on most data"). Keep ownership and user management with your own staff.

Sharing passwords and keys safely

• Share credentials through a password manager or vault with per-person access, never by email, chat or shared document.
• Prefer separate, scoped keys for the vendor over sharing your own logins, so you can revoke theirs alone.
• Keep keys in environment variables or a secrets store, not in code, prompts or CLAUDE.md.
• Use staging keys for staging, so a mistake can't reach live customers.
• List every credential you shared, so you know what to rotate at the end.

Our guide to keeping secrets away from Claude Code goes deeper, and our website security checklist covers the wider basics.

Claude Code settings to have in place

Before the vendor's first session on your repository, agree on and commit the shared settings, so their sessions follow your rules from the start.

• A project CLAUDE.md with build and test commands, conventions and a "never change" list. It is shared through git, so every session on the project loads it.
• .claude/settings.json, committed, with deny rules. Anthropic's permissions documentation gives Read(./.env) as an example that matches reading the .env file, and notes that a .claudeignore file has no effect, so its entries belong in deny rules.
• A written rule on permission modes: no one runs Claude Code with permission checks bypassed on your real systems.
• Managed settings, if your organization deploys them. Anthropic's settings documentation says nothing in a user's own settings files overrides a managed key. Our guide to managed settings and admin controls explains the options.

Our guide on how to choose a Claude Code development partner includes questions to ask about these settings before you sign.

First-week checks

Plan the end of access on day one

Write down now how access will close: which accounts are removed, which are transferred, which credentials are rotated, and who confirms it. Ask for any personal Claude Code notes that matter to move into the shared project files before the end, because personal files and auto memory stay on the vendor's machine. Our guide to Claude Code handover documentation lists what you should receive.

Conclusion

Onboard a Claude Code vendor the way you'd want an agent to work: in your accounts, on a copy, with narrow roles, protected branches, deny rules and no secrets in reach. Grant more only for a reviewed reason, and plan the end of access before work begins. If you want help setting this up for a team, see our Claude Code consulting service, and hold us to the same checklist. More guides are in our Claude Code Guide.

Frequently asked questions