A remediation bot needs to read your code, push a branch and open a pull request. It should not be able to merge to protected branches, change settings, read secrets or administer the repository. Grant the minimum, scope it to chosen repositories, and review the grant on a schedule.
Start from what the job needs
A fix pull request involves four actions: read the repository, create a branch with the change, open the pull request, and read check results. Everything else is optional. GitHub's guidance for apps says to select the minimum permissions required, that apps start with none, and that Contents access covers HTTP Git operations. It also says Workflows access is needed only if the app edits files under the workflows folder.
That last point is worth noticing. Upgrading an action version means editing a workflow file, and a token that can edit workflows can change what your CI runs. Grant that only on repositories where you have decided you want it.
A least privilege checklist
| Capability | Give it? | Reason |
|---|---|---|
| Read repository contents | Yes | Needed to analyse and patch |
| Write a branch | Yes | The fix lives there |
| Open pull requests | Yes | The review vehicle |
| Merge into protected branches | No, until you choose it | Keeps a human in the loop |
| Edit workflow files | Per repository | Can change CI behaviour |
| Repository admin or settings | No | Not part of the job |
| Organisation secrets | No | A fix does not need them |
Scope and lifetime
- Install on selected repositories, not the whole organisation, during the pilot.
- Prefer a dedicated app or machine identity over a person's personal token, so the audit log shows the bot, and so a departing employee does not break it.
- Use short lived credentials where the platform supports them.
- Review the installed permissions quarterly. Account owners must approve new permissions, so a quiet expansion is harder, but check anyway.
Protect the branch, not just the bot
Branch protection is your second layer. Required reviews, required status checks and code owner approval apply to the bot like anyone else. GitHub's protected branch documentation describes each of these. If the bot cannot merge and the branch needs an approval, the worst case is a bad pull request that a reviewer rejects. See required status checks for automated fix PRs.
Where Safeguard fits
Safeguard's agent identity capability gives agents their own identities and audit trails, and autonomous remediation is off by default with every category on Manual. Start with a free scan before connecting anything.
Quick check
Can the bot use my personal access token?
It can, but a dedicated identity is better: actions are attributable, and the grant does not depend on one person.
Does the bot need access to secrets?
Normally no. A fix pull request does not need production credentials.
Sources
Last reviewed: 19 October 2026.
