A developer agent is provisioned to work exclusively within the acme-corp/payments-service repository. During a pipeline run, the agent's reasoning determines that it needs to read a utility function from acme-corp/shared-utils to complete its task. The agent attempts to call a GitHub MCP tool targeting the shared-utils repository. What is the correct architecture to prevent this while still allowing the agent to complete legitimate tasks?
Select an answer to reveal the explanation.
![Landscape 2048x1536 infographic titled 'Repository Scope Enforcement: Installation Token vs. System Prompt'. Left side shows two approaches side by side: Approach 1 labeled 'System Prompt Boundary' shows a dotted line fence around payments-service that the agent's arrow can clearly cross; Approach 2 labeled 'Installation Token Scope' shows a solid padlock boundary around payments-service that blocks the agent arrow with a red 403 error badge. Center shows a GitHub App token issuance diagram: token request specifies 'repoids: [payments-service]', resulting token has a scope badge showing only one repo. Right side shows a comparison: 'Reasoning layer controls = bypassable' vs 'Token layer controls = enforced'. GitHub color scheme, lock and shield icons, clean flat design.](/media/github/gh-600/GH-600-e4-q014.webp)
Short Explanation
A system prompt boundary is just a suggestion; a scoped installation token is a fence. You provision the agent's GitHub token as a GitHub App installation token scoped only to payments-service, so any MCP call targeting another repo gets rejected by the API. That's the gold-standard enforcement for repository scope.
Full Explanation
Repository scope enforcement for agents must happen at the authentication/authorization layer, not at the reasoning layer. The goal is to make it structurally impossible for the agent to access out-of-scope repositories, not merely inadvisable.
The system-prompt-only approach is wrong because system prompt instructions operate within the agent's reasoning and can be overridden, misunderstood, or bypassed—especially in complex multi-step reasoning chains where the agent might rationalize cross-repository access as necessary. This does not prevent the actual API call.
The scoped GitHub App installation token is correct because GitHub App installation tokens are scoped during token generation to a specific set of repository IDs. When you request an installation token and specify only the payments-service repository's ID, the resulting token is cryptographically bound to that scope. Any GitHub API call—including MCP-proxied calls—that targets shared-utils will receive a 404 Not Found or 403 Forbidden response because the token does not grant access to that repository. This is enforcement at the infrastructure layer.
The MCP server repository blocklist is wrong because a repository blocklist is a deny-list approach that requires you to enumerate every repository the agent should not access—which is impractical in a large organization and fails to account for new repositories. Allow-list scoping via token scope is more secure and maintainable: the agent can only access what is explicitly permitted.
The GitHub Actions GITHUB_TOKEN default approach is wrong because the GITHUB_TOKEN in GitHub Actions does default to the repository that triggered the workflow, but its actual permission scope depends on how it was configured in the workflow permissions block. It can be granted broader access by the workflow author, or the agent could use a different token entirely. Relying on GITHUB_TOKEN defaults is not a reliable enforcement mechanism, and it does not prevent an agent from using a separately provisioned credential.