Copilot SDK Server-to-Server Auth: Setup and Billing

GitHub announced public-preview server-to-server authentication for the Copilot SDK on October 27, 2026. An organization-installed GitHub App can now make Copilot requests for an automated service without relying on a particular employee's signed-in account. The change is especially relevant to teams running long-lived agents, background jobs or external CI systems that need an organization-owned identity.

This is an authentication and billing change, not a new Copilot model or a claim that every SDK deployment is production-ready. The feature is still in public preview. GitHub's official documentation distinguishes two implementation paths: the built-in token for eligible GitHub Actions workflows, and a GitHub App installation token for services outside GitHub Actions.

Two authentication paths: choose the right one

The permissions sound counterintuitive: GitHub Actions uses copilot-requests: write, while the GitHub App uses a permission labeled Read-only. They are different authentication routes. Read-only on the app does not mean its requests are free; GitHub says they consume the owning organization's AI credits. The Actions-specific CLI policy also does not govern the external-app token path.

Set up an external Copilot SDK service

1. Create a GitHub App with the organization Copilot Requests permission set to Read-only; review any other permissions it asks for.
2. Install the app on the organization that should own and pay for its usage. Confirm the organization allows Copilot requests through app installations.
3. Generate an installation access token with organization_copilot_requests set to read; GitHub says installation tokens expire after one hour.
4. Pass the token through the SDK's explicit gitHubToken/github_token option. If disabling user credential discovery, do not rely on an automatically discovered environment token.
5. Rotate the installation token before expiry and restart the relevant SDK client or runtime as GitHub's guide instructs. Test authorization, model policy and budget behavior with a low-volume request.

Billing, attribution and the missing per-app budget

For GitHub App authentication, the organization owning the installation pays for Copilot usage. Its model policies and organization-level budgets apply, but GitHub does not currently provide a budget for one app or one installation. That makes shared-budget governance important: an experimental service and a business-critical agent may consume the same organization-level allowance unless the team monitors them operationally.

Administrators can trace app-attributed usage in exported AI usage CSV reports using the app_client_id column. GitHub says this detail is not available in the ordinary AI usage view. To identify the app, match that client ID against the organization's app installations. A budget configured only to send alerts will not stop spending; GitHub documents a separate Stop usage when budget limit is reached setting.

What to verify before putting an agent on a schedule

For teams already using GitHub Actions, the built-in token may be simpler because it avoids managing a separate GitHub App for that workflow. For a service hosted elsewhere, app-based authentication avoids tying the agent's identity to one employee. Neither option removes the need to validate outputs, protect credentials, control tool permissions and audit costs. Keep the distinction clear when documenting internal AI-agent architecture.