Check who has access to your GitHub repository by going to Settings, then clicking Collaborators (or Manage access). This page shows every person with access, their permission level (Read, Write, or Admin), and any pending invitations. For organizations, you can also see team-level access. Audit this list regularly, especially for repositories connected to AI tools like Lovable or V0.
Why You Should Know Who Has Access
Every person (and bot) with access to your GitHub repository can potentially view your code, commit history, and any files stored in the repo. For projects connected to AI tools like Lovable or V0 — which may contain Supabase configurations, API endpoint URLs, and application logic — knowing who has access is a basic security practice.
GitHub has three permission levels for individual collaborators:
- Read: can view code, issues, and pull requests. Cannot push code or change settings. Best for stakeholders, investors, or advisors who need visibility. - Write: can push code, create branches, manage issues, and create pull requests. This is the standard level for developers and contractors. - Admin: full control including managing collaborators, changing settings, deleting the repo, and managing integrations. Reserve this for co-owners only.
If your repository belongs to a GitHub organization (which Lovable requires for its GitHub connection), you may also see team-level access. Teams are groups of people within an organization that share the same permission level.
Beyond human collaborators, you may see bot accounts. The lovable-dev bot appears when Lovable is connected, and GitHub Apps (like Vercel or Netlify) may also have access. These are normal and expected for connected services.
Auditing your access list is especially important when you remove team members, finish contractor engagements, or prepare for a production launch.
Prerequisites
- A GitHub repository you own or have Admin access to
- A web browser with github.com open
Step-by-step guide
Open the repository settings
Open the repository settings
Navigate to your repository on github.com. Click the Settings tab in the top navigation bar — it is the rightmost tab with a gear icon. If you do not see Settings, you do not have Admin access. Ask the repository owner to grant you Admin permissions or to check the access list for you.
Expected result: The repository Settings page opens showing General settings.
View the collaborators list
View the collaborators list
In the left sidebar, click Collaborators (for personal repositories) or Manage access (for organization repositories). GitHub may ask you to re-enter your password for security verification. The page displays all collaborators with their GitHub username, avatar, and permission level. Pending invitations appear in a separate section with an expiration date.
Expected result: You see a complete list of all collaborators, their permission levels, and any pending invitations.
Review permission levels for each person
Review permission levels for each person
Go through the list and check each person's permission level. Next to each collaborator's name, you will see their role: Read, Write, or Admin. Ask yourself: does this person still need this level of access? A common issue is finding old contractors with Write or Admin access months after their work ended. Make a note of anyone whose access should be changed or removed.
Expected result: You have reviewed each collaborator's permission level and identified any that need to be changed.
Check for bot and app access
Check for bot and app access
Scroll down on the Collaborators page or look for a section labeled 'GitHub Apps' or 'Integrations.' You may see bot accounts like lovable-dev (from Lovable's GitHub connection), Vercel's deployment bot, or Netlify's bot. These are normal — they were added when you connected those services. However, if you see an app you do not recognize, investigate it by clicking the app name to see what permissions it has. You can revoke access for any unknown apps by clicking Remove or Configure.
Expected result: You can identify all bot and app accounts with access and verify they are from services you connected.
Set up a recurring access audit
Set up a recurring access audit
Create a recurring reminder (monthly or quarterly) to review this page. On the audit date, open Settings, then Collaborators, and verify that every person and bot with access still needs it. Remove anyone who no longer works on the project. Downgrade permissions for people who only need Read access. This is especially important for repositories connected to AI tools that auto-deploy, since any collaborator with Write access can indirectly trigger production deployments.
Expected result: You have a plan to review repository access on a regular schedule.
Complete working example
1# Repository Access Audit23Date: ____________________4Repository: ______________5Audited by: ______________67## Current Collaborators8| Username | Permission | Still needed? | Action |9|----------|------------|---------------|--------|10| | Read/Write/Admin | Yes/No | Keep/Remove/Downgrade |11| | | | |12| | | | |1314## Pending Invitations15| Email/Username | Invited on | Still needed? |16|----------------|------------|---------------|17| | | |1819## Connected Apps/Bots20| App Name | Purpose | Still needed? |21|----------|---------|---------------|22| lovable-dev | Lovable sync | Yes |23| Vercel | Auto-deploy | Yes |24| | | |2526## Actions Taken27- [ ] Removed inactive collaborators28- [ ] Downgraded over-permissioned users29- [ ] Cancelled expired invitations30- [ ] Rotated credentials if anyone was removed31- [ ] Updated CODEOWNERS fileCommon mistakes when checkking Who Has Access to a GitHub Repository
Why it's a problem: Not checking the access list before a production launch
How to avoid: Always audit collaborators before going live. Remove test accounts, expired invitations, and contractors who finished their work.
Why it's a problem: Forgetting to check bot and app access
How to avoid: Scroll past the human collaborators to see GitHub Apps and integrations. Remove any apps you do not recognize or no longer use.
Why it's a problem: Assuming only Admin users can cause damage
How to avoid: Write-access collaborators can push code to main, which can trigger Lovable sync and Vercel deployments. Treat Write access as a significant permission.
Why it's a problem: Not having a regular audit schedule
How to avoid: Set a monthly or quarterly reminder to review the collaborator list. Access creep — gradually accumulating unnecessary permissions — is one of the most common security issues.
Best practices
- Audit your repository access list at least once per quarter.
- Remove collaborators as soon as they no longer need access — do not wait.
- Use the principle of least privilege: give the minimum permission level each person needs.
- Check bot and app access alongside human collaborators during audits.
- Keep a written record of each audit using a template like the one above.
- For repos connected to AI tools, remember that Write access can trigger auto-deploys.
- Cancel pending invitations that are older than 7 days — they expire anyway but clutter the list.
- If your project handles payments or user data, audit access monthly instead of quarterly.
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
I have a GitHub repository connected to Lovable and Vercel with 6 collaborators. I am preparing for a production launch. Walk me through a complete access audit — what to check, who to remove, and what credentials to rotate before going live.
Frequently asked questions
Can I see access for repositories in a GitHub organization?
Yes. For organization repos, go to Settings and then Manage access. You will see both individual collaborators and team-level access. Organization owners can also view access across all repos from the organization's People tab.
What is the lovable-dev bot that appears in my collaborator list?
The lovable-dev bot is the GitHub App installed when you connected Lovable to your repository. It is the account that pushes commits on behalf of Lovable. This is expected and should not be removed unless you want to disconnect Lovable.
Can I see who accessed the repository, not just who has access?
GitHub does not provide an access log for free plans. On GitHub Enterprise, you can see audit logs of who cloned, viewed, or interacted with a repository. For free/pro plans, you can only see who has access and what they committed.
How do I check access if I am not the repository owner?
You need Admin access to see the full collaborator list. If you have Write access, you can see some information but not the full Settings page. Ask the repository owner to check or to grant you Admin access.
Can RapidDev help with a comprehensive access and security audit?
Yes. RapidDev's engineering team can perform a full security audit of your GitHub repositories, including access reviews, credential checks, and security configuration for AI-connected projects.
Does making the repository public change who can access it?
Yes. A public repository can be viewed by anyone on the internet, regardless of the collaborator list. The collaborator list only controls who can push code, manage issues, and change settings. If your repo contains sensitive configurations, keep it private.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation