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.
Short Explanation and Infographic
A system prompt boundary is a suggestion; a scoped installation token is a fence. GitHub App installation tokens can be restricted to specific repository IDs at issuance time — any API call targeting a different repo returns a 404 or 403, regardless of what the agent decides to do. That is the exam's gold-standard enforcement for repository scope.
Full explanation below image
![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-infographic.webp)
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.
Option A is wrong. 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.
Option B is correct. 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.
Option C is wrong. 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.
Option D is wrong. 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.