Services → GitHub

Connect GitHub

Read code, history and diffs from selected repositories. One connection per repository, each with a token that can reach only that repository.

Tier 1 Fine-grained personal access token ~5 min profile github/code-read

Setting this up with your own agent? Give it these instructions.

Why one token per repository

The hosted GitHub MCP endpoint is a single URL. Which repository a call reaches is

decided by the owner and repo arguments, not by the address you connect to. So

naming a Prodpeek connection gh-api does not stop it reading gh-billing — only

the token does.

That is why the shape here is one connection per repository, each with its own

fine-grained token scoped to exactly that repository. A project spanning four repos

is four connections in the same Prodpeek project. It is slightly more setup, and it

is the difference between "we asked it not to" and "it cannot".

Go to **Settings → Developer settings → Personal access tokens → Fine-grained tokens and choose Generate new token**. (Direct link: https://github.com/settings/personal-access-tokens/new.)

Name it for the connection you are about to create — prodpeek-<repo> — so that revoking the right one later is obvious.

Set an expiry. Ninety days is a reasonable default; a token wired into a gateway is exactly the kind that gets forgotten.

Under Repository access, choose Only select repositories and pick the one repository this connection is for. Not "All repositories".

Under Repository permissions, set: - Contents → Read-only - Pull requests → Read-only (skip if you only need files and history) - Metadata → Read-only (GitHub adds this automatically)

Leave everything else at No access. In particular leave Secret scanning

alerts, Code scanning alerts and Actions alone — the profile denies those tools,

and a token that cannot reach them means the denial holds even if the profile is

ever misconfigured.

In Prodpeek: Services → Add a service, choose GitHub — code read, name it after the repository, leave the URL at the suggested endpoint, and paste the token. Then Test connection — it lists what the endpoint advertises and how the profile classifies each tool.

Repeat the whole thing per repository, including a new token each time. The "Add

another endpoint" button on a service card copies a connection's credential to a new

URL, which is right for a vendor that splits one account across endpoints

(DigitalOcean) — but wrong here: sharing a token across repositories is precisely

the scoping you just set up being undone.

Repository access → Only select repositories → pick ONEThis is the whole scoping mechanism. The GitHub MCP endpoint is one URL for every repo — which repo a call touches is an argument, not part of the address — so the token is the only thing that makes a connection repo-specific.
Repository permissions → Contents → Read-onlyFile contents, commit history, diffs, branches and tags.
Repository permissions → Pull requests → Read-onlyPR diffs and metadata. Omit it if you only want files and history.
Repository permissions → Metadata → Read-onlyRequired by GitHub whenever any other repository permission is set.

The permissions that look harmless and quietly demote the profile from “the credential cannot” to “we asked it not to”.

Any permission set to Read and writeOne write permission ends the Tier 1 claim. The point of this token is that it cannot change anything even if something goes wrong upstream of it.
Secret scanning alertsThose alerts contain the detected secrets themselves. The profile denies the tools; do not hand the token the ability either.
Code scanning alertsA precise map of unfixed vulnerabilities in your own code.
Actions (workflow logs)CI logs are masked in the web UI and often not in the raw download — the classic place a secret escapes.
A classic PAT instead of a fine-grained oneClassic tokens scope to whole accounts, not repositories. repo grants write to every repository you can reach. Fine-grained is not a preference here.