GitHub Copilot workflow approval boundary — Hovvi
How GitHub Copilot keeps Actions workflows from running by default after an Agent-authored pull request, making workflow inspection and approval a separate boundary around potentially privileged execution.
Published by Hovvi Research. Observed ; materially updated .
What happened
Let an Agent propose a repository change, hold the potentially privileged workflow by default, give a reviewer relevant inspection context and require a separate approval before execution unless an explicit administrator policy changes that boundary. Separate inspection of generated repository changes from permission to execute repository workflows, while making the administrator policy that can relax the default legible.
Evidence
Generated code review and privileged workflow execution remain separate decisions.
| Decision point | Documented behavior | Hovvi application limit |
|---|---|---|
| Copilot pushes a pull request | Actions workflows are held by default | Do not imply that the pull request, its code review or its merge has already run CI |
| Workflow files are proposed | The user is directed to inspect .github/workflows because the run can be privileged | Treat secret access as a review rationale, not proof that any secret was exposed |
| A held run needs permission | A separate Approve and run workflows control allows the run | Do not call approval a verified workflow result or external-state outcome |
| Repository policy changes | An administrator can configure a manual-approval exception | Make automation policy visible rather than assuming every repository uses the default |
An Agent's proposed change does not silently authorize its privileged execution.
The documentation establishes a default hold, inspection context and an explicit approval action. It does not establish a captured interface, a completed workflow, a recipient preview or an external-side effect.
Observed facts
- GitHub documents that Actions workflows do not run automatically by default when Copilot pushes changes to a pull request.
- The same guidance warns that workflows can be privileged and may access sensitive secrets, and directs the user to inspect proposed changes, especially files in .github/workflows.
- The documented control for allowing the held run is Approve and run workflows in the pull request merge box.
- GitHub documents an organization or enterprise setting that can change the default and let Copilot-initiated workflow runs proceed without manual approval.
Editorial inference
- Agent trust is easier to calibrate when accepting generated work and permitting privileged execution are shown as separate, reviewable decisions instead of one silent transition.
Evidence views
- Agent-authored pull request with review context
- Changed workflow-file inspection cue
- Explicit approval before workflow execution
- Administrator policy explaining the automatic-run exception
Founder takeaway
Do not let an Agent-authored change silently authorize its own elevated execution: make the hold, the review context, the separate approval and the policy exception explicit.
Use when
- Agent-authored pull requests can alter CI or other repository workflows
- A reviewer can safely wait to inspect the proposed change before workflow execution
- The product needs a clear distinction between content acceptance and permission for elevated automation
Avoid when
- The required outcome is a recipient or message preview rather than a repository-workflow boundary
- The workflow must run automatically and the organization has accepted that risk through an explicit policy
- A team cannot inspect workflow changes or communicate the consequences of the administrator exception
Next implementation step
Design an Agent-authored change review path that makes the workflow hold, workflow-file inspection, explicit execution approval and administrator-policy exception understandable before a privileged run begins.
Acceptance criteria
- A reviewer can distinguish accepting an Agent-authored code change from allowing its workflow to run
- The interface explains why changed workflow files merit inspection before elevated automation begins
- The default hold and any administrator-configured exception are both legible
- No workflow outcome, secret exposure, recipient preview or external write is claimed without separate evidence
- No public reference artifact contains third-party product media, repository data or account state
Related cases
- Default holds on elevated capability: Supabase Row Level Security guardrails — Hovvi
GitHub holds an Agent-authored workflow before privileged execution unless a separate approval or administrator policy permits it; Supabase closes API access after RLS is enabled until deliberate policies grant a route through the boundary.
Version history
Current snapshot: snap_github_copilot_workflow_approval_2026_09_02 — Added a bounded GitHub Copilot agent-trust Task Reference from public GitHub Docs under a link-only policy. GitHub visual design, logos and the source-page screenshot are not copied; this is documentation evidence, not an observed interface Flow.
Use with an Agent
Example read-only MCP query:
Retrieve the Hovvi Founder case fc_github_copilot_workflow_approval_2026_09 with observed facts, evidence screens, applicability limits and citations.