GitHub Permissions
The GitHub tool (see Tools & Integrations) connects either with OAuth ("Connect with GitHub") or with a personal access token (PAT) you create. Every GitHub tool is read-only except one: github_create_issue, which lets the AI file an issue as a follow-up action after HITL approval.
Note the difference between what CloudPeek does and what a token could do: the read-only behaviour above is a property of CloudPeek's implemented tools, while the OAuth flow and classic PATs use the coarse repo scope, which grants broader read/write capability at the token level. If you want the permission boundary itself to be least-privilege, use a fine-grained PAT, and omit Issues (write) if you do not want issue creation; the rest of the tool works unaffected.
Fine-grained PAT (recommended)
A fine-grained PAT lets you grant exactly what CloudPeek uses, and only on the repositories you select:
| Permission | Description | Use case |
|---|---|---|
| Metadata (read) | Mandatory baseline for any repository access | Resolve repositories and their metadata (github_get_repo, github_list_repos) |
| Contents (read) | Read repository files and directory listings | Inspect files and directory structure during investigations, for example reviewing a workflow file or dependency manifest flagged in an alert (github_get_file_contents, github_list_directory) |
| Pull requests (read) | Read pull requests | Review pull requests referenced in an investigation, such as a suspicious change merged around the time of an incident (github_list_pull_requests, github_get_pull_request) |
| Issues (read) | Read issues | List existing issues for context on known problems (github_list_issues) |
| Issues (write) | Create issues | Optional: file an issue as an approved follow-up action, for example tracking a remediation task from an incident (github_create_issue) |
Classic PAT or OAuth
- A classic PAT needs the
reposcope (orpublic_repofor public repositories only). Classic scopes are coarse:repoincludes write access, so prefer a fine-grained PAT where you can. - The OAuth flow requests the
repoandread:orgscopes;read:orglets CloudPeek list repositories across your organisation. Becauserepogrants read/write at the token level, the read-only guarantee under OAuth rests on CloudPeek's implemented tools, not the token; what CloudPeek can reach is also bounded by the connecting user's own access.
Whichever method you use, CloudPeek can only see repositories the token or user can see. A dedicated machine user with access to just the repositories you want investigable is a good way to bound the blast radius.