GitHub Copilot Managed Telemetry Adds User and Device Attribution Without Prompt Capture

For any IT team that has been asked "which developer's agent ran that command on which machine?" and had to answer with a pseudonymous ID, this is a useful change. The data it collects is sensitive, though, so it deserves some planning before anyone switches it on.

What changed​

The new key is telemetry.capture.identity, set in Copilot's enterprise managed settings. When it's set to true, Copilot adds three attributes to its OpenTelemetry (OTel) data:

• user.name: the authenticated Copilot account name. GitHub says this is currently the GitHub login.
• process.user.name: the local operating-system account.
• host.name: the local machine name.

GitHub's enterprise managed settings reference says the setting has no effect on the existing pseudonymous enduser.pseudo.id attribute. You don't lose your current correlation data by turning on identity, and identity doesn't replace it.

Microsoft's VS Code documentation explains where these values land. When enabled, telemetry includes user.name on agent invocation spans, including subagent and inline chat spans, with process.user.name and host.name as resource attributes. That matters for queries. In most OTel backends, the account name sits on individual spans and the OS user and hostname sit on the resource, so your dashboards may need to join the two.

In short: identity capture answers "who, and on which machine?" while keeping the conversation itself out of your telemetry pipeline.

Five separate content switches​

GitHub has also split sensitive content into five classes that can each be turned on separately. GitHub's reference describes them as follows:

Two details are easy to miss:

• toolArguments and toolOutput are separate switches. You can record what an agent tried to run without recording what came back, or the other way round.
• Turning off policyDetail doesn't hide all policy data. GitHub says bounded policy posture, counts, outcomes and classifications stay available when this class is false. You lose only the raw, unbounded material, such as full sandbox path lists.

The new controls build on telemetry plumbing GitHub has been rolling out for months. A WindowsForum report on the September launch said that on September 22, 2026, GitHub added OpenTelemetry (OTel) support to the desktop GitHub Copilot app. The same report noted that the same managed telemetry control already covered VS Code, Copilot CLI and JetBrains IDEs. Until now, content capture was mostly a single on/off switch. These controls replace it with a set of separate settings.

In short: you can now collect the specific content an audit needs and leave the rest out.

Which clients support it​

Client support is uneven, and it's the part most likely to catch admins out.

GitHub says the fine-grained capture controls work in Copilot CLI, the GitHub Copilot app and VS Code sessions using Agent Host. GitHub's reference adds an important exception: VS Code's local agent harness supports capture.identity and the legacy captureContent setting, but it doesn't apply the five fine-grained classes separately. On the local harness, content capture is still all or nothing.

There is also a documentation mismatch to watch. Microsoft's VS Code monitoring page, as currently indexed, says identity capture currently applies only to the Local harness, and Agent Host telemetry doesn't include these identity attributes. Recent engineering work suggests that page is behind. A VS Code pull request dated October 1, 2026 says admins can already control identity capture for the Local harness, and the change applies the same policy to VS Code's own Agent Host telemetry, which is exported separately from the Copilot runtime. An earlier VS Code pull request on identity capture also mentions targeting the identity policy to version 1.140.

The practical advice is to test before you trust. Check identity attributes on the specific VS Code build and session type your developers use, rather than relying on any one documentation page.

How to configure it​

The settings sit in the telemetry object of your enterprise managed settings, usually in managed-settings.json. GitHub's reference lists these surrounding sub-properties:

• enabled: turns telemetry export on or off.
• endpoint: your OTLP collector URL.
• protocol: accepts "http/json" or "http/protobuf".
• capture: the new object holding identity and the five content classes, each defaulting to false.
• captureContent: the legacy shorthand (more on this below).
• lockCaptureContent, serviceName, resourceAttributes and headers.

The smallest configuration for attribution alone looks like this:

{
  "telemetry": {
    "capture": {
      "identity": true
    }
  }
}

Identity capture alone doesn't send anything anywhere. You still need to configure export. GitHub's fuller example turns export on, points to an OTLP endpoint, uses http/protobuf, and explicitly sets all five content classes to false.

A cautious rollout​

Based on GitHub's documented defaults and precedence rules, a careful deployment could go like this:

1. Set up an approved collector. GitHub's OTel documentation recommends a secure backend that supports OTLP, or an OpenTelemetry Collector in front of a backend that doesn't. If your collector requires an Authorization header, use HTTPS. GitHub warns that plain HTTP sends header values unencrypted.
2. Enable export with identity only. Turn on enabled, set endpoint and protocol, and set capture.identity to true. Leave the content classes off.
3. Check what arrives. In your backend, confirm user.name appears on agent spans and process.user.name and host.name appear as resource attributes. Test each client type you've deployed.
4. Add content classes only when needed. If an investigation calls for command history, enable toolArguments on its own before reaching for prompts or responses.
5. Review the full effective policy if you deliver managed settings through more than one channel (see below).

Precedence rules that can catch you out​

GitHub says explicit managed values override local settings, SDK configuration and environment variables. The VS Code documentation adds that managed identity capture also overrides COPILOT_OTEL_CAPTURE_IDENTITY, and managed resource attributes override OTEL_RESOURCE_ATTRIBUTES. Developers can't use an environment variable to get around a managed choice.

Two more rules matter:

• Managed telemetry objects don't merge. GitHub's reference says that if more than one managed source defines telemetry, the highest-precedence source supplies the whole managed telemetry object. Lower-precedence objects are ignored, not combined. If your MDM-delivered policy contains a telemetry block, a carefully built capture object in a lower-precedence file may never take effect.
• The legacy settings have limits. captureContent turns all five content classes on or off together, but it never enables identity. An explicitly set capture sub-property beats captureContent for that class. lockCaptureContent stops local settings from enabling a legacy content class, but GitHub's reference says it doesn't govern identity.

This matters for existing deployments. Many current configurations follow the older pattern, such as one community Grafana walkthrough that sets "captureContent": false, "lockCaptureContent": false alongside the endpoint and headers. Those configurations keep working. Adding identity is a separate, deliberate step.

In short: read the effective managed telemetry object, not just the file you edited.

The privacy trade-off​

GitHub is unusually direct about the risks. Its reference warns that captured content can include source code, file contents, prompts, commands, tool results, MCP identifiers, and paths to workspaces, user profiles or files that may contain secrets. Its advice is to enable only the classes your use case needs and send the data to an approved collector.

Identity-only capture isn't harmless either. A GitHub login combined with an OS account and hostname identifies a person. Microsoft's VS Code guidance is blunt: enable identity capture only when your organization has an appropriate purpose, access controls, and retention policy for this data.

There are reasonable arguments on both sides:

• For it: security teams investigating a risky agent action need to know who and which device, quickly. Identity-only capture gives them that without filling a log store with proprietary source code. Collecting the minimum is a better default than turning on captureContent because it was the only option.
• The worry: once per-user attribution exists, a security audit tool can easily turn into a productivity monitor. Organizations with works councils, union agreements or strict employee-monitoring rules should involve HR and legal before step 2, not after.

The setting itself is neutral. How you use it is a policy decision for your organization.

What it means for Windows and enterprise IT​

For Windows-heavy shops managing Copilot through Intune or registry-delivered policy alongside managed-settings.json, the non-merging precedence rule is the main thing to plan around. Decide which channel owns the telemetry block and keep it there.

The broader point is that AI coding agents now run commands, change files and call MCP servers on corporate endpoints. Admins can now answer "who and where" separately from "what was said", which fits the least-privilege approach security teams already apply elsewhere. For a feature that ships switched off, it covers a lot.