A Copilot agent is assigned to maintain the 'frontend' repository. Its MCP tools include create_branch, commit_file, and open_pull_request. A developer notices that when asked to 'apply the same fix to all affected repositories,' the agent successfully creates branches in the 'backend' and 'infrastructure' repositories, which it was never authorized to access. What control prevents cross-repository scope violations?
Select an answer to reveal the explanation.
Short Explanation
Scope the GitHub App installation to the frontend repository only. That way, the token used by the MCP tools can't authenticate to backend or infrastructure, so the agent can't act outside its lane. Token-level enforcement beats application-level logic every time.
Full Explanation
The failure here is that the agent's GitHub App installation token has access to all repositories, so MCP tools calling the GitHub API with different repository names succeed. This is a scope confinement violation—the agent's effective access extends far beyond its intended mandate.
The correct fix is to configure the GitHub App installation with repository-level scoping. When you install a GitHub App, you can choose 'All repositories' or 'Only select repositories.' For this agent, the installation should be scoped to only the 'frontend' repository. When the MCP tool attempts to create a branch in 'backend', the API call returns a 404 (not found) or 403 (forbidden) because the App installation token is not valid for that repository. This is an infrastructure-level enforcement that cannot be bypassed by user instructions, prompt injection, or application logic bugs.
The system-prompt rule specifying that the agent should only work in the 'frontend' repository is the weakest control—user instructions like 'apply to all affected repositories' can override it, and prompt injection can manipulate it. It's guidance, not enforcement. The logging-warning approach, where MCP tools log a warning when called with repositories other than 'frontend', is a detection control, not prevention—the unauthorized actions already happened. The application-code validation approach, where the agent must include the repository name in each tool call and the application validates that it matches 'frontend', is better than a system prompt but worse than infrastructure enforcement: application logic can have bugs, can be bypassed during error handling, and creates maintenance burden. The GitHub App installation scope is the authoritative boundary.