Let coding agents review PRs without giving them unrestricted merge access WorkOS is offering early access to Airlock, a tool that authorizes specific GitHub merge actions for coding agents while keeping review credentials scoped to Contents: read and Pull requests: write. The guide instructs teams to route merges through Airlock, keep the Contents: write permission out of the review token, and pass the reviewed head commit SHA in the merge API request so GitHub returns a 409 Conflict if the PR changed after approval. It also recommends enabling GitHub's stale-review dismissal so a changed diff requires fresh approval. Let coding agents review PRs without giving them unrestricted merge access Set GitHub permissions for AI code review, govern merges with Airlock, and prevent agents from merging code that changed after approval. 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 https://workos.com/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 https://workos.com/airlock . 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 https://docs.github.com/en/rest/repos/contents get-repository-content to inspect repository files. - Pull requests: write https://docs.github.com/en/rest/pulls/reviews create-a-review-for-a-pull-request to submit reviews. GitHub's merge endpoint requires Contents: write https://docs.github.com/en/rest/pulls/pulls merge-a-pull-request . 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 https://workos.com/airlock 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 https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches 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 https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches require-pull-request-reviews-before-merging so a changed diff requires fresh approval. In the merge API request https://docs.github.com/en/rest/pulls/pulls merge-a-pull-request , include the ID of the reviewed head commit, called its SHA: { "sha": "