The problem: commit identity is self-reported
Rulesets already let administrators control things like who can push to a branch and how commits must be formatted. Until now, nothing in a commit's own metadata could prove who sent it. GitHub's announcement says the author and committer fields are strings supplied by the pushing client. Anyone with write access can therefore set them to any name and email. GitHub's stated worry is an attacker who compromises a low-privilege account and forges commits that appear to come from a trusted maintainer. That could slip past review policies and muddy audit trails.
GitHub already authenticates every push. What it didn't do was durably attach that authenticated identity to each commit in a way you could see afterward.
What the preview adds
According to the GitHub changelog post of October 12, 2026, there are two pieces:
- Durable pusher identity. Each commit pushed to a repository gets an authenticated pusher identity attached to it. It is independent of whatever the author and committer metadata claims.
- A new rule condition, "Committer must match pusher." It blocks a push when the committer metadata doesn't match any verified email address of the authenticated pusher. GitHub says this closes one path for commit identity spoofing. To use it, you add the rule to a ruleset.
GitHub also says the pusher identity is visible in the UI and API wherever commits are shown. It positions this as a way to spot-check suspicious activity and speed up investigations without relying on unverified metadata.
Who can get it
This is not a general rollout. GitHub describes it as a limited public preview for GitHub Enterprise customers. Interested customers are told to contact their account team and ask for access. The announcement gives no date for wider availability. It also doesn't say which Enterprise plans or deployment types are covered, what the API fields are called, or which UI locations show the pusher.
What the rule does and doesn't check
Precision matters here, because the rule's wording is narrow.
- It compares the committer metadata against the verified emails of the authenticated pusher.
- It does not, as described, require author, committer and pusher to all be the same person.
- It does not prove who wrote the code. A forged author field is not covered by the rule as described.
Think of it as a bouncer checking that the name on the wristband matches a name on the guest's ID. It says nothing about who baked the cake.
Why this won't be a clean switch-on
Legitimate workflows often have different people or systems in the pusher, author and committer roles:
- A maintainer pushing a contributor's patch.
- A bot or automation pushing commits.
- A mirror re-pushing existing history.
A 2025 NDSS Symposium paper on GitHub activity found that in the sampled data only about 30% of commits had one account as author, committer and pusher. Its authors cite bots and mirrors as examples of legitimate differences. Those figures describe that study's dataset, observed in 2024. They are not a measurement of this feature or of all GitHub repositories. Still, they suggest a mismatch between roles is a poor sign of compromise on its own. It is an investigative signal, not a verdict.
The announcement also doesn't document how the rule treats bypass lists, GitHub-generated commits, bot identities, deploy keys or multi-author commits. GitHub's general ruleset documentation says bypass can be granted to roles, teams or GitHub Apps. It doesn't say how that applies to this new condition. I couldn't find the new condition in the public documentation I reviewed, so treat the changelog as the only authority on its behavior for now.
Practical guidance for Enterprise admins
If you get preview access:
- Look before you enforce. Use the pusher identity in your commit views during incident reviews. Compare it with author and committer on anything that looks odd.
- Inventory unusual workflows. Find any process that pushes commits carrying someone else's committer email. These are the ones most likely to be blocked.
- Pilot the rule on a limited set of repositories. Check how it treats automation and your bypass settings before widening it. Don't assume behavior GitHub hasn't documented.
- Keep the other controls. Write-access hygiene, code review and signed commits still matter. This is an identity-integrity control, not a replacement for any of them.
The bigger picture
Git was designed around a trusting, distributed model where identity strings are labels, not credentials. Hosting platforms have gradually layered verification on top, such as signed-commit badges and account-level rules. Recording the authenticated pusher is a sensible extension, because the host is the one party that definitely knows who authenticated.
The open questions are scope and edge cases. A preview limited to Enterprise customers, with undocumented exceptions, means most teams can't rely on it yet. The idea is sound and the audit value is real. Whether the enforcement rule is practical will depend on how it handles bots, mirrors and delegated workflows.