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
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. You should use a fine-grained PAT scoped only to Issues: Read and Write on the target repository, because that follows least privilege and contains the blast radius if the token leaks. Never over-scope credentials just for convenience.
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. Classic PATs with full repo scope violate 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's repositories. The recommended alternative is a fine-grained PAT scoped only to Issues: Read and Write on the specific target repository. An issue-labeling agent needs exactly two permissions: Issues: Read to fetch open issues and Issues: Write to apply labels. Nothing else. Fine-grained PATs configured this way cannot push code, modify branch protection, access secrets, or affect any repository other than the designated one. The claim that classic PATs cannot be used with the GitHub API is incorrect; classic PATs work perfectly fine with the GitHub API. An organization-level PAT would expand the blast radius even further by potentially touching all repositories in the organization, which is the opposite of least privilege. The suggestion to use unauthenticated GitHub API calls for a public repository is tempting, but the GitHub API has strict rate limits for unauthenticated requests, 60 requests per hour versus 5,000 for authenticated requests. More critically, writing labels always requires authentication regardless of repository visibility, so unauthenticated access cannot satisfy the agent's write requirement. The suggestion to use a Deploy Key because it is read-only by default misunderstands Deploy Keys. Deploy Keys are SSH keys tied to a single repository, which is a scope improvement, but they are designed for git operations such as clone, push, and 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.