A security-sensitive agent should only be able to read and write files within the payments-service repository and must not access any other repository in the organization. Which configuration approach correctly scopes the agent to that single repository?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Scoping an agent to a single repository is a permissions problem, not a configuration label problem. The actual enforcement happens at the credential level — specifically through the GitHub App installation settings or the token scope. By restricting the app or token installation to only payments-service and setting organization access to none, the agent literally cannot authenticate to any other repository, regardless of what it tries. That's real security, not honor-system self-restriction.
Full explanation below image
Full Explanation
Repository scoping for agents is enforced through the authentication mechanism the agent uses to call GitHub APIs. GitHub Apps (and fine-grained personal access tokens) allow precise repository scope restriction: you can configure an installation to cover only specific repositories, effectively limiting any token issued by that installation to those repositories only.
Option A is correct. When configuring a GitHub App or fine-grained token, setting organization access to none and explicitly listing only payments-service under the repository access configuration creates a hard platform-level boundary. Any API call the agent makes with that token to access other repositories will be rejected with a 403 or 404 by GitHub's API — the agent cannot access what the token isn't scoped to, regardless of agent-level configuration.
Option B is incorrect. There is no scope: single flag in the agent definition spec. While some agent frameworks may use the triggering repository as a default context, this does not prevent the agent from calling GitHub APIs to access other repositories if its token has broader permissions.
Option C is incorrect. A secret named AGENT_SCOPE is just data — it has no enforcement power. An agent that reads this secret would need to voluntarily restrict itself, which is not a security control. A compromised or misbehaving agent could simply ignore this value.
Option D is incorrect. While it's true that agents installed in a repository's .github/agents/ directory may default to that repository's context for some operations, the platform does not enforce strict repository isolation based solely on file placement. The actual access boundary is determined by the token/credential the agent uses.
Key exam point: repository scoping is enforced through credential/token scope (GitHub App installation settings or fine-grained PAT repository restrictions), not through YAML flags or secret values.