Article

GitHub previews organization-owned access for background Copilot agents

GitHub’s Copilot preview lets background apps use organization-owned access. Usage is billed to the organization, with no separate budget for each app.

Editorial illustration for GitHub previews organization-owned access for background Copilot agents: a controlled task flows from input to output. Not documentary evidence.

GitHub announced a public preview on October 27, 2026 that gives software teams a new way to run unattended Copilot services. Background services can use an app installed on their organization’s GitHub account instead of an employee’s login. This gives teams building agents—software that carries out tasks—access independent of a signed-in person.

The administration guide lists Copilot Business and Enterprise as eligible plans, with organization owners controlling access. The app must be installed on an organization: installations on personal accounts or at enterprise level do not qualify. Having a Copilot Enterprise subscription does not change that installation requirement.

The organization pays, without a separate app budget

The organization that owns the app installation pays for its Copilot usage. Under GitHub’s usage-based billing rules, cost depends on the model and tokens consumed—the units of content processed and generated. One AI credit equals US$0.01. Included credits are pooled at the billing-entity level; paid usage beyond that pool is enabled by default unless an administrator disables it.

App usage counts against the organization’s Copilot budget, but there is no budget for an individual app or installation. Organization budgets cap metered charges after the included pool is exhausted. To make a budget block further requests, administrators must enable “Stop usage when budget limit is reached”. An alert-only budget allows spending to continue beyond its limit.

Administrators can identify app usage in downloaded AI usage CSV reports, not in GitHub’s on-site AI usage view. Those exports identify the organization and app, allowing teams to attribute consumption.

The practical implication is that visibility and enforcement are different decisions. A report can show which service used credits without giving that service a separate spending ceiling. Teams that require a hard limit for each background app should not treat usage attribution as that control.

Where the service runs changes the setup

For services and automated build systems outside GitHub Actions, the Copilot SDK guide describes using a GitHub App with the organization-level Copilot Requests permission set to Read-only. The SDK, GitHub’s software development kit, accepts a short-lived installation token—a credential for the installed app.

Despite the Read-only label, this permission allows requests that consume AI credits. The app can use only models permitted by the organization’s Copilot policies.

The installation tokens expire after one hour. GitHub instructs developers to obtain a replacement before expiry and restart the SDK client or its host runtime, depending on the setup. Long-running services therefore need to account for credential renewal and those restarts.

Teams already using GitHub Actions have a separate built-in authentication route. It uses GITHUB_TOKEN, requires the copilot-requests: write workflow permission and the “Allow use of Copilot CLI billed to the organization” policy, and needs no custom GitHub App or additional authentication secret. That policy is not required for the new outside-Actions app route.

Authenticating a service is also separate from deciding which actions it may take. Teams should review Copilot’s tool-approval controls alongside access and spending settings, rather than assume an app identity authorizes every operation.

For a background service outside Actions, the immediate decision is whether organization-owned access and shared spending controls fit the job. The feature remains a public preview; GitHub’s announcement does not give a general-availability date.