Deploy Gate · GitHub workflows

GitHub approval gates for AI-authored changes.

Deploy Gate adds an authorization check and signed receipt to a configured GitHub workflow. Keep your code review and CI checks, and record who authorized the exact change.

Review setup Walk through an approval

What you are connecting

Your GitHub workflow → authorization check → protected merge or deployment.

Start with one repository, one selected workflow, and named approvers.

Example actionProtected GitHub change

Change requests authorization
The workflow identifies the commit and action.
Named approver reviews
A consequential change waits for a decision.
Signed receipt checked
The receipt must cover this commit and action.
Authorization check passes
Other required CI and deployment checks still apply.

Change requests authorization

Illustrative flow with required checks configured. No actions are sent.

The protected path

Keep your GitHub approval workflow

GitHub reviews and deployment protection remain part of your workflow. Configure Deploy Gate alongside those controls so an authorization record covers the intended commit and action. A GitHub Actions approval gate only protects the paths covered by your required checks and deployment rules.

Tie approval to the change under review

Start with one repository and a protected change. Review the approval, compare the receipt with the intended commit, then test a new commit and a denied request. Record successful execution separately from the authorization decision.

Read the GitHub approval-gate guide

GitHub approvals and Deploy Gate

What each approval leaves on record

GitHub environment reviewers and pull request reviews decide whether a job runs or a branch merges. Deploy Gate adds a required check above them: a signer approves the specific change, and Permission Protocol issues a record that can be checked outside GitHub.

GitHub approvals compared with Deploy Gate
Question	GitHub environment reviewers	Pull request reviews with branch rules	Deploy Gate
Designed to gate	A workflow job that references the environment. The job waits until a required reviewer approves it.	Merging a pull request into a protected branch.	The pull request's check, and optionally the deploy job after merge.
Who approves	Up to six listed people or teams; one approval lets the job run. You can stop people approving runs they triggered.	The required number of reviewers with write access, and code owners when you require them.	A signer you configure in Permission Protocol.
What the approval covers	That workflow run's deployment to that environment.	The pull request. A branch rule can dismiss approvals when new commits change the diff.	The repository, pull request, head commit, environment, and capability. In deploy mode an approval ships once, and a commit that no gated pull request merged is refused.
What it leaves on record	The approval, with an optional comment, on the workflow run in GitHub.	Review records on the pull request in GitHub.	A receipt issued by Permission Protocol that names the approver who signed, the policy, and the scope. Its Ed25519 signature verifies against the published issuer key, offline or through the API.
If the approval service is unreachable	Runs inside GitHub.	Runs inside GitHub.	Production environments fail closed. Other environments can opt into fail-open.

Checked against GitHub Docs and the Deploy Gate action (v2.3.0) on October 14, 2026.

Use them together. Keep pull request reviews for code quality and environment reviewers for deploy approval, then add Deploy Gate where a change needs a signer-approved record that someone outside GitHub can verify. Deploy Gate checks the pull requests and deploys your workflow routes through it, whoever wrote them.

Sources: GitHub environments (opens in a new tab), protected branches (opens in a new tab), Deploy Gate action v2.3.0 (opens in a new tab).

Connect a repository Walk through an approval (an illustration; nothing real runs)

From setup to a tested decision

Connect one workflow, then verify it.

Connect one repository
Install the GitHub App for the selected repository and choose the approval workflow you want to evaluate.
Configure the enforced path
Set the required check and deployment rules. Select protected changes and approvers; keep your existing CI and review requirements.
Exercise the gate
Test approval, denial, changed commits, alternate paths, and service errors. Inspect the matching receipt before using the workflow in production.

Connect a repository Review the GitHub Action

Scope and boundaries

What this controls, and what it doesn’t.

Required checks and deployment rules must actually cover the production path. Administrators and alternate credentials can change or bypass that path.
An approval must cover the intended commit and action. A changed action needs a fresh evaluation.
Outage behavior varies by integration and version. Some Action versions continue on API errors; verify the behavior you intend to rely on.
An authorization receipt documents approval. It does not by itself prove that execution succeeded.

The record behind the decision

Inspect the authorization evidence.

Review the action, commit, approver, policy, and signature. Compare the receipt with the action your workflow actually intends to execute.

From approval to receipt Discuss your workflow

How to choose which AI actions need human approval

Your first workflow

Ready to test your first workflow?

Work through setup, approval, denial, and evidence inspection. Keep track of your checks before expanding the rollout.

Open the test checklist