A Gate Is a Capability the Agent Does Not Have
A gate is a capability the agent does not have. Three verbs are structurally removed from GitHub Copilot cloud agent: it cannot approve its own pull request, it cannot merge one, and it cannot even mark one "Ready for review," per GitHub's risks-and-mitigations documentation. Not a policy asking the agent to wait for review, but an architecture in which advancing past review is an action the agent does not possess.
This is the most foundational decision gate in the section: every other gate (the author is never the approver, auto-approval graded by risk, scope discipline) sits behind it. A required approval must be something only a real person or a verified, separately built system can perform, and the performance must leave a record. Both halves matter. An approval the author can grant itself is not a gate. An approval that leaves no record is not evidence.
GitHub removes the verbs instead of trusting the agent to wait
The laptop model enforces review by convention: the engineer is supposed to get a review before merging, and branch protection backstops them. An agent producing dozens of changes a day needs the convention replaced with a boundary. GitHub's implementation is the cleanest published example of what that looks like in practice:
| Constraint | Mechanism |
|---|---|
| Agent can't ship its own work | Draft PRs "must be reviewed and merged by a human"; the agent "cannot approve or merge a pull request" |
| Requester can't rubber-stamp | The user who asked Copilot to create a PR is prevented from approving it, preserving the "Required approvals" rule |
| Agent can't escape its lane | Push access is limited to a single copilot/ branch; the agent "cannot directly run git push or other Git commands" |
| Untrusted input can't trigger work | Only users with write access can trigger the agent; comments from others are never presented to it |
| Side effects wait at the gate too | GitHub Actions workflows don't run until a person with write access clicks "Approve and run workflows" |
The second row is the subtle one. If the human who delegated the task could approve the result, author and approver collapse into one person with an agent in between, and the segregation-of-duties control is theater. GitHub extends this to automations: work from a scheduled or event-triggered run is attributed to the person who created the automation, and that person can't approve it either. See the author is never the approver for the general principle.
A verified system can act at the gate: Intercom cleared the bar
A system, not only a person, can act at the gate. Intercom auto-approves 19% of its PRs with no human in the loop. What makes their reviewer a verified system rather than a rubber-stamp LLM call:
- Piloted against outcomes. A controlled pilot of over 100 PRs produced zero reverts of AI-approved PRs and a 6–16x improvement in time-to-approval at the 75th percentile. In the first four weeks of broader rollout, 497 PRs went fully autonomous.
- Separate actor from author. Claude writes the code; an independent multi-sub-agent pipeline reviews it, with distinct sub-agents for intent alignment, safety, logical correctness, and best practices. See AI reviewing AI.
- It refuses. Refusal is what proves it gates: the agent "won't approve large PRs"; oversized changes are flagged and must be broken down. See scope discipline.
- Auditors confirmed it. Intercom engaged its auditors, Schellman, before scaling, and confirmed the process meets SOC 2, HIPAA, ISO 27001, ISO 42001, and AIUC-1 requirements.
Intercom's framing of the evidence requirement is the standard to hold: "The evidence an auditor expects to see is the same whether a human or an AI approved the change. The 'who' may change, but the 'what' doesn't."
The action at the gate must be recorded
Enforcement without evidence fails the audit half of the claim. Both systems treat the record as part of the gate itself. Intercom logs the review comments, the approval decision, the test results, and the merge event for every AI-approved PR, "labelled, logged, and queryable." GitHub signs the agent's commits so they appear as Verified, marks the initiating human as co-author, and links every agent-authored commit message to its session logs. An auditor reconstructing "who approved this and on what basis" gets an answer from the system, not from memory. The same artifact serves segregation of duties and the broader audit trail.
Escape hatches run toward more review, never less
Both published designs share one asymmetry worth copying. At Intercom, "any engineer can request a human review on any change, at any time. The system is a tool, not a mandate." At GitHub, the agent remains subject to whatever branch protections and required checks the repository already enforces. The opt-out always escalates scrutiny; there is no published mechanism in either system for a human to waive a required gate quietly. When branch protection blocks the bot itself, GitHub's answer is an explicit bypass-actor configuration, which is its own decision with its own record. See when branch protection blocks the bot.
One caveat from Intercom closes the case for gates: review, human or AI, was never a guarantee. The majority of Intercom's largest outages came from infrastructure, usage patterns, and third-party failures that no PR review would catch, and the product changes that did cause past outages "were all reviewed and approved by humans." The gate is necessary. It is not sufficient.