A pull request comment agent has two required capabilities: (1) read repository file contents, and (2) create and update comments on pull requests. The agent is currently configured with a GitHub personal access token (PAT) that grants full repository admin access, including settings, webhooks, branch protection management, and member administration. What change should be made to align the agent with least privilege principles?

The principle of least privilege requires that any actor — human or agent — be granted only the permissions necessary to perform its specific function. Granting an agent more permissions than it needs creates unnecessary risk in two scenarios: agent compromise, where a hijacked agent with admin access can do significantly more damage than one with read and comment access, and agent error, where a bug in the agent could accidentally trigger admin operations it was never intended to perform.

For this agent's two requirements, the correct GitHub token scopes are: contents: read, which allows reading repository file contents, and pull-requests: write, which allows creating and updating pull request comments. GitHub fine-grained personal access tokens and GitHub Apps both support this granular scope selection, allowing exactly these two permissions and nothing else. With this scoping, the agent literally cannot perform admin operations even if it attempts to, because the API will reject any request requiring permissions beyond its token scope. This is a hard enforcement of least privilege at the authentication layer.

The monitoring approach, which keeps the existing admin token but adds alerts if the agent attempts to use admin capabilities, is a detective compensating control, not a prevention. The overprivileged token still exists and can still be exploited, and detection after misuse is inferior to prevention through scoping.

The secrets-storage approach, which keeps the admin token but stores it in GitHub Actions secrets so it is encrypted and not visible in logs, addresses credential confidentiality but not privilege scope. An encrypted admin token is still an admin token with full admin capabilities. Encryption prevents the token from being read; it does not restrict what the token can do when used.

The per-repository admin token approach, which creates a separate admin token for each repository the agent accesses to reduce the blast radius of any single token compromise, multiplies the number of overprivileged tokens rather than reducing the privilege level of any individual token. The blast radius per token is slightly reduced, but the total attack surface is increased, and all tokens are still over-privileged for the task.

The correct fix is always to scope the credential to the minimum permissions required, using fine-grained token controls.