GitHub has introduced server-to-server authentication for applications built with the Copilot SDK, giving automated workloads a way to access Copilot without relying on a signed-in developer’s credentials.
The feature, released in public preview on October 27, uses a GitHub App installed on an organization. The app obtains a short-lived installation token, and Copilot usage is attributed and billed to the organization that owns the installation. The organization’s model policies, budgets and spending controls also apply to requests made by the app.
This changes the operational model for teams embedding Copilot in internal services, repository automation or customer-facing developer tools. Authentication can now represent the workload itself rather than whichever employee happened to authorize it.
From user credentials to application identity
Many agent integrations begin with a personal access token or another credential tied to an individual developer. That can be convenient during a prototype, but it creates problems when the integration becomes a persistent service. Employees change roles, credentials expire or are revoked, and audit records can make automated activity look like human activity.
GitHub’s new path uses an installation token issued to a GitHub App. Installation tokens are short-lived and scoped through the app’s installation and permissions, making them better suited to unattended workloads than a long-lived user credential.
The distinction matters for governance. An organization can identify the application responsible for Copilot consumption instead of attributing every request to a nominal operator. GitHub includes an app_client_id field in AI usage CSV reports, allowing owners to separate app-originated usage during analysis.
For teams building an AI API control plane for developer teams, this is a useful identity pattern: human users, automation accounts and deployed applications should not share indistinguishable credentials or billing records.
Billing follows the organization
Requests authenticated this way consume the organization’s Copilot allowance and are governed by its existing model policies, budgets and spending controls. That gives administrators one place to decide which models an application may use and how much aggregate AI spending the organization will permit.
It also means application owners cannot treat server-to-server access as an independent pool of capacity. A busy integration can draw from the same organizational budget as other eligible Copilot activity. Teams will need to monitor automated consumption alongside interactive use and decide how incidents, retries and unexpected request loops should affect shared limits.
The current preview does not support a separate budget for each app or installation. The app_client_id field can help with retrospective attribution, but reporting by application is not equivalent to enforcing a hard application-specific ceiling. Organizations that need isolation may still require their own metering layer or AI API spend controls for teams in front of automated workloads.
What developers need to change
Developers adopting the feature must create a GitHub App, install it on the relevant organization and exchange the app’s credentials for an installation token. The application then uses that short-lived token when calling through the Copilot SDK. Deployment systems must therefore handle token issuance and renewal rather than storing a static developer token indefinitely.
Operational records should preserve both the GitHub App identity and the organization charged for each request. That is especially important for platforms serving multiple organizations: a token issued for one installation must not be reused to route another customer’s workload, and usage exports should be reconciled against the correct tenant.
The model also affects offboarding. Removing one developer no longer has to disable an organization-owned integration, while uninstalling the GitHub App or changing its permissions provides a more direct control over the application itself. The practical result is a cleaner separation between workforce identity and workload identity.
The remaining limits
Server-to-server authentication is still a public preview, so GitHub may change its contract before general availability. GitHub has not announced support for enterprise-level installations or personal accounts through this authentication path.
The lack of per-app budgets is the most immediate control gap. Organizations can see which app generated usage, but they cannot yet assign each app or installation an independent Copilot budget. That becomes more significant as companies deploy multiple coding agents, review services and repository automations under one organization.
Even with that limitation, the release establishes a clearer ownership model for machine-generated Copilot traffic. Authentication, policy and billing now attach to an installed application and its organization, creating a more defensible foundation for persistent automation than borrowed developer credentials.