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?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Least privilege means exactly what it says: the minimum permissions needed to do the job, nothing more. A comment agent with admin access is like hiring a receptionist and giving them the master key, the safe combination, and the power to fire employees. Replace the admin token with a fine-grained token scoped to exactly: read files, write PR comments — full stop.
Full explanation below image
Full Explanation
The principle of least privilege (PoLP) 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 (a hijacked agent with admin access can do significantly more damage than one with read + comment access) and agent error (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 — allows reading repository file contents - pull-requests: write — 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 — the API will reject any request requiring permissions beyond its token scope. This is a hard enforcement of least privilege at the authentication layer.
Why the other options fail: - Option A (keep admin token + monitoring) is a detective compensating control, not a prevention. The overprivileged token still exists and can still be exploited. Detection after misuse is inferior to prevention through scoping. - Option C (store in secrets for encryption) 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. - Option D (separate admin token per repository) 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.