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?

The principle of least privilege in the SDLC context means permissions are granted based on current, verified requirements—not anticipated future needs. Requesting only Pull requests: Write, with Pull requests: Read implicit, matches the agent's actual job: posting review comments on open pull requests. Granting Contents: Write to an agent that only posts comments means 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. If reading pull request diffs is needed, that comes through the Pull requests API, not Contents. Contents: Read is only needed if the agent reads file content, which the scenario does not specify. Accepting the developer's suggestion because extra permissions simplify future feature additions is the classic least-privilege antipattern. When the agent's requirements expand, the correct approach is to go through new security review and update the manifest—not to grant excess permissions upfront. Requesting Administration: Write to ensure recovery from permission errors is far worse—it would give the agent the ability to add members, change branch protection rules, and delete the repository itself. Requesting all available permissions and using runtime filtering to limit what the agent actually calls is 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.