A security policy requires that an autonomous agent may only commit changes to branches matching the pattern agent/ and must never be able to push directly to main or any release branch (release/). Which combination of controls best enforces this policy?
Select an answer to reveal the explanation.
Short Explanation
You need two independent locks: branch protection rules on main and release/ block direct pushes at the GitHub API layer, and scoping the workflow trigger to agent/ refs keeps the agent from running in the wrong branch context. That defense-in-depth pairing is what enforces the policy.
Full Explanation
Branch-based scope restriction for agents requires defense-in-depth: the policy must be enforced at both the agent's execution context, where it runs, and at the repository level, what it can push to. Relying on a single control creates a single point of failure.
The correct approach combines two independent, complementary controls. Branch protection rules on main and all release/ branches require pull requests and block direct pushes, enforcing the policy at the GitHub API layer so no direct push is possible regardless of who or what is making the attempt. Even if the agent has a misconfigured token, it cannot bypass branch protection. Scoping the agent's workflow trigger to only run when the ref matches the agent/ pattern means the agent workflow activates only in the correct branch context, preventing the agent from accidentally operating in a release context. Together, these create redundant enforcement.
The pre-commit hook approach is wrong because pre-commit hooks are client-side controls that run in the local git environment. When an agent pushes via GitHub's API, which is how MCP-based GitHub tools work, pre-commit hooks do not execute at all; they run in the committer's local git repository, not server-side. An agent making API calls entirely bypasses client-side hooks.
The system prompt branch-name validation approach is wrong because system prompt instructions operate within the agent's reasoning layer and provide no structural enforcement. A sufficiently complex reasoning chain, an injection attack, or a simple misinterpretation could cause the agent to ignore the instruction. This is especially problematic because the agent might reason that committing to main is the fastest way to complete a task.
The fine-grained personal access token approach is wrong because GitHub's fine-grained personal access tokens do support repository-level permission scoping, but they do not support branch-level permission restrictions within a repository at the token configuration level. Token scopes operate at the repository and permission-type granularity, not at the branch name granularity. Branch protection rules are the correct mechanism for per-branch access control.