GitHub merge approval policy

The control gap

A merge is a concrete production-impact boundary and should not inherit the same treatment as reading or commenting on a pull request.

A merge rule should consume repository facts that already exist: branch name, protection status, pull-request author, changed paths, required checks, and the code owners responsible for the affected area. The agent should not decide that its own patch is low risk. Endram makes the decision from normalized request context and routes the exact merge request to the owner named by policy.

Treat approval as authorization for one commit SHA, not permission to merge whatever reaches the branch later. If the head changes, the original approval should no longer match. The decision record should retain the repository, pull request, base and head SHAs, reviewer, policy version, and GitHub result so an auditor can follow the complete chain.

Evaluate merge method and branch protections at execution time. Squash, merge commit, and rebase can produce different resulting identifiers, while an administrator override may bypass required checks. The adapter should refuse an approved operation if required checks regress, the base branch changes, or GitHub reports the pull request is no longer mergeable.

Route review from ownership facts rather than a fixed global queue. Changed paths can select code owners; deployment configuration can add a release owner; security-sensitive directories can require a second group. Prevent the agent that authored or orchestrated the change from satisfying its own human-approval condition.

After execution, retain GitHub actor, merge timestamp, resulting commit, merge method, branch, provider request ID, and protection status. If GitHub rejects the merge, close the execution attempt as failed and require a new decision after the repository state changes instead of replaying the old approval.

What good looks like

A narrow policy that can be tested in shadow mode, reviewed with owners, and promoted to enforcement with measurable impact.

• Match the concrete action "merge_pull_request" rather than every operation exposed by the tool.
• Scope the target to protected repositories and branches and the production environment.
• Require a request-bound approval that expires and cannot be reused.
• Record denied attempts as well as approved executions.

A production workflow

1. Copy the template and replace example identities and resource selectors.
2. Run it in shadow mode against representative requests.
3. Review false positives, missing resource attributes, and approver routing.
4. Enable enforcement for one agent and expand only after reviewing the decision log.

A policy you can test

GitHub merge approval policy is a concrete starting point, not a claim that one generic rule fits every environment. Replace example identities and selectors, validate the request shape, and begin in shadow mode.

name: github-merge-approval
match:
  tool: github
  action: merge_pull_request
  resource.branch: ["main", "release/*"]
decision: require_approval
approval:
  reviewers: ["codeowners"]
  expires_in: 15m

Endram keeps the policy version with every decision. A later change creates new evidence instead of rewriting why an earlier request was permitted.

Evidence to require

• Every attempted merge_pull_request, including denied requests.
• The exact protected repositories and branches selector evaluated by policy.
• The requesting agent, delegated user, reviewer, and timestamps.
• Policy version, matched rule, decision reason, and execution result.

Buyer checklist

• Does the selector cover only the intended production resources?
• Who owns the approval queue outside business hours?
• What is the acceptable approval expiry?
• Which emergency identity may bypass the rule, and how is that use audited?