A useful GitHub Copilot audit separates three questions: who has a license, how people use Copilot, and who changed settings or access. These have different data sources. Usage totals alone do not prove that only approved code was processed.
Start with read-only reports and keep existing security policies in place. In particular, allowing suggestions that match public code is not a remedy for an empty usage report.
1. Define what the audit must establish
Use seat-management data for licensing, usage metrics for adoption, and audit events for administrative changes. GitHub’s metrics overview explains why these resources are not interchangeable.
Write down the enterprise or organization, reporting period, intended readers and purpose before exporting data. For a cost review, do not substitute accepted lines of code for billing records. For a compliance review, do not describe an adoption dashboard as a complete file-access log.
2. Open the current usage dashboard
Open the enterprise, choose Insights, then Copilot usage. Access requires an appropriate role, such as enterprise owner or billing manager, or delegated metrics-viewing permission. The Copilot usage metrics policy must also be enabled. See the dashboard instructions.
If the page is missing, ask an administrator to check your reporting role and the metrics policy. Do not request enterprise ownership simply to read a report. If collection is intentionally disabled, treat enabling it as an approved governance change, not a troubleshooting shortcut.
3. Export a report with its actual date range
The usage dashboard provides NDJSON exports, rather than the universal CSV export described in older guides. Preserve the raw file and note when it was downloaded. For each comparison, record the dates actually covered, not merely the day you requested the report.
The field reference distinguishes aggregate, repository and per-user reports. Match your analysis to that report’s schema. A count of interactions is not a count of distinct people, and the absence of a breakdown entry is not proof of zero activity.
4. Use the current API without broadening access
The current latest enterprise aggregate report route is:
GET /enterprises/{enterprise}/copilot/metrics/reports/enterprise-28-day/latestThe API requires the enterprise’s Copilot usage metrics policy to be set to Enabled everywhere; have the policy owner verify that prerequisite. It returns report dates and signed download links, not the old inline usage array. Retrieve the linked report files through an approved client and protect both the links and downloaded data.
For this endpoint, classic personal access tokens and OAuth tokens require read:enterprise or manage_billing:copilot. The documented fine-grained token types are GitHub App user or installation tokens with read access to Enterprise Copilot metrics; do not assume an ordinary fine-grained personal token is supported at enterprise scope. Follow the endpoint’s current authentication requirements.
Use your organization’s approved credential process. Do not paste a token into a shared workbook, report, issue or command transcript. On a 403 or 404, check the account, endpoint, enterprise identifier and permission requirements before creating another credential. “All repositories” is not a substitute for the correct enterprise permission.
5. Investigate missing data without changing protections
Metrics are processed reports, not a real-time record. Check the latest completed date, supported client versions and telemetry coverage. Document unavailable data as unavailable. If telemetry is intentionally restricted, record that limitation instead of silently changing the policy.
Organization attribution follows membership, so a user can appear in several organization reports while being counted once at enterprise level. Do not add organization active-user totals to estimate unique enterprise users. These coverage details are documented in the metrics overview linked above.
Compare like-for-like periods and scopes. If a collection failure is suspected, save the HTTP status, request time and redacted response metadata for the administrator. Never include authorization headers or signed report URLs in a public support request.
6. Review audit events separately
In the enterprise’s Settings → Audit log, search action:copilot for Copilot plan, policy and licensing events. This requires enterprise ownership or the appropriate audit-log-reading role. The audit log does not contain users’ local Copilot prompts. GitHub documents a 180-day audit-event history; this is not a Business-versus-Enterprise usage-retention comparison. See Copilot audit logs.
If longer retention or additional session monitoring is needed, have the security team approve the destination, data fields and retention policy. That is a separate implementation, not evidence that every prompt is already available in the usage API.
7. Turn findings into a repeatable review
Keep a compact record of the question, source report, reporting dates, coverage gaps and conclusion. Separate confirmed administrative changes from inferred adoption trends. Discuss low activity with the relevant team before removing access; one incomplete report is not sufficient evidence of an unused license.
Store identifiable user reports only where authorized reviewers can access them. A scheduled read-only export can support future comparisons once its permissions and retention are approved, but the first audit should verify the meaning and completeness of the data before automating it.
Official documentation checked October 14, 2026.