Who Should Have Repository Access and How to Audit It Safely
This guide is for customers who need to confirm that the right people can access their code repository and nobody else can. You will finish with a reviewed member list, correct permission levels, and a simple record of who still needs access.
TL;DR — Your code repository should usually be accessible only to: your internal owner, the software agency staff actively working on the project, and any automation accounts used for deployment or testing. The most common fix is removing old employees, former contractors, and duplicate personal accounts from the repository or organization member list, then confirming the remaining users have the right permission level. Reading time: ~5 min
Goal
When you are done, you will have a checked list of everyone who can access your code repository, the access level each person has, and any unneeded access removed or flagged for removal.
Prerequisites
- Your repository hosting login (for example, GitHub, GitLab, or Bitbucket)
- Admin or owner access to the repository, project, workspace, or organization (the top-level account that contains repositories)
- The repository name you want to review
- A current list of people who should still be involved: your internal owner, your agency contact, and any current developers or contractors
- 10-15 minutes with no planned deployment changes during the review
- Optional, if you prefer command line: GitHub CLI
gh >= 2.0— check with:
gh --version
- Optional, if you prefer command line: GitLab CLI
glab >= 1.0— check with:
glab --version
Steps
Step 1: Decide who should have access before you open the member list
Write down these exact categories in a note or ticket:
1. Internal owner/admin
2. Current agency team members actively working on the project
3. Deployment or CI/CD service accounts (automation accounts)
4. Read-only auditors, if required
5. Nobody else
What you should see when this succeeds: you have a short approved list of names or roles to compare against the repository access list.
Step 2: Open the repository access screen in your provider dashboard
Use the dashboard path that matches your provider:
- GitHub repository level:
Repository → Settings → Collaborators and teams - GitHub organization level:
Organization → PeopleandOrganization → Teams - GitLab project level:
Project → Manage → Members - GitLab group level:
Group → Manage → Members - Bitbucket repository level:
Repository settings → User and group access - Bitbucket workspace level:
Workspace settings → User directoriesorWorkspace settings → User groups
What you should see when this succeeds: a list of users, teams, groups, or service accounts with access levels such as Admin, Maintainer, Write, Developer, Read, or similar.
Step 3: Compare every person on the list to your approved list
For each entry, classify it using this table:
| If the account belongs to | Keep? | Permission to aim for |
|---|---|---|
| Your internal technical owner | Yes | Admin/Owner only if they manage access |
| Current agency lead or active developer | Yes | Write/Developer/Maintainer as needed |
| CI/CD bot or deploy key (automation credential) | Yes | Minimum required, usually read-only unless it deploys tags/releases |
| Former employee or former contractor | No | Remove |
| Personal account you cannot identify | No | Remove or investigate immediately |
| Auditor or compliance reviewer | Maybe | Read-only |
What you should see when this succeeds: every listed account is marked as Keep, Remove, or Investigate.
Step 4: Remove access that is no longer needed
⚠️ Removing the wrong account can interrupt deployments or block your agency from shipping urgent fixes. If an account name looks like automation, bot, deploy, CI, runner, or integration, do not remove it until you confirm what it does.
Use the dashboard action next to each unneeded user:
- GitHub:
Repository/Organization member row → RemoveorRole dropdown → Remove access - GitLab:
Member row → Remove member - Bitbucket:
User row → Remove access
If your provider asks for confirmation, enter the exact username shown on screen and confirm.
What you should see when this succeeds: the removed user no longer appears in the member list.
Step 5: Reduce permission levels for people who need access but have too much
Use the role dropdown next to each remaining user and set the lowest role that still lets them do their job:
- Owners/Admins: only for people who manage billing, security, or access
- Maintainer/Write/Developer: for people who change code
- Read/Reporter: for people who only review code
Typical dashboard paths:
- GitHub:
Repository → Settings → Collaborators and teams → Role - GitLab:
Project/Group → Manage → Members → Role - Bitbucket:
Repository settings → User and group access → Permission
What you should see when this succeeds: each remaining account shows the intended lower role instead of broad admin access.
Step 6: Check teams, groups, and inherited access
Many people appear to have access "indirectly" through a team or parent group (a collection of users managed together). Open these screens too:
- GitHub:
Organization → Teams - GitLab:
Group → Manage → Membersand check inherited members - Bitbucket:
Workspace settings → User groups
Open each team or group that has repository access and review its members using the same Keep/Remove/Investigate list.
What you should see when this succeeds: you can explain every indirect access path, not just direct repository collaborators.
Step 7: Check deploy keys, app integrations, and service accounts
Repository access is not only human users. Also review machine access:
- GitHub:
Repository → Settings → Deploy keysandSettings → Installed GitHub Apps - GitLab:
Project → Settings → Repository → Deploy keysandSettings → Access TokensorGroup/Project access tokens - Bitbucket:
Repository settings → Access keysand connected apps/integrations in workspace or repository settings
Keep only keys and integrations you recognize. If a key is labeled for an old server, old CI system, or unknown laptop, remove it.
What you should see when this succeeds: only current servers, CI/CD tools, and approved integrations still have machine access.
Step 8: Save a simple audit record
Create a note in your ticket system, password manager note, or project document with this exact format:
Repository: <repo name>
Date reviewed: <YYYY-MM-DD>
Reviewed by: <your name>
Kept admins: <names>
Kept write access: <names>
Kept read-only access: <names>
Kept automation accounts: <names>
Removed: <names>
Investigate later: <names>
Next review date: <YYYY-MM-DD>
What you should see when this succeeds: you have a dated record you can hand to your agency or internal team without repeating the audit from memory.
Verify it works
Run these checks in the dashboard:
- Open the repository member list again.
- Confirm every visible user, team, group, key, and app matches your audit note.
- Confirm there are no unknown accounts.
- Confirm only one or two people have Admin/Owner, not every developer.
- If your provider has an audit log, open it and confirm the removals or role changes were recorded.
Typical audit log paths:
- GitHub:
Organization/Enterprise settings → Audit log - GitLab:
Group/Project → Audit eventsorAdmin area → Audit events - Bitbucket: check workspace or repository audit/activity logs if available in your plan
What proves the result end-to-end: the current access list contains only approved people and approved automation accounts, and your audit log or saved note shows what changed.
Common pitfalls
Removing a bot or deploy key because the name looks unfamiliar
Mistake: deleting an automation account without checking what it does.
Symptom: deployments, builds, or release tagging suddenly fail after the cleanup.
Fix: open Deploy keys, Access tokens, and app/integration screens first; remove only items tied to old systems or unknown owners.
Checking only the repository member list and missing team access
Mistake: reviewing direct collaborators but not teams, groups, or inherited access.
Symptom: a removed person still has access through a team or parent group.
Fix: open the provider's Teams, Groups, or User groups screen and review those members too.
Leaving too many admins because it feels safer
Mistake: keeping every active developer as Admin/Owner.
Symptom: more people can change access, delete settings, or bypass normal controls than necessary.
Fix: change most active developers to Write, Developer, or Maintainer; reserve Admin/Owner for access managers.
Forgetting former contractors and personal accounts
Mistake: only checking company email addresses and overlooking personal Gmail or old freelance accounts. Symptom: people outside your current team still appear in the member list. Fix: compare every username to your approved list, not just the display name or email domain.
Auditing human users but not machine access
Mistake: removing old staff but leaving old deploy keys, access tokens, or app integrations in place.
Symptom: an old server or external tool can still pull code after the user cleanup.
Fix: review Deploy keys, Access tokens, and installed apps right after the member audit.
This article was written by an AI system and published pending human review. Verify anything you intend to act on.
Have a project in mind?
Get an instant AI price estimate for it, or talk directly to our team.
One email a month on what we learn building with AI