Let AI Coding Agents Review PRs Without Granting Unrestricted Merge Access

AI coding agents are rapidly becoming part of everyday software development workflows — from generating code to reviewing Pull Requests (PRs), they're taking on an ever-growing set of responsibilities. But a core tension has emerged: teams want AI agents to help review code and speed up the evaluation process, yet aren't comfortable handing over unrestricted merge permissions. This article explores a framework for constraining AI agent behavior through GitHub permission controls and an Airlock governance mechanism.

Why You Can't Just Give AI Agents Merge Permissions

Merging code into the main branch is a high-risk operation. If an AI agent holds unrestricted merge permissions, it could push code into production branches without adequate human oversight. Even more concerning is a specific risk: code being modified after it's already been approved.

Imagine this scenario — a PR passes review and gets approved, but then someone (or another agent) adds new commits to that branch. If an AI agent simply treats the "approved" status as sufficient and triggers a merge, the code that actually gets merged is no longer the same code that was reviewed and approved. This kind of "post-approval tampering" is a common entry point for supply chain attacks and accidental errors.

The key to involving AI agents in code review, therefore, isn't about whether to grant permissions at all — it's about how to draw the permission boundaries precisely, decoupling review capabilities from merge capabilities.

---

Supply chain attacks have become one of the most significant threats in software security in recent years. The 2020 SolarWinds incident is a prime example — attackers injected malicious code into the build pipeline, ultimately affecting tens of thousands of downstream users. In the context of AI agents participating in code review, "post-approval tampering" creates a similar attack window: a malicious actor can deliberately push a seemingly harmless commit to a branch after the PR is approved but before the agent executes the merge, smuggling harmful code into the main branch. Because this window is extremely brief, manual review often fails to catch it. This is precisely why after-the-fact auditing isn't enough — you must technically enforce snapshot consistency before the merge action is triggered.

Using GitHub Permissions to Fine-Tune the AI Review Role

The first layer of defense is configuring permissions at the GitHub level. The core idea is to give AI agents only the minimum permissions required for code review, without granting the ability to write directly to or merge into the main branch.

Typical approaches include:

• Creating a dedicated identity for the AI agent (such as a GitHub App or a dedicated account), rather than reusing a human developer's high-privilege credentials
• Using branch protection rules to restrict who can merge into protected branches
• Allowing the agent to submit review comments and start discussions, while reserving the "final merge" action for humans or a controlled automated process

This way, even if an AI agent determines that a PR "looks fine," it cannot complete the merge on its own — it must pass through an additional governance checkpoint.

---

GitHub Apps are the recommended approach for establishing an independent identity for AI agents. Compared to Personal Access Tokens (PATs), GitHub Apps have their own distinct identity, fine-grained repository permission scopes, and support installation at the repository level. Permissions can be precisely controlled to "read-only content + submit Pull Request Reviews" without granting any write or merge capabilities. Branch Protection Rules are another critical line of defense: administrators can require that merges pass a certain number of required status checks, a specified number of human approvals, and options like "Require approvals from code owners." These rules are enforced server-side — even if an agent technically has write access on the client side, it cannot push code into a protected branch without satisfying the protection rules. Together, even if an AI agent's credentials are compromised, the attack surface is limited to review-level permissions, not full write control over the repository.

Airlock: A Governance Checkpoint for Merge Actions

The source material specifically highlights using Airlock to govern merges. Airlock acts as a controlled isolation layer between approval and actual merging — true to its name, it inserts a managed barrier between the two stages.

The value of the Airlock mechanism manifests in two key ways:

Enforcing Code State Verification After Approval

The most important rule is: prevent the agent from merging code that has changed since it was approved. In other words, Airlock verifies that the code currently awaiting merge is identical to the code that was reviewed and approved. If any changes are detected after approval, the merge is blocked and the PR must go through review again.

This directly closes the "post-approval tampering" vulnerability described earlier, ensuring that "what was reviewed is what gets merged."

Keeping Automation Within Controlled Boundaries

Through a governance layer like Airlock, teams can let AI agents handle the tedious work of reviewing code and providing feedback, while bringing critical merge decisions under a unified policy engine. This preserves the efficiency gains from automation without allowing agents to overstep their authority.

---

Airlock takes its name from the "airlock chamber" concept used in aerospace and biosafety contexts — before entering the next environment, you must pass through a controlled intermediate state, with both doors never open simultaneously. Similar mechanisms appear elsewhere in software supply chain security: the SLSA (Supply-chain Levels for Software Artifacts) framework requires verifiable provenance at every step from source code to release; GitHub's native "Required Deployments" and third-party Policy-as-Code tools (such as OPA/Conftest) can also inject validation logic before merges. The core value of Airlock is decoupling "approval" from "execution" in both time and logic: an approval records that a specific code snapshot has been sanctioned, while execution must re-verify that the current code matches that snapshot — preventing man-in-the-middle attacks or race conditions that lead to the security flaw of "approving A, merging B."

What This Approach Means for Your Team

From an engineering governance perspective, this framework communicates a clear principle: capability grants should follow least privilege, and sensitive operations should have independent checkpoints. The trend of AI agents entering the development workflow is irreversible, but "trust but verify" remains the baseline.

For teams evaluating AI code review tools, consider these dimensions:

• Can the agent's identity and permissions be independently configured and audited?
• Is it possible to enforce mandatory verification between approval and merge?
• Can the system detect and block subtle risks like post-approval code changes?

It's worth noting that the original source material is fairly concise — it proposes a framework rather than a detailed implementation tutorial. Actual deployment will require adapting to your team's specific CI/CD pipeline, branching strategy, and the capabilities of the tools you've chosen.

Summary

AI agents reviewing PRs are an effective way to boost development efficiency, but merge permissions must be handled with care. By configuring least-privilege access at the GitHub level and adding an Airlock-style governance checkpoint to enforce post-approval code consistency, teams can enjoy the benefits of automation while maintaining code security as a hard floor. The core insight is to separate "reviewing" from "merging" — let the agent do the reading, but let a controlled mechanism make the final call.