Let coding agents review PRs without giving them unrestricted merge access

Coding agents can take work off your team's PR queue, but an overly broad GitHub token can also let them merge code they were only asked to review. This guide shows how to set up review access, use Airlock to authorize specific merges, and ensure the code being merged is the revision someone approved.

WorkOS Airlock checks each proposed action against the agent's task and your policies, asking a person to approve when the rules require it. It is in early access if you want to try it with your coding agents.

Start with a credential that can review

For an integration that reads repository files and submits PR reviews, use a GitHub App token or fine-grained personal access token scoped to the required repositories:

• Contents: read to inspect repository files.
• Pull requests: write to submit reviews.

GitHub's merge endpoint requires Contents: write. Keep that permission out of the review credential. Check the shell environment too: an authenticated gh client or another token can give the agent a separate route to write access.

Make a merge a separate assignment

If you want the agent to merge, authorize that work explicitly for a particular repository and PR. Route the action through Airlock and keep the merge credential behind that governed execution path.

Airlock's published GitHub example combines passing CI, an approved review, and a small change scope. Changes to authentication, billing, or migrations require code-owner sign-off. Adapt those conditions to your repository: a two-line change to an authorization check can deserve more scrutiny than a large documentation edit.

For the same otherwise eligible PR, a review-only assignment should produce feedback; an explicit merge assignment can proceed once its conditions are satisfied. Keep GitHub's required checks and reviews enabled, with no bypass for the agent's identity. GitHub must still accept the merge after Airlock allows the action.

Merge the code that was reviewed

A PR can change after approval. If someone pushes another commit, the agent needs to check the updated code and obtain any required approval again. Enable GitHub's stale-review dismissal so a changed diff requires fresh approval.

In the merge API request, include the ID of the reviewed head commit, called its SHA:

{
  "sha": "<reviewed-commit-id>"
}

GitHub returns 409 Conflict if that ID no longer matches the PR's latest commit. Recheck the updated code before retrying. Automatically substituting the new ID would defeat the check.

Try it in a test repository: approve a PR, push another commit, then attempt the merge using the original commit ID. Expect a conflict and no merge. Our policy-testing guide covers more cases.

Try Airlock in early access to control which GitHub actions your coding agents can take on your behalf.