Why a read-only Copilot app can still spend your organization’s credits
A nightly code analysis agent can inherit a surprisingly human dependency: the login of the person who configured it. On October 27, GitHub introduced public-preview server-to-server authentication for organization-installed GitHub Apps using the Copilot SDK. A service can make requests as its installation rather than a signed-in user. The surprising detail is the required permission: Read-only can still authorize paid AI usage.
Read-only is not a free request
The app receives a short-lived installation token after being granted the organization Copilot Requests permission at Read-only. Usage is attributed and billed to the organization owning the installation. In this context, the label authorizes requests that consume AI credits; it should not be read as a promise that nothing billable can happen.
Consider a hypothetical company with a nightly analysis app and a document summarizer. Both may have a read-only label and both may generate organization usage. Not editing repository files and consuming model capacity can happen together. Moving identity from a person to a workload changes ownership, not the cost of inference.
Actions and external servers enter differently
An external service or other CI system mints an installation access token and supplies an explicit SDK option such as gitHubToken. Only organization installations qualify. Personal-account and enterprise installations do not. The enterprise-installation release discussed previously and this Copilot preview have different boundaries.
An organization repository running in GitHub Actions can instead use its built-in GITHUB_TOKEN. That path uses copilot-requests: write in YAML and requires the Allow use of Copilot CLI billed to the organization policy. Organization-installed app authentication does not require that policy. Read-only in the app and write in a workflow describe different authentication paths.
Keep the identity working after an hour
Installation tokens expire after one hour. A long-running service needs to deliver the replacement to its runtime, not merely mint it. The SDK documentation instructs a child-process client to restart with the new token; an in-process or existing runtime requires restarting its host runtime. Replacing a file does not itself prove that a running process adopted the new value.
The useLoggedInUser: false setting disables automatic credential discovery, including environment-variable tokens. Pass the token explicitly through the SDK option when using it. If a laptop succeeds while a server reports no authentication, distinguish an accidental fallback to a personal login from the token actually delivered to the runtime.
App attribution, organization budgets
Organization owners can locate app usage in AI usage CSV exports through organization and app_client_id. Match that value to client_id in the installation-list API to identify app_slug. This attribution is not currently exposed in the web AI usage view. Visibility per app also does not create a per-app budget: budgets remain organizational, and an alert-only budget does not stop excess usage.
Suspending or uninstalling an installation stops its requests and its access to other organization resources. The useful change is a clearer owner for automated work within organization model and spending policies. Detaching a service from a personal account works best when token replacement and billing ownership move with it.