Task 6.2: Implement guardrails and human-in-the-loop workflows

• ARestrict Copilot cloud agent to repository administrators only

  Incorrect

  Administrators manage settings, but these files can still be edited by anyone with write access unless protected.

• BMove the files into the .github-private repository

  Incorrect

  Setup steps, hooks and repository agents must live in the repository itself.

• CAssign those paths to the platform team in CODEOWNERS and require code owner review in a ruleset

  Correct

  GitHub recommends protecting Copilot and MCP configuration files with CODEOWNERS and the Require review from Code Owners rule.

• DAsk Copilot in custom instructions never to edit those files

  Incorrect

  Instructions guide the model; they don't stop people changing the files.

When building guardrails for Copilot cloud agent, GitHub suggests protecting important Copilot and MCP configuration files with a CODEOWNERS file and enabling the Require review from Code Owners rule, so edits must be approved by specific teams. Files such as copilot-setup-steps.yml can be edited by anyone with write access by default; the customization cheat sheet lists the paths to target.

• ARequire a pull request before merging, with at least one approval

  Correct

  GitHub says to enable at least Require a pull request before merging, requiring at least one approval.

• BRequire linear history

  Incorrect

  Linear history controls merge commits; it isn't one of the minimum rules named.

• CBlock force pushes

  Correct

  Block force pushes is the other rule the guidance names as a minimum.

• DRestrict file extensions

  Incorrect

  File extension limits don't gate unvetted changes or history rewrites.

• ERequire deployments to succeed before merging

  Incorrect

  That rule ties merging to deployments; it isn't part of the minimum baseline named.

To stop developers or bad actors from unilaterally applying unvetted AI suggestions or agent work to sensitive codebases, GitHub suggests a branch ruleset that enables at least Require a pull request before merging, with at least one approval, and Block force pushes. You can add more rules on top of this baseline.

• ABoth run, because the enterprise's allow list covers npm

  Incorrect

  A deny rule from any source wins over allow rules.

• Bnpm publish is blocked, and editing /docs needs approval because it is outside every allowlist

  Correct

  A deny from any managed source blocks the operation, and allowlists intersect, so unmatched operations require approval.

• Cnpm publish asks once, then is remembered for the session

  Incorrect

  Deny blocks the operation outright; it isn't an ask.

• DThe /docs edit is allowed, since allowlists from different sources are combined

  Incorrect

  The effective allowlist is the intersection of the sources that declare one, not the union.

Managed permissions use deny > ask > allow precedence. A deny rule set by any managed settings source blocks the operation for all users regardless of other sources. The effective allowlist is the intersection of all sources that declare one, not the union, and when any source defines permission rules, an unmatched supported operation defaults to requiring approval.

• APre-approve low-risk tools such as shell(npm test) and keep prompts for the rest

  Correct

  Read-only operations already run without prompts; narrow allow rules remove prompts that add little safety.

• BStandardize on --allow-all through a shell alias so prompts never appear

  Incorrect

  GitHub strongly advises against an alias that applies allow-all every time.

• CRequire approval for every read and search as well, so that nothing at all slips through

  Incorrect

  Approving read-only operations adds friction without materially reducing risk.

• DTurn off the CLI's permission system and rely on code review afterwards

  Incorrect

  Review afterwards doesn't stop destructive commands at the moment they run.

In Copilot CLI, read-only operations such as searching, reading files and read-only shell commands are allowed automatically, while tools that can modify the system need approval. To cut needless prompts, allow specific tools or subcommand patterns with --allow-tool, or approve them for a location, keeping approvals where they reduce risk. GitHub cautions against aliasing allow-all options so they apply to every session.

• ADismiss stale pull request approvals when new commits are pushed

  Correct

  Approvals are dismissed when the diff changes, so new changes need approval again.

• BRequire linear history

  Incorrect

  That controls merge commits, not approvals.

• CRestrict file size

  Incorrect

  That limits file sizes, not approvals.

• DRequire signed commits

  Incorrect

  Signing shows who committed; it doesn't reset approvals.

With Dismiss stale pull request approvals when new commits are pushed, an approval is dismissed when the approved diff changes, and the pull request needs approving again. GitHub suggests it if you're concerned about pull requests being hijacked.

• AMark it ready for review

  Incorrect

  The agent cannot mark its pull requests ready for review.

• BApprove it

  Incorrect

  The agent cannot approve pull requests.

• CMerge it

  Incorrect

  The agent cannot merge pull requests.

• DPush commits to the pull request's branch

  Correct

  The agent can push to its branch; marking ready, approving and merging need a person.

Draft pull requests created by Copilot cloud agent must be reviewed and merged by a human. The agent can push to its branch, but it cannot mark its pull requests ready for review and cannot approve or merge a pull request.

• ATrust hook input, since it comes from Copilot

  Incorrect

  Validate and sanitize all input processed by hooks.

• BBuild commands by joining strings without escaping

  Incorrect

  Use proper shell escaping to prevent injection.

• CNever log sensitive data such as tokens or passwords

  Correct

  Hooks should never log secrets.

• DAvoid timeouts so checks always finish

  Incorrect

  Set appropriate timeouts to avoid blocking the agent.

GitHub's security considerations for hooks are: validate and sanitize hook input, use proper shell escaping, never log sensitive data such as tokens or passwords, give scripts and logs appropriate permissions, be cautious with external network calls, and set timeouts to prevent resource exhaustion.

• ANothing; gh skill only lists verified skills

  Incorrect

  Skills are not verified by GitHub.

• BInspect it with gh skill preview

  Correct

  Skills aren't verified by GitHub, so preview the content before installing.

• CRun it once in Autopilot to see what it does

  Incorrect

  Running an untrusted skill is the risk to avoid.

• DPin it with --pin, which scans it for malware

  Incorrect

  --pin locks a version; it doesn't scan.

Skills are not verified by GitHub and may contain prompt injections, hidden instructions or malicious scripts. Always inspect a skill before installing it; gh skill preview renders its SKILL.md and file tree in your terminal without installing anything.