GitHub Copilot Server-to-Server Authentication: SDK Access, Billing and Limits

GitHub opened a public preview of Copilot server-to-server authentication on October 27. Services built with the Copilot SDK can now authenticate through an organization-installed GitHub App instead of a signed-in employee, with usage charged to that organization.

That makes unattended agents easier to operate. It also moves an important decision into app administration: which services should be allowed to consume the organization's AI budget?

How Copilot server-to-server authentication works

The announcement describes a GitHub App permission called Copilot Requests. An app requests this organization permission with read-only access, then uses a short-lived installation token to make Copilot requests through the SDK.

The installation owner becomes the billing identity. This is useful for a scheduled maintenance agent or an internal service that should continue operating independently of one employee's login. The organization can govern the app rather than treating a person's credentials as infrastructure.

The word “read-only” needs care here. The permission allows an app to consume AI credits. It describes the permission level, not a promise that the app cannot create costs.

SDK setup and token renewal

GitHub's authentication guide separates services outside GitHub Actions from workflows running inside it.

For an external service, create the app, grant the organization permission, and install it on the organization that should pay. Generate an installation token with organization_copilot_requests set to read, then supply that token explicitly through the SDK's authentication option.

Installation tokens expire after one hour. The guide describes minting a replacement before expiry and restarting the SDK client or runtime, depending on how the service is hosted. A long-running worker therefore needs a token lifecycle, not just a successful first request.

For an organization-owned GitHub Actions repository, the documented alternative uses the workflow's GITHUB_TOKEN with copilot-requests: write. That path requires the policy allowing Copilot CLI usage billed to the organization. It is a different setup from installing an app for an external service.

For a production worker, I would treat expiry handling as part of the first integration test. A job that works for ten minutes but fails during its next scheduled run has not really solved unattended execution.

Organization billing does not mean per-app budgets

The administration documentation covers Copilot Business and Enterprise organizations. Personal-account and enterprise-level installations are not supported by this preview.

Organization model policies and budgets apply, but there is no separate budget for each app or installation. App attribution is available in AI usage CSV exports through app_client_id, rather than in the AI usage interface. An alert-only budget does not stop consumption; that requires the stop-usage budget option.

Owners can suspend or uninstall an app to revoke access, although that also affects its other organization permissions. These are broad controls, so an app with several responsibilities deserves particular care.

The practical consequence is straightforward: a shared organization budget can still be exhausted by one busy integration. Teams running several agents should consider their own queue limits, concurrency controls and per-service accounting instead of assuming billing attribution also provides spending isolation.

What this changes for internal agents

This preview addresses a real operational mismatch: software services should not need a human login to establish who they are working for. It gives platform teams a more suitable identity boundary for Copilot-backed automation.

The next useful test is whether a team can explain an unexpected bill quickly. Knowing which organization paid is a start. Knowing which app ran, why it ran and when it should stop is what makes the integration manageable.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams turn agent infrastructure, product updates and engineering decisions into clear stories developers and founders can use.

Book a 30-minute call.