Before installing a GitHub App, confirm you trust its owner, read the permissions it requests on the installation screen, limit it to the repositories it needs, and learn how to revoke it. Installing and authorizing are separate actions with different effects, so review each one.
Install versus authorize
GitHub's documentation separates the two. Authorizing lets the app verify your identity, see which of its resources you can also reach, and act on your behalf, for example by creating issues or commenting on pull requests. Installing gives the app the organization and repository permissions it requested, such as reading repository metadata or writing issues. You can do either one without the other.
| Action | What the app gains | Who is the actor in logs |
|---|---|---|
| Install | The permissions it requested, on the repositories you choose | The app |
| Authorize | The ability to act as you, within what both of you can access | You, as a user-to-server token |
When an app acts for you, it can only do what both you and the app are allowed to do. If you can reach repositories A and B and the app can reach B and C, it reaches only B on your behalf.
Review steps
- Check the owner. Is it a company or person you recognize, with a public contact and a security page?
- Read the permission list. Compare each permission with the stated function. A code review bot needs to read code and write comments. It does not need to administer the repository.
- Prefer selected repositories. Choose the specific repositories instead of all current and future ones.
- Separate read from write. Write access to contents, workflows or administration deserves a second approver.
- Check what it can reach outside GitHub. Ask where it sends data and whether it stores code.
- Write the decision down with the date, the owner of the integration and the review date.
After installation
Review installed and authorized apps on a schedule. GitHub lets you review and revoke an app's authorization at any time. Audit logs list the user as the actor when the app uses a user-to-server token, so when you investigate you need to remember that the person's name may appear on actions the app took.
Remove apps nobody can explain. An unused integration with write access is standing risk with no benefit.
When to treat the app as a vendor
If the app touches private source code, treat its owner like any supplier: ask where data goes, how long it is kept, and what happens on a breach. The vendor onboarding security checklist works for this, scaled to what the app can do.
Quick check
Does installing a GitHub App give it access to all my repositories?
Only if you choose that. The installation screen lets you pick which repositories the app can access, and it lists the permissions you are granting.
Who shows up in the audit log when an app acts for me?
The log lists you as the actor, with the access type shown as a GitHub App user-to-server token. Keep that in mind during investigations.
Safeguard's policies, gates and asset discovery can help you see which integrations and repositories exist, and a free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
