An agent is designed to automate issue labeling in a GitHub repository. It reads open issues and applies predefined labels based on their content. A developer proposes using a classic Personal Access Token (PAT) with full repo scope for simplicity, arguing it is easier to set up than fine-grained alternatives. What is the primary security concern with this approach, and what is the recommended alternative?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Think of a classic PAT with full repo scope like handing a contractor a master key to your entire building when they only need to access one filing cabinet — that is the problem here. Option B is correct: a fine-grained PAT scoped exclusively to Issues: Read and Write on one specific repository follows least privilege to the letter. If the token is stolen or leaked, the blast radius is contained to issue operations only. Never over-scope credentials just for convenience.
Full explanation below image
Full Explanation
The principle of least privilege (PoLP) dictates that any credential should grant only the permissions required to perform its specific task and nothing more. A classic PAT with full repo scope violates this by granting the bearer write access to code, branches, settings, webhooks, secrets, and deploy keys across every repository the token owner can access. If this token is leaked through logs, prompt injection, or code exposure, an attacker gains sweeping control over the organization repositories.
Option B is correct because GitHub fine-grained PATs allow scoping to a single repository and a specific permission category. An issue-labeling agent needs exactly two permissions: Issues: Read (to fetch open issues) and Issues: Write (to apply labels). Nothing else. A fine-grained PAT configured this way cannot push code, modify branch protection, access secrets, or affect any repository other than the designated one.
Option A is wrong on two counts: classic PATs work perfectly fine with the GitHub API, and an organization-level PAT would expand the blast radius even further by potentially touching all repos in the org — the opposite of least privilege.
Option C is tempting for public repositories, but the GitHub API has strict rate limits for unauthenticated requests (60 requests/hour vs. 5,000 for authenticated). More critically, writing labels always requires authentication regardless of repository visibility, so unauthenticated access cannot satisfy the agent write requirement.
Option D misunderstands Deploy Keys: they are SSH keys tied to a single repository, which is a scope improvement, but they are designed for git operations (clone, push, pull) — not GitHub REST API calls for issue management. They also require read-only mode to be explicitly configured; by default they can have write access, and they cannot be scoped to specific GitHub API resources like issues.