Copilot license and repository accounts can now differ: keep attribution intact

Many developers work with more than one GitHub identity: an enterprise account that carries the company's Copilot license, and a personal or other organisation account that holds the repositories they work on. Until recently the tools assumed one account did both, which pushed people towards sharing or switching accounts in awkward ways. In the first half of October 2026 GitHub changed that in the Copilot app and in VS Code, and in the same fortnight shipped two features that matter for the follow-on question: when one person uses two accounts, how do you still know who did what?

The context: what changed

GitHub's weekly Copilot update of 9 October says the Copilot app now lets you use separate GitHub accounts for your Copilot license and your repositories, for example an enterprise-provided license alongside repositories reached through another account.

The VS Code 1.141 release notes, dated 7 October, solve a related problem. Many organisations use Copilot through a GHE.com account but keep their code on GitHub Enterprise Server, and the old github-enterprise.uri setting held only one instance. The new github-enterprise.uris setting takes a list of GHE.com and Enterprise Server instances, labels each account with its host, and asks which instance to use at sign-in. Support varies by extension: the GitHub Pull Requests extension uses one Enterprise account at a time, for instance.

Two further changes landed on 12 October:

• Telemetry attribution. The client telemetry changelog adds a telemetry.capture.identity managed setting that puts three attributes on Copilot's OpenTelemetry data: user.name (the authenticated Copilot account, currently the GitHub login), process.user.name (the local operating-system account) and host.name (the machine). It is off by default and separate from content capture. Five content classes, from prompts to tool output and policy details, are each off by default and controlled independently. These controls apply in Copilot CLI, the Copilot app and VS Code sessions using Agent Host.
• Push attribution. The push attribution changelog says GitHub now records the authenticated user who pushed each commit, alongside the author and committer fields, and adds a ruleset condition, Committer must match pusher. This is a limited public preview for GitHub Enterprise customers, available on request.

Analysis: what to make of it

Less account sharing is a security gain

When a tool insists that one account does everything, people work around it: they sign in to a personal account with company Copilot, or reach company code from a personal account, or share credentials. Each workaround blurs who is acting and under which policy. Letting the license account and the repository account differ removes a reason for those workarounds. That is a real improvement, even though the feature itself is about convenience.

But identity now has more parts

After the change, one developer's AI-assisted change can involve four identities: the Copilot account whose license and policies apply, the repository account that reads code and opens pull requests, the operating-system account on the machine, and the person. Audit questions such as "who ran this agent session against that repository" now need those parts joined. Separate accounts are not a security boundary in themselves; they are separate records that someone has to correlate.

Commit metadata was never proof

The push attribution changelog says it plainly: author and committer fields are strings the client supplies, and "anyone with write access to a repository can set them to any name and email they choose." That has always been true, but agents that commit on a developer's behalf make it more relevant. A durable, authenticated pusher identity is the field to rely on where it is available, and the Committer must match pusher rule turns the check into enforcement. Both are preview, and only for GitHub Enterprise customers, so plan accordingly.

Attribution without content

The telemetry change separates two decisions that are often bundled: knowing who used Copilot on which machine, and seeing what they typed. Identity capture can be on while every content class stays off. That makes per-person attribution possible without collecting prompts or code, which is usually the right default. The changelog's own caution applies to content capture: prompts, tool arguments and policy details can contain source code, file contents, commands and paths. The decision about content is covered in capturing prompts in AI telemetry.

What it means for engineering and security leaders

Decide which identity is authoritative for each question. For licensing and AI policy, it is the Copilot account. For repository access and code changes, it is the repository account and, where available, the authenticated pusher. For investigation, it is the person, reached through the operating-system user and host that telemetry can now carry. Write that mapping down before you need it.

Then check that the records exist. Identity capture is off by default, so attribution in OpenTelemetry data appears only if an administrator turns it on through managed settings. Push attribution is opt-in preview. Without them, the join between a Copilot session and a commit relies on unverified metadata.

Practical takeaways for this week

• Tell developers that separate license and repository accounts are now supported in the Copilot app, so there is no reason to share or switch accounts.
• Where Copilot comes through GHE.com and code lives on Enterprise Server, move from github-enterprise.uri to github-enterprise.uris.
• Decide whether to turn on telemetry.capture.identity in managed settings, and keep content classes off unless an audit use case needs one.
• If you are a GitHub Enterprise customer, consider requesting the push attribution preview and testing the Committer must match pusher rule on one repository.
• Document which identity answers which audit question.

Where SpanDock fits

SpanDock keeps a per-computer identity of its own. Each client is paired with a single-use code, and the first computer to use it becomes that client, named after the computer. As the privacy page puts it, every client sees only its own data, and the client's identity always comes from its authenticated connection, never from the request. That gives a machine-level record of which computer's AI tools sent which sessions, independent of the GitHub accounts in use.