A Blocked Merge Is Governance Working: Fix It With Identity, Not a Bypass

A blocked merge is a governance control doing its job against an actor that arrived without a proper identity. Three threads on GitHub's community forum between October 2025 and April 2026 made the same complaint in three costumes: branch protection was blocking an AI agent. Unsigned commits no one could merge. Squash merges that handed authorship to Copilot. An approval rule that locked out the one person who wanted to approve. None of these were bugs.

The control collides with the agent because the agent has the wrong identity, not because the control is wrong. The threads below show what each collision actually encodes, and why the durable fix is always identity, never exemption. The same controls show up as design principles elsewhere in this section: agent identity, binding to the human, and author-never-approver.

Unsigned commits: provenance, enforced at the merge button

In October 2025 a platform engineer reported that Copilot coding agent's commits were unsigned, and the impact line is worth quoting whole: "The agent can create a PR, but no one can merge it because the commits are unsigned and the ruleset applies organization-wide" (#175965). The org's signing requirement did not know or care that the author was an agent. It asked for a verified key; the agent had none.

The resolution was not to relax the rule. It was to give the agent a key. GitHub shipped commit signing for the agent in April 2026; signed commits now show as "Verified," and GitHub's own risk documentation frames this as audit infrastructure: confidence the commits came from the agent and were not altered, with each commit message linking to the session log. Cursor reached the same answer independently: cloud agents sign every commit with an HSM-backed Ed25519 key, and PRs satisfy signed-commit branch protection with no configuration.

Squash-merge authorship: git blame is an accountability record

A month later, #179983 asked: "Is there a way to ensure that when merging Copilot-created PRs, the person who requested the work becomes commit author, while still acknowledging Copilot's contribution?" Squash merging promoted Copilot to sole author, which the poster said "distorts git blame, contribution history, and team accountability." Eight comments, twelve participants, and as of our June 2026 research pass, no accepted answer. Adjacent reports describe org-level committer-domain checks broken by the agent's random *[email protected] address.

GitHub's intended model is sound: the agent authors the commit, the human who assigned the task is co-author, so AI-authored and human-initiated are both visible in the record. The squash button silently discards half of that pair, and the half it keeps is the one with no legal accountability. That is the attribution problem from agent identity and binding to the human, surfacing as a merge-strategy setting.

The requester can't approve: four-eyes meets a team of one

The third thread is the sharpest. #179997 reports that PRs the agent opens "on behalf of" user X prevent user X from approving them, quoting GitHub's constraint message: "Approvals from users that collaborated with Copilot on changes will not satisfy review requirements." The poster asks for an option to disable it.

GitHub built this deliberately. Its documentation says the restriction "maintains the expected controls in the 'Required approvals' rule," and extends it to automations: scheduled agent runs are attributed to the automation's creator, who then cannot approve the resulting PR. This is the author-never-approver principle and SOC 2 segregation of duties, enforced in product. The user on the other end experiences it as a defect, because a solo developer plus an agent is a review team of one. Our venue research found this pattern everywhere: nobody types "segregation of duties" into a forum; they type "Copilot PR cannot be approved." (A sibling thread, #172019, hits the same wall via the "require approval of the most recent reviewable push" rule.)

The wrong fix is a bypass

GitHub's documented workaround for incompatible rulesets is to add Copilot as a bypass actor. That unblocks the agent by exempting it from the control entirely, which is precisely backwards: the actor producing the most volume becomes the one your rules no longer see. The right fix in every one of these collisions is an agent identity rich enough to satisfy the control: a signing key for provenance, a distinct author bound to an initiating human for attribution, and an approver who is not the requester, whether that means a second human or a separate review gate.

One gap: this corpus covers GitHub and Cursor. The field is effectively silent on how GitLab, Bitbucket, and other hosts handle the same three collisions, so treat the pattern, not the vendor specifics, as portable.