Before you install any AI code review tool on your GitHub organisation, you are handing it some level of access to your source code. The difference between "read the diff of pull requests in three repositories" and "act as an admin on everything" is enormous, and it comes down to how the tool integrates. This post explains the three ways a bot can connect to GitHub, what each permission means in practice, and how to evaluate a tool's access request in two minutes.
Three ways a bot can connect
Personal access token
The oldest approach. A developer creates a token on their own account and pastes it into the tool. The bot then acts as that person, with every permission that person has, on every repository they can see.
Avoid this for anything shared. The token is tied to one human, it typically grants far more than needed, it stops working when they leave, and every comment appears to come from them.
OAuth App
The tool asks the user to authorise it, and receives a token scoped to that user. Better than a pasted token, because the scopes are declared and the user can revoke access. But it is still user-scoped: the bot can see whatever the authorising user can see, and its actions are attributed to a person.
OAuth is the right tool for signing in. It is a poor tool for acting on repositories.
GitHub App
A GitHub App is installed on an organisation or account, not on a person. It declares exactly which permissions it needs and which repositories it covers, and it acts under its own identity. Access tokens are short-lived and minted per installation. If the developer who installed it leaves, nothing breaks.
This is the correct model for a review bot, and it is what GitHub itself recommends.
Which permissions a review bot actually needs
A bot that reviews pull requests and posts comments needs surprisingly little:
| Permission | Level | Why |
|---|---|---|
| Pull requests | Read | See PRs open, list changed files, read the diff |
| Contents | Read | Fetch file patches for review context |
| Metadata | Read | Required by GitHub for every App; lists repositories |
| Pull request comments | Write | Post inline findings and the summary comment |
Notice what is not on the list:
- Contents: write. A review bot has no reason to push commits. If it asks for this, it can modify your code.
- Administration. No bot needs to change repository settings, branch protection, or collaborators.
- Members or organisation-level write. Not needed to review code.
- Actions or Secrets. A tool asking for these can read your CI secrets.
- Checks: write is reasonable if the tool posts a status check, but it is optional. DiffNova does not request it; findings arrive as ordinary review comments.
What the bot does with the access
Permissions tell you what a tool can do. You also want to know what it does:
- Does it clone your repository? Some tools pull the whole codebase to build an index. That is a much larger data footprint than reading the diff of a single PR. Ask where that copy lives and for how long.
- What is sent to the model? The diff only, or surrounding files, or the whole repository? Less is better unless you have a specific reason to want more context.
- Is source stored after the review? The findings and scores are useful history. The source itself should not be kept.
- Are webhooks verified? Every GitHub webhook carries an HMAC signature. If the tool does not verify it, anyone who knows the endpoint can forge a "PR opened" event.
- Are duplicate deliveries handled? GitHub retries webhooks. A tool that reviews the same PR twice on a retry is wasting your money and cluttering the PR.
The two-minute evaluation
When the installation screen appears, read the permission list before clicking Install:
- Every write permission needs a reason you can state in one sentence.
- Choose Only select repositories and start with one or two. Widen later.
- Check that sign-in and repository access are separate. A tool that uses OAuth for login and a GitHub App for repositories has the right architecture. One that uses your OAuth token to read repositories is acting as you, not as itself.
After installing, look at the first PR it touches. The comments should come from the App's own bot identity, not from a human account.
How DiffNova connects
DiffNova uses GitHub OAuth only for signing in to the dashboard, with the read-only read:user and user:email scopes. Repository access comes from the DiffNova GitHub App, installed per organisation or account, covering only the repositories you select.
The App reads pull requests, contents, and metadata, and writes pull request comments. It does not request contents write, administration, members, or secrets. It does not clone repositories: only the changed-file patches of the PR under review are fetched and sent to the model, capped at 500 KB per review. Webhooks are verified with HMAC-SHA256 before processing, and GitHub's delivery ID is used to drop duplicate deliveries. Installation tokens are short-lived and refreshed automatically.
Disconnecting an account deactivates its repositories but keeps the review history, so you can pause without losing the scores.
You can inspect all of this on the installation screen before granting anything. Start at diffnova.com, sign in with GitHub, and read the permission list before you click Install.