GitHub Copilot adds server authentication with a billable read-only permission

GitHub [introduced server‑to‑server authentication for the Copilot SDK on October 27](https://github.blog/changelog/2026‑10‑27‑github‑copilot‑supports‑server‑to‑server‑authentication), in public preview. A service can make Copilot requests using a GitHub App installed on an organization, rather than relying on a person to stay signed in. The organization that owns the installation is charged for those requests. The [administrator documentation](https://docs.github.com/copilot/how‑tos/administer‑copilot/manage‑for‑organization/manage‑app‑copilot‑access) lists Copilot Business and Copilot Enterprise and gives organization owners responsibility for managing access. The installation must belong to an organization: personal‑account installations and enterprise installations cannot use this authentication method. The organization must also be enabled for Copilot requests from GitHub App installations. That makes the installation itself an operational dependency. A team moving a background service from a user credential needs to identify the organization that will pay, the app allowed to request models and the owner who can withdraw its access.

The app needs the organization‑level Copilot Requests permission set to Read‑only. GitHub’s access and billing guide explicitly says this permission lets an app consume the organization’s AI credits. The label describes the permission GitHub requires; it does not impose a zero‑spend mode.

Organization model policies and spending controls apply, but there is no budget for an individual app or installation. GitHub also distinguishes an alert from enforcement: a budget that only sends alerts will not stop spending. The organization must enable Stop usage when budget limit is reached for the budget to block further requests at its limit.

The practical consequence is a shared spending boundary. Approving another app gives it access to the organization’s applicable budget, so an owner should review its purpose, requested permissions and expected usage before installation. Model availability remains a separate configuration check; OpenTools’ Copilot model‑policy API explanation covers that policy layer.

GitHub’s [administration guide](https://docs.github.com/copilot/how‑tos/administer‑copilot/manage‑for‑organization/manage‑app‑copilot‑access) says app attribution is available in AI usage CSV exports, rather than in the AI usage view on GitHub. In the report, find the organization’s rows with an `app_client_id`, then match that value to `client_id` from the organization’s app‑installations REST response. The response’s `app_slug` identifies the app. An empty `app_client_id` is not evidence that an app made no requests. GitHub says the field is empty for user‑attributed usage, GitHub Actions, other GitHub‑owned apps and historical usage from before app attribution was available. An organization owner can stop one installation by suspending or uninstalling it. That action also blocks the installation’s access to other organization resources. For an app used by several workflows, the access decision therefore reaches beyond its Copilot requests.

For a service outside GitHub Actions, the SDK authentication guide says to mint an installation access token with the Copilot permission and pass it through the SDK’s explicit token option, such as gitHubToken or github_token. Installation tokens expire after one hour.

GitHub’s examples disable stored‑user credential discovery with useLoggedInUser: false. With that setting, environment‑variable tokens in the host process are ignored, so the token must be passed explicitly. The guide gives a separate instruction for an existing runtime URI: set COPILOT_GITHUB_TOKEN on that runtime process.

Refreshing the token also requires a runtime step. GitHub says to mint the replacement before expiry, then restart a child‑process SDK client with it, or restart the host runtime for an in‑process or existing‑runtime connection. A service that creates a token only at its initial launch has not addressed the documented refresh requirement.

GitHub Actions has its own route. For an organization‑owned repository, GitHub documents using the built‑in GITHUB_TOKEN with copilot‑requests: write and enabling the organization’s Allow use of Copilot CLI billed to the organization policy. That route needs no GitHub App or stored authentication secret. The organization‑installed app route does not require that Actions‑specific policy. Choose the path for the runtime before copying its permission settings.

Illustration created for OpenTools with AI assistance. It represents an app using organization credentials; it is not a GitHub interface, product screenshot or photograph.