A developer wants a Copilot agent to work exclusively on feature branches prefixed with 'agent/' so that it never modifies code on main or release branches. Which configuration approach best enforces this branch-based scope?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Branch protection rules are the platform-level guardrails that actually enforce what can and can't be pushed. Telling the model in plain language to stick to agent/* branches is like putting up a 'please knock' sign — polite, but not a lock. The correct approach layers protection rules on main and release branches (so the agent literally cannot push there) with agent configuration that always creates agent/-prefixed branches for its work.
Full explanation below image
Full Explanation
Branch-based scope isolation ensures an agent's changes are quarantined to purpose-built branches and never land directly on protected branches. This is enforced through a combination of platform-level controls and agent configuration:
1. Branch protection rules on main and release branches (e.g., release/*) block direct pushes, require pull requests, and may require status checks. The agent cannot bypass these rules regardless of what the model attempts — the GitHub API will reject the push with a 403.
2. Agent configuration that specifies the branch naming pattern (e.g., creating branches matching agent/{task-id} or agent/{description}) ensures the agent's working branches are clearly identifiable and isolated.
Together, these controls create a defense-in-depth setup: even if the agent tries to push to main, the branch protection rule prevents it; and the naming convention makes agent branches easy to identify and review.
Option B is incorrect because model-level instructions are not access controls. The model may misinterpret context, an adversarial input could override the instruction, and — most importantly — the GitHub API does not check system prompt instructions before accepting a push. Instructions guide behavior probabilistically; they do not enforce it deterministically.
Option C is incorrect because a branch deletion trigger is unrelated to restricting which branches an agent can write to. It would also be counterproductive — triggering the agent when branches are deleted is not a useful CI pattern for this scenario.
Option D is incorrect because renaming the default branch to agent/main would break the entire repository's normal workflow. Team members, other CI pipelines, and integrations all depend on a stable default branch name like main. This is not a scoping strategy; it's a disruptive rename.
Option A is correct. Branch protection rules provide enforceable platform controls, and agent branch naming configuration provides operational isolation.