GitHub Copilot enterprise administrators can now attribute activity to a user without collecting prompts, responses or tool content, according to GitHub’s telemetry announcement. The control is telemetry.capture.identity in enterprise managed settings. Enabling it adds account, operating-system user and machine identifiers to OpenTelemetry data; sensitive content capture remains a separate decision.
For platform engineers, the practical question is how to make that separation hold across clients and configuration sources. The update introduces five independently configurable content classes, but client support differs, explicit managed values override local configuration, and competing managed telemetry objects do not merge. Those details determine what an enterprise policy actually captures.
What identity capture adds
WindowsForum’s account of the update and daily.dev’s summary describe setting telemetry.capture.identity to true to add three attributes to OpenTelemetry, or OTel, data:
| Attribute | Identity represented |
|---|---|
| <code>user.name</code> | The authenticated Copilot account; currently the GitHub login, according to GitHub as reported by WindowsForum |
| <code>process.user.name</code> | The local operating-system account |
| <code>host.name</code> | The local machine name |
These identify different parts of the execution context. An authenticated Copilot account and a local operating-system account are separate fields, alongside the machine identifier. Keeping those distinctions visible matters when interpreting attributed activity.
Identity capture is off by default. WindowsForum also reports that enabling it has no effect on the existing pseudonymous enduser.pseudo.id attribute. Named attribution therefore supplements that identifier rather than replacing it.
The operational implication is a narrower collection option: administrators can request named attribution without also requesting conversation or tool content. That still creates identifiable telemetry. Excluding prompts does not make account names, operating-system usernames or machine names anonymous.
Five content classes, five distinct choices
The content controls separate data that a broad content-capture switch would otherwise handle together. WindowsForum describes the following classes, with daily.dev also listing all five. Each is off by default and can be enabled separately on supported clients.
| Capture class | Content it can include |
|---|---|
| <code>prompts</code> | User, system and developer prompt text and associated model input, including supported attachments, compaction summaries, skill content and workspace context |
| <code>responses</code> | Assistant response text and supported reasoning content from the top-level agent and subagents |
| <code>toolArguments</code> | Raw tool arguments, commands, denied resources, process names, tool descriptions and schemas, and raw identifiers for MCP servers, plugins, hooks, servers and tools |
| <code>toolOutput</code> | Tool results and execution-error details from tools, hooks, MCP servers and subagents |
| <code>policyDetail</code> | Unbounded policy details, such as raw sandbox filesystem path arrays |
This breakdown matters because content extends beyond the visible chat exchange. Prompt capture can include workspace context and skill content. Tool-argument capture can include commands and identifiers, while tool-output capture can include execution errors. A policy that excludes prompts and responses can still request sensitive material through other classes.
policyDetail also has a specific boundary. According to GitHub’s reference as reported by WindowsForum, bounded policy posture, counts, outcomes and classifications remain available when that class is false. Disabling raw policy detail therefore does not remove all policy-related telemetry.
For administrators, the useful distinction is between attribution, selected content and broader capture. The controls allow these decisions to be made separately; they do not establish which combination is appropriate for a particular organization.
Managed values override local configuration
GitHub says explicit managed values override local settings, SDK configuration and environment variables, according to WindowsForum. Daily.dev likewise reports that managed settings take precedence over local configuration. An enterprise policy review consequently needs to examine the managed values rather than relying on a developer’s local choices.
There is a second precedence rule within managed configuration. WindowsForum reports that GitHub’s reference says managed telemetry objects do not merge: if multiple managed sources define telemetry, the highest-precedence source supplies the whole managed telemetry object.
The configuration implication is that separate managed sources cannot be assumed to contribute complementary pieces. A team assigning attribution in one source and content choices in another should review the complete object supplied by the winning source. The supplied evidence does not identify the ordering of those sources, so it does not support a universal recipe for determining which one wins.
For the transport setting, WindowsForum reports that the managed telemetry protocol property accepts http/json or http/protobuf. The evidence does not provide a complete verified configuration payload or collector setup, so these identifiers are configuration reference points rather than a copy-and-paste deployment example.
Legacy content controls leave identity separate
The existing captureContent setting remains available as shorthand for turning all five content classes on or off together, according to both secondary accounts. It never enables identity capture. An administrator seeking named attribution must configure telemetry.capture.identity separately.
lockCaptureContent has a different role. WindowsForum reports that GitHub’s reference describes it as stopping local settings from enabling a legacy content class, while excluding identity from its scope. It should therefore not be interpreted as a control over named attribution.
These distinctions matter when reviewing an existing policy. A broad content setting does not imply identity collection, and a legacy content lock does not determine the identity setting. Each needs to be evaluated according to its documented scope.
Client support changes the policy’s reach
According to GitHub as reported by WindowsForum, the fine-grained controls work in Copilot CLI, the GitHub Copilot app and VS Code sessions using Agent Host. Daily.dev reports the same coverage.
VS Code’s local agent harness is a separate case. WindowsForum says it supports capture.identity and the legacy captureContent setting, but does not apply the five fine-grained content classes separately.
For a deployment spanning these environments, the implication is that a selective capture policy needs a client-specific review. Support for attribution or the legacy switch does not establish support for independent control of prompts, responses, tool arguments, tool output and policy detail.
The update’s central benefit is the ability to separate named accountability from content collection. Its practical limits sit in configuration precedence and client compatibility. The available accounts describe the controls, but do not establish minimum client versions, a managed-source precedence ordering or a complete deployment procedure. Those remain implementation questions beyond what the supplied evidence can answer.
