How to give a developer or coding agent access without sharing your passwords

The hierarchy

There are four ways to let someone work on an account behind your site. Use the first one that works, and go down the list only when the one above it genuinely isn’t available.

1. Invite them, with their own login and the smallest role that does the job. Every service that matters has this. They sign in as themselves, the service records what they did, you can limit what they can touch, and removing them is one click.
2. Give them a scoped token. For tools and automated workflows that can’t sign in interactively, most services issue a token limited to specific resources and actions, with an expiry. It’s a credential, but a narrow, revocable one.
3. Do the task yourself, with their instructions. For a one-off change, such as adding two DNS records, ask for the exact values and enter them. Five minutes, and nobody gets access.
4. Share a credential. Only when the service has no way to add a person or issue a token, and only through a password manager’s sharing feature, never by message. Change it when the work ends.

The same list applies whether the “someone” is a freelancer, an agency, a colleague, or an AI coding tool you run yourself. A coding agent that needs to push to your repository should be connected as an app with permission on that repository, not handed your GitHub password, for exactly the same reasons.

Before granting anything

• Make sure the account is yours first. Inviting someone to an account you don’t own doesn’t help. The diagnostic finds each account and whose it is.
• Turn on 2FA on your own login before adding anyone. If your account is the weakest link, roles don’t matter.
• Write down what you’re about to grant: the service, the person or tool, the role, the date, and when it should end. This list is what you’ll revoke from later.
• Ask what they actually need. “Access to the site” is not an answer. “Write access to the repository and the ability to add DNS records” is. If they can’t say, grant the least and add more when asked.

Domain and DNS

A developer setting up a site usually needs to add or change DNS records. They do not need the registrar login, and they never need to be the registrant.

• Registrar with delegation. GoDaddy’s delegate access lets you invite a person by email with domain-only rights; a delegate can’t see your password or payment methods. Namecheap’s share access does similar per domain. Look for “users”, “delegates”, “members” or “sharing” in the account settings.
• DNS at Cloudflare. Add them as an account member with a DNS-scoped role rather than Administrator. Cloudflare also issues API tokens limited to one zone and to DNS editing, which is what to give a tool.
• No delegation available. Ask for the records as a list of type, name and value, and add them yourself. The DNS guide covers doing that without breaking anything.

Never let a developer change the registrar account’s email to theirs, and never share the registrar password. Both hand over the domain.

GitHub

• Repository under your personal account: invite them as a collaborator. They can read and push; only you can delete, transfer or change who else has access. There is no read-only option on a personal repository.
• Repository in your organization: add them as an outside collaborator on that repository, or as a member if they’ll work across several. Give the Write role for someone who’ll push code, Read for someone who only needs to look, and Admin to nobody who isn’t you. Admin is what allows transferring or deleting the repository.
• For a tool or script that needs to act on the repository without a person present, GitHub’s fine-grained personal access tokens can be limited to one repository, to specific permissions, and given an expiry date. Prefer an installed GitHub App where the tool offers one.

If the repository isn’t yours to grant access to, the GitHub guide covers getting it under your account first.

Hosting

• Vercel: a team lets you invite members by email with a role; Member and Developer roles can work on projects without touching billing or team settings. The free Hobby plan is for individuals and doesn’t include team collaboration, which is a reason to use a paid team for a business site.
• Netlify: team members with roles, including a Developer role for people who deploy and configure, and a Git Contributor role for people who only push code and shouldn’t see the dashboard.
• Cloudflare: account members with roles; a Super Administrator invites, everyone else gets a narrower role.
• Tokens: each host issues API or deploy tokens for automation. Vercel’s can be scoped to a single project and given an expiry; Netlify’s have an expiry date and are invalidated if you reset your password. The value is shown once. Store it as a secret, not in the code.

Environment variables are readable by anyone with access to a host project unless they’re marked sensitive or secret. Mark them before you invite people, and read the secrets guide for what that means.

Databases and services

• Databases (Supabase, Neon, Firebase and similar): organizations with members and roles. Give a developer the developer-level role, keep Owner for yourself. Database passwords and service keys are credentials; a developer who needs to run queries should use their own database user or the provider’s dashboard, not the production connection string.
• Payments (Stripe and similar): team members with roles that separate viewing, developing and administering, and restricted API keys that grant only specific capabilities. Never share the live secret key; issue a restricted key for what the integration actually does.
• Email, analytics, CMS, forms: almost all have team features. Where one doesn’t, prefer issuing a second API key in your account for the developer’s use, so it can be deleted independently.

For every service, the account owner stays you. The data guide walks through finding them all.

AI coding tools

A coding agent needs, at most, the same things a developer does: the code, and a way to commit changes to it. It rarely needs anything else, and it never needs your passwords.

• Tools that run on your computer, such as Claude Code, Cursor or Codex used locally, work on a copy of the repository that you’ve already signed in to fetch. They act as you. Their access to GitHub is your access, which is fine for a site you own and something to notice if you’re running them against someone else’s.
• Tools that connect as an app, such as AI builders that sync to GitHub or agents that open pull requests from the cloud, ask you to install or authorize a GitHub App. The app’s permissions are fixed by its maker and you accept them as a set; what you choose is which repositories it may see, so choose only the ones it needs rather than “all repositories”. Claude Code’s app, Cursor’s and Codex’s all work this way. GitHub lists every app you’ve authorized, with a revoke button, under your settings.
• Tools that need to deploy or read secrets should get a scoped token from the host or service, as above, not the dashboard login. A coding agent doesn’t need your production database password to write code; it needs the variable names.

One habit worth forming: don’t paste secrets into a chat with an agent. Put them on the host as environment variables and refer to them by name. The agent can write the code that reads them without ever seeing the values.

When you really must share a credential

Some small services have one login and no way to add a person or issue a token. If the work can’t be done by you with their instructions, then:

1. Share it through a password manager’s sharing feature, which can be withdrawn, rather than by message, email or document, which can’t.
2. Note it on your access list with the date.
3. Change the password when the work ends, and turn on 2FA if it wasn’t already, which will also invalidate any sessions they kept.

When the work ends

Go down your access list and, for each entry:

• Remove the person from the repository, organization, team, or account.
• Delete any token you issued for them, and any GitHub App or OAuth authorization that belonged to their tool.
• Change any credential you shared outright.
• Rotate any secret they could have seen that isn’t already covered: a database password, an API key they created in your account, a sign-in secret.
• Check the account’s member list one more time for anyone you don’t recognise.

Checklist

Sources

The rules and product behaviour described above were checked against these pages when the guide was last updated. If something here has changed, these are the places to look.

• Invite a delegate to access my GoDaddy account · GoDaddy
• How do I share access to my domain with other users? · Namecheap
• Manage account members · Cloudflare
• Create an API token · Cloudflare
• Adding outside collaborators to repositories in your organization · GitHub
• Repository roles for an organization · GitHub
• Managing your personal access tokens · GitHub
• Reviewing and revoking authorization of GitHub Apps · GitHub
• Removing an outside collaborator from an organization repository · GitHub
• Claude Code GitHub Actions · Anthropic
• GitHub integration · Cursor
• Access tokens · Vercel
• Hobby plan · Vercel
• Get started with the API: personal access tokens · Netlify
• Account member roles · Cloudflare
• Access roles · Vercel
• Roles and permissions · Netlify
• Access control · Supabase
• API keys: restricted keys · Stripe