A developer is building a Copilot agent that only reads open pull requests and posts review comments. During the SDLC security review, the architect asks which GitHub App permissions should be requested. The developer suggests requesting 'Pull requests: Write' plus 'Contents: Write' to future-proof the agent. What should the architect recommend instead?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Think of permissions like keys on a keyring: you only carry keys to rooms you'll actually enter today. Future-proofing by granting unused permissions violates least privilege and dramatically expands what a compromised agent can do. Security reviews exist precisely to catch this pattern.
Full explanation below image
Full Explanation
The principle of least privilege in the SDLC context means permissions are granted based on current, verified requirements—not anticipated future needs. Granting 'Contents: Write' to an agent that only posts comments means a compromised or misbehaving agent could rewrite source files, inject malicious code, or delete files entirely. These are not hypothetical risks: prompt injection attacks routinely attempt to leverage unused permissions.
Option A ('future-proofing') is the classic least-privilege antipattern. When the agent's requirements expand, the correct approach is to go through a new security review and update the manifest—not to grant excess permissions upfront.
Option C (Administration: Write) is far worse—it would give the agent the ability to add members, change branch protection rules, and delete the repository itself.
Option D (grant all, filter at runtime) is a defense-in-depth failure: runtime filters can be bypassed, misconfigured, or absent in error paths. The permission boundary at the OAuth/GitHub App layer is the authoritative enforcement point, not application logic.
The correct answer grants only what is needed right now: 'Pull requests: Write' enables posting review comments, and 'Contents: Read' is only needed if the agent reads file content (which the scenario does not specify). If reading PR diffs is needed, that comes through the Pull requests API, not Contents.