A Copilot agent uses the GitHub MCP server to search issues and read pull request metadata across a single public repository. During OAuth authorization, the developer requests the 'repo' scope. A security engineer flags this as excessive. What is the minimum OAuth scope set that satisfies the agent's stated requirements?
Select an answer to reveal the explanation.
Short Explanation
OAuth scopes are like a fishing license that specifies which waters and which fish. You don't need the broad 'repo' scope, which gives full read/write access to all repositories including private ones, just to read a single public repo. 'public_repo' is the precise license for this job.
Full Explanation
GitHub's OAuth scopes follow a hierarchical model where broader scopes include all permissions of narrower ones. The 'repo' scope grants full read/write access to all repositories the user has access to, including private repositories. Requesting it for an agent that only reads public data violates least privilege in two ways: it grants write access when only read is needed, and it grants access to private repositories when only a public repository is needed. For this use case, searching issues is available via the public issues API with no token for public repos, or 'public_repo' for consistency, and reading pull request metadata is available via the pulls API with 'public_repo' for public repositories. The correct minimum scope is 'public_repo', which grants read/write access to public repositories only. Since the agent only reads, the write capability within 'public_repo' is an acceptable residual risk that should be further mitigated by tool allow-listing so the agent cannot call write-capable tools even with that scope. The claim that 'repo' scope is the minimum required for any repository interaction and cannot be narrowed further is incorrect because 'repo' is not the minimum for public repositories; 'public_repo' is a narrower alternative. The claim that 'read:org' and 'read:user' scopes are sufficient for all repository read operations is incorrect because 'read:org' grants access to organization membership and team data, not repository content, and 'read:user' grants access to user profile data; neither provides repository issue or PR access. The claim that 'admin:repo_hook' scope is needed so the agent can register for webhook events on the repository is incorrect because 'admin:repo_hook' is for managing webhooks, not reading issues or PRs, and is a high-privilege scope that would be dangerous to grant unnecessarily.