On November 5, 2026, GitHub added telemetry-gap and client-version fields to Copilot usage reports. A user can appear as active while their editor contributes no usage details. Administrators can now identify that condition explicitly instead of trying to infer it from empty breakdowns.
The BYOK reporting released on November 3 makes that gap a security concern. Treating missing BYOK entries as proof of approved-model use can clear a user whose activity was never fully reported. Identify the affected client and compare the usage evidence with its provider configuration before closing the review.
This guide proposes an evidence-handling procedure based on GitHub's documented behavior. General Analysis has not exercised it against an enterprise tenant. For the controls around the agent itself, start with securing coding agents.
Collect a settled day and keep its scope#
The new fields appear in enterprise and organization reports. User records carry the telemetry and version signals; aggregate daily records carry affected-user counts. In aggregate 28-day reports, those counts sit inside day_totals. Access requires an eligible administrative or metrics-reader role and an enabled Copilot usage metrics policy. See the November 5 release scope.
Use the Copilot usage metrics report endpoints with your approved reporting identity. Retrieve the per-user and aggregate exports for the same enterprise or organization and day. Preserve the raw downloads, collection time, scope, and file hashes in private storage. A failed download belongs in the collection record; it must not become an empty successful report.
GitHub allows two full UTC days after a reporting day closes for processing. Wait for that window before diagnosing missing telemetry. Record the report day separately from the download date so a fresh export cannot make an unsettled day look complete.
See how your AI systems hold up under real attacks
General Analysis maps AI applications and agents, red teams prompts, retrieval, tools, MCP servers, browser actions, permissions, and business workflows, then turns findings into evidence your team can reproduce and retest.
Keep receipt and version status separate#
The field reference defines two independent signals:
client_telemetry_presentdescribes whether qualifying client usage telemetry arrived for that user and day.truedoes not promise completeness.falsemeans server-side activity was recorded without qualifying client telemetry; it does not identify the cause.usage_metrics_requirementsclassifies identifiable IDE and extension components intomet,unmet, andunknown, using their last-known versions. It can be absent when no components are identified or when the record predates the field.
The schema examples also preserve null or omitted telemetry status, including users with only cloud-agent or code-review activity. Do not turn that unevaluated state into either a failure or a pass.
Use this decision table to assign follow-up work. The actions are our recommendations, not API-generated verdicts.
| Observed record | What to investigate | Conclusion to avoid |
|---|---|---|
Telemetry false; versions met | Client settings and the event delivery path | "Supported versions prove reporting works." |
Telemetry true; a component unmet | The named component and its last-known version | "Some events arrived, so every client is covered." |
| Telemetry null or absent | Report age, activity surface, and whether evaluation applies | "The user disabled telemetry." |
Version entries unknown | Device inventory and unrecognized or missing versions | "No failed minimum means all requirements passed." |
GitHub's troubleshooting guidance identifies disabled IDE telemetry, blocked delivery through a proxy or firewall, and unsupported clients as possible causes. Check those paths before assigning intent to a missing event. A user-level signal alone cannot identify which device needs repair.
Separate local BYOK from enterprise custom models#
The November 3 announcement distinguishes two routes. Developer-configured BYOK goes directly from the client to a provider or local model. Enterprise custom models are configured by administrators and route through GitHub. The first relies on client telemetry; the second is counted server-side.
A provider model's name cannot establish which route served it. Preserve is_custom_enterprise_model on each model entry inside totals_by_client. Earlier report days lack that classification; do not label them Copilot-hosted by default.
Local BYOK's used_local_byok and totals_by_local_byok cover the CLI and Copilot app. The BYOK field contract excludes IDEs from that local BYOK coverage. The word "local" describes configuration, not a guarantee that inference stays on the device: developer-configured remote providers are included.
Keep three questions in the review record:
- Was BYOK activity observed in a covered surface?
- Which provider and credential were configured for the relevant session?
- Did that configuration and its actual use comply with the organization's policy?
The report helps with the first question. Approved configuration, device records, and available provider logs address the others. Request only the evidence necessary to identify the route; do not collect the provider's secret key.
Preserve unknowns in the reporting pipeline#
The following illustrative projection labels two signals in already-downloaded per-user daily NDJSON. Keep the original file: the projection is a review aid, not a full schema validator or a security decision. The labels are ours.
Code source: illustrative, using GitHub's user-level example schema.
jq -c '
def signal($yes; $no):
if . == true then $yes
elif . == false then $no
elif . == null then "unavailable"
else "unexpected_value"
end;
{
day, enterprise_id, organization_id, user_id,
client_telemetry_present,
usage_metrics_requirements,
used_local_byok,
totals_by_local_byok,
telemetry_review: (
.client_telemetry_present
| signal("received_not_proven_complete"; "missing")
),
byok_review: (
.used_local_byok
| signal("observed"; "none_observed")
)
}
' users.ndjson
The projection intentionally treats null and omitted signals as unavailable. It retains the version assessment without converting an empty or unknown assessment into success. Reject unexpected values for investigation. Handle aggregate wrappers and duplicate user/day records upstream; do not feed them into this per-user projection. Empty input produces no rows, so the collection job must detect it separately.
For a hypothetical review, consider a row with telemetry false, all identified versions met, and used_local_byok: false. The output says missing and none_observed. It does not say "BYOK disabled." Ask the device owner to verify telemetry settings and delivery, then inspect the approved provider configuration for the relevant period. If those records were not retained, leave that historical question unresolved. Repairing collection now does not supply the missing evidence.
Reconcile counts without inventing a complete inventory#
Local BYOK totals are subsets of the CLI and app totals, while enterprise custom-model usage already contributes to totals_by_client. Adding those breakdowns to their parents double counts activity. GitHub also warns that local token totals can undercount when providers omit token usage. These are documented reporting limits, not evidence that an unexplained difference was malicious.
The two new affected-user counts can overlap. Keep missing telemetry and below-minimum clients as separate daily measures; do not add them to produce a unique affected-user population or add daily counts into a unique monthly total. The November 5 announcement explicitly warns against both operations.
GitHub's reconciliation guide explains why dashboards and exports can differ in scope, time window, and freshness. For this review, retain the source aggregate alongside the user-level investigation. A successful arithmetic reconciliation is useful, but it cannot establish that every device emitted every event.
Once the affected path reports as expected, retain the evidence and close its collection issue. The provider-policy review may still need configuration or usage records. For tool execution or downstream changes, follow the separate CLI metrics investigation and Copilot app OpenTelemetry procedure. Record any missing historical evidence in the decision instead of treating repaired telemetry as proof of past behavior.
Frequently asked questions
- Does client_telemetry_present true prove complete Copilot reporting?
No. It means qualifying client telemetry arrived for that user and day. It does not prove that every device, session, or local BYOK request reported. Keep client-version and collection evidence alongside the usage record.
- Does used_local_byok false prove that no external provider was used?
No. It means no local BYOK request was observed in the covered reporting signal. Local BYOK includes developer-configured remote providers as well as local models, and its telemetry can undercount. Enterprise custom models have a separate server-side classification.
