GitHub Copilot OpenTelemetry: Privacy-First Capture Plan

The production verdict

Use GitHub Copilot OpenTelemetry in two stages.

First, export operational signals and, when attribution is genuinely required, enable identity only. This can answer who used a supported Copilot client and from which local account or machine without deliberately copying prompt, response or tool bodies into the collector.

Second, open a time-bounded investigation tier only when a named incident question cannot be answered from metadata. Enable the smallest additional class that answers that question, route it to an approved endpoint, restrict access, set a deletion time, and prove the data disappeared afterward.

Do not turn on the legacy captureContent bundle for convenience. GitHub now exposes five independent content classes. A platform team should make five independent decisions.

GitHub's October 12 release is the important change. telemetry.capture.identity is separate from prompts, responses, tool arguments, tool output and policy detail. Every capture class is off by default. Managed values take precedence over local settings, SDK configuration and environment variables.

That makes the rollout decision clearer: define the audit question first, then admit only the data classes it requires.

What each switch can copy

The word telemetry sounds harmless because conventional application telemetry usually means durations, counters and error states. Agent telemetry can contain the work itself.

GitHub's current enterprise managed-settings reference describes six independent classes:

Identity is not anonymous. It is simply narrower than content. Host names and local account names may still be personal data or reveal internal naming conventions. Give the identity stream the same ordinary controls you would give authenticated developer activity.

The five content classes carry a different risk. Prompts and tool output can reproduce source files. Tool arguments can expose commands, repository paths, server names and identifiers. Policy detail can disclose workspace and profile locations. Responses can contain transformed copies of private input even when the original prompt was not retained.

The first architectural rule follows directly: do not send agent content into a general-purpose collector merely because that collector already accepts application traces. Its administrators, retention policy, indexing behavior, support exports, backups and downstream integrations may all be broader than the repository access model the content came from.

Write an audit question before a configuration

A capture plan should start with a question that can become false. “Improve observability” is not a question. These are:

• Which licensed users are actually starting agent sessions?
• Which client surface produces a repeated tool failure?
• Did a particular denied command originate from the expected policy path?
• Which session exceeded its safe-exit budget?
• Did the deletion job remove the investigation data by the promised date?

Map each question to the smallest evidence class.

For adoption and attribution, identity plus ordinary bounded metadata may be enough. For a repeated tool error, error classification and tool outcome may be enough before raw output is considered. For a suspected policy defect, start with bounded posture, counts, outcomes and classifications. GitHub says these remain available while policyDetail is false. Raw filesystem arrays should be the exception, not the baseline.

The plan should also name what the evidence cannot prove. A trace that shows a tool call occurred does not prove the action was authorized. A user name does not prove the named person approved every action in the session. A prompt and response pair does not prove the generated code was correct, reviewed or deployed. Telemetry is evidence about execution, not a substitute for admission, acceptance or production reconciliation.

This boundary matches our production observability decision guide: traces are useful only when the team knows which decisions they support and which controls live elsewhere.

Use a capture manifest, not a toggle

Retain a manifest before a pilot begins. The values below are illustrative, not a claim about a DVNC client deployment.

{
  "decision_id": "copilot-otel-identity-pilot-01",
  "audit_question": "Which approved users start sessions in the pilot group?",
  "harnesses": ["copilot-cli", "github-copilot-app"],
  "capture": {
    "identity": true,
    "prompts": false,
    "responses": false,
    "toolArguments": false,
    "toolOutput": false,
    "policyDetail": false
  },
  "collector": "https://otel.example.com",
  "access_owner": "platform-security",
  "retention_days": 14,
  "deletion_test_due": "2026-11-02",
  "release_terminal": "READY_FOR_SHADOW"
}

The manifest makes drift reviewable. If someone later enables toolOutput, the change cannot hide inside a broad telemetry diff. The new class needs its own purpose, owner and retention decision.

GitHub supports both capture and a legacy captureContent shorthand. The shorthand controls all five content classes together but never enables identity. An explicit class under capture takes precedence for that class. Set lockCaptureContent to prevent local configuration from reopening a legacy content path you intended to keep closed.

Also retain the complete managed telemetry object that actually won precedence. GitHub says objects from lower-precedence managed sources are not merged into the winning object. A reviewer who compares fragments from several sources may reconstruct a policy that no client ever used.

Test the plan before collecting data

I built a dependency-free capture-plan evaluator for this article. It accepts the required classes, client harness, collector approval, retention, access owner, content approval and deletion status. It returns either READY_FOR_SHADOW or BLOCK, plus the exact exposed data and reasons.

const CONTENT = [
  "prompts",
  "responses",
  "toolArguments",
  "toolOutput",
  "policyDetail",
];

export function planCapture(input) {
  const reasons = [];
  const requested = new Set(input.requiredClasses ?? []);
  const capture = Object.fromEntries(
    ["identity", ...CONTENT].map((key) => [key, requested.has(key)]),
  );

  if (!input.endpoint?.startsWith("https://")) {
    reasons.push("collector_must_use_https");
  }
  if (!input.approvedEndpoint) reasons.push("collector_not_approved");
  if (!input.retentionDays) reasons.push("retention_not_defined");
  if (!input.accessOwner) reasons.push("access_owner_not_defined");
  if (!input.deletionTested) reasons.push("deletion_not_tested");
  if (CONTENT.some((key) => capture[key]) && !input.contentApproval) {
    reasons.push("sensitive_content_not_approved");
  }
  if (input.useLegacyCaptureContent) {
    reasons.push("legacy_bundle_expands_capture");
  }
  if (
    input.harness === "vscode-local" &&
    CONTENT.some((key) => capture[key])
  ) {
    reasons.push("fine_grained_content_controls_not_supported_by_harness");
  }

  return {
    decision: reasons.length ? "BLOCK" : "READY_FOR_SHADOW",
    capture,
    reasons,
  };
}

The retained implementation also enumerates the concrete data exposed by each class. Its eighteen synthetic checks cover identity-only operation, unknown classes, HTTP endpoints, unapproved collectors, missing retention and ownership, untested deletion, content approval, legacy bundle expansion, harness differences and exact class isolation.

Eighteen passing checks prove the evaluator implements this policy. They do not prove a vendor collector deletes data, GitHub emits every expected signal, a user identity is accurate, or your organization has met a legal obligation. Those require customer-owned verification.

Respect the client and policy edges

Fine-grained capture is supported in Copilot CLI, the GitHub Copilot app and VS Code sessions using Agent Host. GitHub documents an important exception: VS Code's local agent harness supports identity and the legacy captureContent setting, but does not independently apply the five fine-grained content switches.

Do not publish one policy matrix and assume every client enforces it identically. Pin the pilot's client surfaces and versions. For any unsupported combination, block content capture or isolate it as a separate rollout with an explicit compensating control.

The managed-settings transport matters too. GitHub's October 13 enforcement update introduced forceRemoteSettingsRefresh. On supported clients, it can require a fresh settings fetch at startup and fail closed when current policy cannot be confirmed. Without it, the normal cache favors startup resilience during transient failures.

That is a real availability tradeoff. A security-sensitive change may justify blocking Copilot until fresh policy arrives. A routine identity-only pilot may prefer the ordinary cache. Decide by risk tier, and test startup with the collector available, unavailable and slow.

GitHub's September 22 Copilot app release says the app can route OTel through enterprise-managed settings and excludes prompt and response content by default. The default is a safe starting posture, not a complete programme. Local overrides, precedence, collector access and retention still need evidence.

Roll out from identity to investigation

Where telemetry programmes fail

• The audit question arrives after collection. The team gathers everything and hopes useful questions emerge. Reverse the sequence.
• Identity is called anonymous. A GitHub login, OS account and host name can identify a person or device. Govern them honestly.
• The legacy bundle becomes the default. captureContent turns five distinct risks into one switch. Use the granular classes where the harness supports them.
• A collector inherits excessive access. Repository content moves into a platform whose operators and exports were designed for metrics, not source code.
• Precedence is reviewed incorrectly. Managed telemetry objects are selected as complete objects rather than merged from every lower-precedence source.
• Harness differences are ignored. A policy that is granular in CLI or Agent Host may collapse to legacy behavior in the VS Code local harness.
• Freshness is assumed. A client may use cached settings unless freshness is required and successfully confirmed.
• Retention is asserted but never tested. Index expiry, object storage, backups and exports can disagree. Test the full path.
• Telemetry becomes acceptance. Traces show activity. They do not approve a command, validate a result or reconcile a deployment.

Frequently asked questions