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
Scoping an agent to one repo is a permissions problem, not a label problem. You enforce it at the credential level by setting organization access to none and listing only payments-service in the app or token installation. Then the agent literally can't authenticate to any other repo, no matter what it tries.
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.
The correct approach — setting the agent's organization_access field to none and listing only payments-service under repositories in the agent's token or app installation settings — 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.
The scope: single flag approach 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.
The repository-level secret named AGENT_SCOPE=payments-service approach is incorrect. The 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. If the agent is compromised or misbehaving, it could simply ignore this value.
The .github/agents/ directory placement approach 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 or credential the agent uses.
Key exam point: repository scoping is enforced through credential or token scope, such as GitHub App installation settings or fine-grained personal access token repository restrictions, not through YAML flags or secret values.