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 and Infographic
Think of blast radius like a fire: the less fuel in the room, the less damage when something goes wrong. An agent with org-wide write access can cause org-wide harm if compromised or buggy. Scoping installation to specific repositories directly limits blast radius—the core threat modeling principle here.
Full explanation below image
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.
Option A (rate limiting) addresses throughput, not lateral reach—rate limits do nothing to prevent the agent from writing to unintended repositories. Option C (token rotation) 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. Option D (disabling webhooks) 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.