Constant APP_PERMISSIONS 

pub const APP_PERMISSIONS: [(&str, &str); 9];

The App’s permissions: repository Administration (write), Contents (write, for the bootstrap commit and for pushing re-signed Dependabot commits, §9), Variables (write), Metadata (read); organisation Members (read) and Administration (write). No secrets, Actions logs, code scanning or packages.

Organisation Administration (organization_administration) is for one thing: the org ruleset that runs verify-trust as a required workflow from the bridge-managed <org>/.vgi repository at a pinned commit (§9). A pull_request workflow committed to the repository itself runs from the pull request’s own files, so a writer could edit it to pass; the org ruleset takes what runs out of the pull request’s reach. GitHub files every /orgs/{org}/rulesets endpoint under this permission, at write even for reads. It is always requested — the manifest is fixed per App, and organisations are the recommended topology — and it also lets the App edit other org settings, which is why the bind screen has to say why it is there. On a personal account it grants nothing. An owner who declines it gets the owner-review fallback (missing_permissions lists it).

Checks (checks, write), Pull requests (pull_requests, read) and Merge queues (merge_queues, read) are for one thing too: where there is no org required workflow, the bridge posts the “Verify commit trust” check itself (§9, “forged check runs”), and the repository ruleset requires that check from this App’s own integration id. A workflow on another branch can post a check run under the GitHub Actions App — the reason a check pinned to Actions is forgeable by any writer — but nothing but this App’s key can post one under this App. The two read permissions are what GitHub requires for the pull_request and merge_group events that tell the bridge when to check, and for reading a pull request’s current base. None of them reaches code: checks only posts check runs, and the reads see pull request and queue metadata. Tokens for them are minted per pull request, for that one repository.

Pull requests is requested at write, not read, for one more thing: the pull-request gate (git-ns/bridge/job 0.5 closePullRequest). When the community’s pull-request policy does not allow a pull request’s author, the VTC has the bridge post the community’s message on it and close it. GitHub files a pull request’s conversation comments under Issues or Pull requests (write) and closing one under Pull requests (write) alone, so pull_requests: write is the single least permission that does both — Issues is not requested. It reaches no code either: it cannot push, and merging needs Contents. Tokens for it are minted per job, for the one repository. An installation that approved only read keeps everything else (the bridge-posted check needs only CHECK_PERMISSIONS); its closePullRequest jobs fail forbidden, and the binding’s missing_permissions lists pull_requests:write until the owner approves the upgrade.