GitHub Enterprise Cloud now provides authorized enterprise administrators with a centralized inventory of credentials that can access an enterprise, along with an option to export that inventory as CSV. The feature is designed to support ownership reviews, access investigations, stale-credential analysis, and audit or rotation workflows without exposing the original token values.
The update matters because credential reviews often require more than a list of active secrets. Administrators need to understand who owns a credential, which organizations or applications authorize it, what permissions it has, and whether it still has a current relationship with the enterprise. GitHub’s inventory brings those details together through the web interface and REST API.
What changed
Eligible users can open enterprise Settings > Authentication security > Credentials to review the inventory and export it as a CSV file. The inventory covers fine-grained and classic personal access tokens, OAuth App user tokens, GitHub App user and installation access tokens, SSH keys, and federated credentials.
The inventory includes credentials currently authorized to access the enterprise as well as credentials owned by enterprise members that do not currently have enterprise authorization. Depending on the credential type, records can include identifiers, credential state, ownership and application details, authorization state, timestamps, scopes, permissions, repository selection, and authorized organizations.
The data is intentionally metadata rather than secret material. Original token values are not exposed. Some records can contain hashed token values, while SSH records can include fingerprints. Those values may help teams correlate inventory records with audit-log activity, but they should still be treated as sensitive operational data.
The GitHub announcement describes the inventory and CSV export capability as available for GitHub Enterprise Cloud. GitHub Enterprise Server support is planned for an upcoming release, but the supplied announcement does not identify a release number or date.
REST API access and filtering
For automation, the REST API exposes the inventory through GET /enterprises/{enterprise}/credentials. Administrators can filter results by token_types, authorization_state, owner, organization, and application. An individual record can be inspected with GET /enterprises/{enterprise}/credentials/{inventory_id}.
The list operation uses opaque cursor pagination through the Link header. Each request can return up to 100 results with per_page, and the API does not provide a total count. Consumers processing the complete inventory should therefore follow the returned cursors rather than assuming that the first response represents the full dataset.
Access is limited to enterprise owners and users with the fine-grained View enterprise credentials permission. The authentication requirements depend on the credential used to call the API: classic personal access tokens and OAuth App tokens require the read:enterprise scope, while fine-grained access tokens require read access to the Enterprise credentials enterprise permission. The REST API reference documents the available operations, filters, pagination behavior, and response fields.
How exports work
CSV exports are generated asynchronously rather than being returned immediately as part of a synchronous request. The API documents export retrieval through GET /enterprises/{enterprise}/credentials/exports/{export_id}. When an export is ready, the operation redirects to a short-lived download URL.
The supplied API reference does not expose the exact export-creation endpoint or its request parameters. That limitation does not prevent administrators from using the documented web interface, but teams building an automated export workflow should avoid assuming an undocumented request format.
The download URL is described only as short-lived. GitHub’s supplied documentation does not specify its exact validity period, retention policy, or detailed access-control behavior. Teams should handle downloaded CSV files as sensitive administrative data and define their own storage and access practices rather than relying on an undocumented retention window.
There is also an important distinction between API filtering and the CSV workflow. The REST list endpoint supports server-side filters, while the supporting administrative documentation discusses filtering the downloaded CSV rather than filtering the web export before it is created. The supplied sources do not independently confirm that the web interface provides pre-export filters.
Why the export matters for platform teams
The inventory can provide a more structured starting point for enterprise credential governance. Security and platform teams can use it to identify credentials with unclear ownership, review which organizations authorize a credential, examine permission and scope metadata, and locate credentials that no longer appear to have current enterprise authorization.
It can also support incident investigations and audit preparation. Inventory identifiers, hashed token values, and SSH fingerprints may help correlate credential records with audit-log activity where applicable. That correlation can help teams understand how a credential relates to enterprise activity without requiring GitHub to display the original secret.
However, CSV row counts should not automatically be treated as unique credential counts. A row represents a credential and authorizing-organization combination. If one credential is authorized for multiple organizations, it can appear in multiple rows. Any reporting or dashboard built from the export should account for that relationship before calculating totals.
The inventory is read-only. Reviewing or exporting records does not revoke, delete, or otherwise remediate credentials. Remediation takes place at the enterprise, organization, application, or user level, depending on the credential type. Revocation or deletion can disrupt users and automation, so an inventory finding should be treated as an input to a review process rather than an automatic instruction to remove access.
What you should do
- Confirm access. Verify that administrators who need the feature are enterprise owners or have the View enterprise credentials permission. For API workflows, use the documented scope or fine-grained enterprise permission appropriate to the authentication method.
- Start with targeted API queries. Use filters for credential type, authorization state, owner, organization, or application when investigating a specific risk area. Follow
Link-header cursors for complete results and do not depend on a total-count field. - Review metadata before taking action. Compare ownership, authorization, scopes, permissions, repository selection, timestamps, and organization relationships. Treat hashed values and SSH fingerprints as sensitive even though original token values are not exposed.
- Account for duplicate CSV relationships. When analyzing exports, distinguish unique credentials from credential-and-organization rows. A single credential can legitimately produce multiple rows.
- Protect exported files. The download link is short-lived, but its exact expiration and retention behavior are undocumented in the supplied material. Apply controlled storage and access practices to any downloaded CSV.
- Assess operational impact before remediation. Confirm ownership and dependencies before revoking authorizations or deleting credentials, particularly where automation may depend on them.
Availability and limitations
The documented product environment is GitHub Enterprise Cloud. GitHub Enterprise Server support is planned for an upcoming release, with no release number or schedule supplied. The feature provides visibility and export capabilities, not direct remediation, and the exact API request used to create an export is not included in the supplied reference.
For teams responsible for enterprise access reviews, the practical change is a more usable inventory of credential metadata across several credential types. The value comes from combining that inventory with careful filtering, audit-log correlation, ownership review, and deliberate remediation decisions.
