GitHub Adds a Third Identity to Commits: Who Actually Pushed

GitHub has started durably recording the authenticated user who performed a push, and it now shows that identity in the UI and API alongside the existing author and committer fields. The feature is called push attribution and is currently in limited public preview. The announcement was published in the GitHub Changelog on October 12, 2026. Every commit now carries three identities instead of two, and one of them is verified by the platform.

What exactly changed

In git, the author and committer fields are filled in on the client side. Their values come from the local config or environment variables, and nothing prevents anyone from setting someone else's name and email. GitHub maps these addresses to accounts and can mark a commit as Verified if it is signed, but far from every commit is signed. Until now, the fact of "who pushed this to the repository" could only be reconstructed indirectly in the public history, for example through repository events or audit logs.

Push attribution closes this gap. The platform knows who authenticated during the push and now stores that information as part of the commit data. The pusher field appears in the UI and is available through the API.

Why this matters in the age of agents

The announcement does not spell out the motivation in detail, so what follows is engineering logic, not GitHub's claims. A typical commit today passes through several hands. The author may be a developer, the committer changes during a rebase, squash or cherry-pick, and the push itself comes from a service token or an AI agent acting on the user's behalf. The three fields give three different answers to the question "whose code is this?"

For incident investigations and security reviews, the distinction is critical. If a malicious or simply broken commit lands in a branch, the author in the metadata proves nothing. The pusher shows whose credentials were used to deliver it. For organizations with compliance requirements, it is also a way to tell human work from automation without manually cross-checking logs.

What is known and what is not

• Status: limited public preview, announced on October 12, 2026
• New value: pusher, meaning the authenticated user who performed the push
• Where it appears: the GitHub UI and API, next to author and committer
• Data source: server-side authentication, not the client's git config
• Not disclosed in the announcement: pricing, the list of eligible accounts and organizations, behavior for older commits, the exact format of the field in REST and GraphQL, and how GitHub Apps and bots are represented

The last item is the most interesting. The practical value of the feature for anyone building automation around repositories depends on how the field will represent apps and agents.

What teams should check now

While the feature is in preview, it is too early to build it into critical processes, but you can prepare. First, find out whether the preview is available to your organization and test it on a non-critical repository. Second, check which integrations push to your code: personal tokens, GitHub Apps, CI runners, agents. That determines what you will see in the pusher field. Third, if you have audit scripts that currently assemble "who pushed" from events and logs, assess whether you can replace them with API queries once the field format stabilizes. Finally, do not give up on commit signing: pusher tells you who delivered the code, but it does not prove who wrote it.