GitHub Copilot Can Now Tie Telemetry to a User Without Collecting Prompts

GitHub Copilot has a new setting that separates two questions that enterprise telemetry has long conflated: who is using the assistant, and what exactly they are writing to it. The telemetry.capture.identity parameter in managed settings lets Enterprise administrators attribute Copilot activity to a specific user without collecting prompts, responses, or tool content. The parameter adds three configuration options. The published excerpt of the announcement cuts off the list, so the exact names and values are best checked against the original GitHub Changelog entry dated 12 October 2026.

What exactly has changed

Until now, companies rolling out AI assistants for developers faced an awkward choice. They could collect telemetry in anonymized form and not know which employees actually use the tool. Or they could enable detailed collection, where the logs capture prompt text, code fragments, and tool-call results alongside attribution. In the second case, the telemetry store may end up holding everything a developer showed the model: internal APIs, client names, pieces of non-public logic.

The new setting moves identity onto a separate axis. An administrator can keep the link between an event and a user without receiving the content of the interaction. The configuration is set centrally through managed settings, so developers do not toggle it locally.

Why companies need it

Attribution without content covers several typical enterprise rollout tasks:

• license accounting: you can see which of the purchased seats are actually in use and which sit idle;
• effectiveness measurement: activity can be matched to teams and projects without reading the conversations themselves;
• incident investigation: when a client behaves anomalously, it is clear which user's device it came from;
• compliance with internal policies: the security team does not need to store code and prompts to answer the question "who did what, and when."

There is also a separate regulatory argument. For European companies, personal data in telemetry and the content of work conversations usually fall under different regimes for agreement with employees and trade unions. When identifier collection is separated from text collection, it is easier to justify: the purpose is clear and the volume of data is limited.

What remains unclear

The announcement, in the form available, does not disclose a number of details. It is unknown which three options telemetry.capture.identity offers, or in what form the identifier is stored: as a login, an internal ID, or a hash. The text also does not say which Copilot clients the setting applies to or how it interacts with existing content-collection parameters. These points determine how suitable the setting is for strict policies, and they should be checked before enabling it.

What administrators should do

The practical sequence looks like this:

1. Read the full GitHub Changelog entry and the managed settings documentation, and record all three values of the parameter. 2. Define the purpose of attribution: license accounting, security, or productivity analytics. The purpose determines the choice of mode. 3. Agree on its use with legal counsel and employee representatives. A user identifier remains personal data even when there are no prompts in the logs. 4. Verify on a pilot group that content really does not reach telemetry, for example by inspecting actual events in the log receiver. 5. Set a retention period and define who can access the data: attribution on its own makes it possible to build activity profiles.

The takeaway for the market is pragmatic. Enterprise AI assistants are increasingly chosen for control over data, not only for model quality. Being able to answer "who is using it" without answering "what did they write" removes one of the security team's frequent arguments against broad rollout.