Your security team is reviewing a new Copilot agent that will autonomously triage issues, label PRs, and close stale tickets across 12 repositories. During threat modeling, they identify that the agent's GitHub App has write access to all repositories in the organization. Which threat does this configuration most directly introduce, and what is the correct mitigation?
Select an answer to reveal the explanation.
Short Explanation
Think of blast radius like a fire: the less fuel in the room, the less damage when something goes wrong. If the agent has org-wide write access, one bug or compromise can hurt every repo. You need to scope the GitHub App installation to only the repositories it actually needs.
Full Explanation
Threat modeling an agentic workflow requires mapping each permission to the minimum surface area required for legitimate operation. When a GitHub App is installed with organization-wide write access, a single compromised token, a prompt injection, or a logic bug can affect every repository in the org simultaneously—this is blast radius amplification. The correct control is to scope the GitHub App installation at the repository level, granting access only to the 12 repositories the agent manages. This is the principle of least privilege applied at the installation boundary.
The rate-limiting mitigation addresses throughput, not lateral reach—rate limits do nothing to prevent the agent from writing to unintended repositories. The token-rotation mitigation improves credential hygiene but does not reduce the scope of what a valid token can access; a freshly rotated token with org-wide write is still dangerous. The webhook-disabling mitigation would break the agent's trigger mechanism and does not address the overly broad installation scope. The correct threat model conclusion is: minimize the installation scope first, then layer rate limits and rotation on top as defense-in-depth.