How do you require human approval before automation changes code?

Put the risky job behind a GitHub environment that has required reviewers. The job pauses until a named person or team approves, and secrets tied to that environment stay locked until then. Check your plan, because protection rules on private repositories need a paid tier.

Where approval belongs

Not every automation step needs a human. Creating a ticket or posting to chat is low risk. Opening a pull request is moderate, since a reviewer still decides whether to merge. The steps worth a hard pause are the ones that change something with no later review: pushing to a protected branch, rotating a credential, closing a batch of alerts, or touching production configuration.

Setup steps

GitHub's documentation for managing environments describes this flow:

1. In the repository settings, create an environment with a clear name, such as remediation-approval.
2. Turn on required reviewers and add up to 6 people or teams. Only one of them needs to approve for the job to proceed.
3. Optionally select prevent self-review so the person who triggered the run cannot approve it.
4. Optionally add a wait timer.
5. Add environment secrets and variables. The docs say these are available only to jobs that use the environment, and only after the protection rules pass.
6. In the workflow, reference the environment on the job that needs approval.

jobs:
  apply-fixes:
    runs-on: ubuntu-latest
    environment: remediation-approval
    steps:
      - run: ./apply-approved-fixes.sh

Plan limits to check first

The same page says users on GitHub Free can only configure environments for public repositories, and that for private repositories you need GitHub Pro, Team or Enterprise. It also warns that if you convert a repository from public to private, configured protection rules or environment secrets are ignored on plans that do not support them. Read that again before relying on it as a control: a gate that silently stops working is worse than no gate. Confirm behaviour in a test run after any plan or visibility change.

What the approver should see

An approval click is only as good as the information in front of the approver. Before the job reaches the gate, have an earlier job write a short summary: what will change, in which repositories, which versions, test results and a link to the diff. Our post on what to ask before enabling automated fix pull requests and the shadow mode approach help here. A job summary, covered in writing a security report as a job summary, is a convenient place for it.

Alternatives when environments do not fit

• Require pull request review and branch protection, so the human gate is the merge itself.
• Use a manual workflow_dispatch run that only a small group can start.
• Keep the automation in report only mode until the team trusts it.

Try it yourself

Click through it at your own pace, or open it full screen.

Look at how a fix is proposed to a person before anything is applied.

Safeguard's autonomous remediation opens fix pull requests, is off by default, and starts with every category on Manual. Try the free scan at gold.safeguard.sh/scan.

Quick check

Sources

• GitHub Docs: managing environments for deployment

Last reviewed: 19 October 2026.