GitHub has added server-to-server authentication to the GitHub Copilot SDK, giving services and software agents a way to make Copilot requests on behalf of an organization without borrowing a developer’s login. The capability is in public preview, but its operational significance is already clear: platform teams can now give an AI workload its own identity, attach usage to an organization, and revoke access through a GitHub App installation.
That sounds like an authentication enhancement. In practice, it is a new control boundary for production agents. A service identity is easier to rotate, audit, budget, and disable than a user credential, but only if teams design the surrounding lifecycle. The right rollout is therefore not “replace a token and ship.” It is to treat each Copilot-enabled service as a governed workload with an owner, an installation boundary, a short-lived credential path, a spending policy, and a tested kill switch.
What GitHub actually changed
For services outside GitHub Actions, a GitHub App installed on an organization can now request access to Copilot through the read-only Copilot Requests organization permission. The service mints an installation access token, passes that token to the Copilot SDK, and explicitly disables automatic discovery of a signed-in user. GitHub says the installation token expires after one hour.
Requests are attributed and billed to the organization that owns the app installation. The organization’s model policies, budgets, and spending controls remain in force. Administrators can identify app-attributed activity in downloaded AI usage CSV reports through the app_client_id field, then map that client ID to an installed app. Suspending or uninstalling the app stops its Copilot access, although that action also removes the app’s access to other organization resources.
GitHub Actions follows a separate path. An organization-owned repository can grant the workflow’s built-in GITHUB_TOKEN permission to make Copilot requests, avoiding a separate GitHub App and stored authentication secret. Other CI systems and long-running services use the installation-token approach. That distinction matters because the policy switches and operational controls are not identical.
Why user credentials were the wrong production primitive
A user token answers the question “which person authorized this request?” That is useful for an interactive coding assistant. It is a poor fit for a queue worker, remediation bot, internal developer portal action, or autonomous review service that must keep running through vacations, role changes, and employee departures.
User-bound authentication creates several predictable failure modes. Availability depends on an individual account. Usage and cost are mixed with human activity. Revocation can break an unrelated service. Credential discovery may silently select whatever login happens to exist on the host. Ownership becomes ambiguous because the runtime identity points to a person rather than the team operating the workload.
A GitHub App installation provides a more accurate unit of control: the workload operates for an organization, under organization policy, with a credential derived for that installation. This does not make the agent safe by itself. It does make responsibility legible. Platform teams can reason about who owns the app, where it is installed, what it may access, how much it may spend, and how to stop it.
Design the identity boundary before writing integration code
The first architectural decision is the size of the app’s blast radius. One app shared across many unrelated agents is easy to provision, but it collapses attribution and revocation into a coarse control. If one service misbehaves, suspending the shared installation may interrupt every consumer. A separate app for every tiny task creates administrative overhead. A practical middle ground is one app per product or operational domain, with a named owning team and a documented set of workloads.
Keep the app’s permissions narrow. The Copilot Requests permission is labeled read-only, but GitHub explicitly warns that it can incur usage charges. “Read-only” describes the permission type, not financial harmlessness. Review repository and organization permissions together, because suspending the app affects all resources granted to that installation, not only Copilot.
Record four facts in the service catalog before rollout:
- Owner: the team responsible for code, runtime, and cost.
- Installation: the organization and app identity used for requests.
- Purpose: the bounded tasks the agent is allowed to perform.
- Revocation path: who can suspend or uninstall the app, and what else that action disrupts.
This inventory becomes essential during an incident. An app client ID in a billing export is useful only if an operator can quickly map it to a service, owner, and escalation route.
Build token rotation into the runtime
Installation tokens expire after one hour, so token refresh is part of the runtime design rather than a maintenance task. GitHub’s guidance is to mint a new token before expiry and restart the SDK client or runtime with the new credential. Long-running agents need a renewal loop that fails predictably, exposes telemetry, and never falls back to a developer login.
The SDK configuration should explicitly disable logged-in user discovery. GitHub documents this as useLoggedInUser: false or the language-specific equivalent, with the installation token supplied through the SDK’s explicit token option. That setting prevents a production process from authenticating with a cached local credential merely because the intended installation token is missing.
Platform teams should make the failure mode closed and observable. If token minting fails, stop new work, preserve queued tasks, and emit an alert that distinguishes authentication failure from model or application failure. Monitor token age and successful refreshes, but never log the token itself. Exercise the restart path under load so renewal does not duplicate requests or abandon work halfway through a tool sequence.
A minimum token-lifecycle checklist
- Mint tokens just in time and keep their lifetime shorter than the surrounding deployment secret.
- Refresh before expiry with jitter so replicas do not renew simultaneously.
- Disable automatic user-credential discovery.
- Keep credentials out of logs, traces, command arguments, and crash reports.
- Test expired-token handling and repeated
401 Unauthorizedresponses. - Confirm that a suspended installation blocks fresh requests.
Treat billing controls as runtime controls
Server identity improves attribution, but GitHub’s current controls remain organization-wide. Administrators cannot create a dedicated budget for an individual app or installation. App usage counts against the organization’s Copilot budget, and a budget that sends alerts does not stop spending. GitHub says administrators must enable Stop usage when budget limit is reached if the budget is expected to block further requests.
This limitation should shape rollout. A noisy agent can consume shared capacity or push the organization to a stop condition that affects other users and workloads. The application therefore needs its own guardrails even though the billing system cannot enforce them per app.
Set concurrency caps, request-rate limits, maximum retry counts, per-job token or cost estimates, and queue backpressure. Establish an application-level daily allowance with alerts before the organization budget is threatened. Where possible, route optional work to a lower-cost approved model and reserve expensive models for tasks that justify them. Organization model policy still sets the outer boundary, but the service should apply the tighter operational policy.
Cost controls also belong in preproduction tests. A retry loop that looks harmless against a mock can become an expensive feedback cycle when model calls are billable. Test timeouts, malformed responses, rate limits, and partial tool failures. Ensure that each condition has a finite retry policy and that operators can pause intake without redeploying the service.
Make attribution useful, not merely available
GitHub currently exposes app attribution in CSV exports rather than directly in the AI usage interface. Operators must find rows containing an app_client_id, list the organization’s app installations, and match the report value to an installation’s client_id. That is enough for periodic accounting, but it is not a real-time observability system.
Build a local mapping between app client IDs and service metadata, then enrich cost reports with team, environment, workload, and deployment version. Correlate those reports with application metrics such as jobs completed, requests per job, retries, latency, and failures. The useful question is not only “how much did this app spend?” but “what operational outcome did that spending produce?”
Because historical and non-app usage may have an empty app_client_id, reporting pipelines should treat missing attribution as an explicit category rather than discarding those rows. Review attribution after every new installation and permission update. If a service expected to appear under an app remains unattributed, investigate credential fallback before expanding traffic.
Test the kill switch as part of deployment
GitHub provides a direct revocation mechanism: suspend or uninstall the app installation. That is valuable, but it is a broad stop. The same action blocks the app from other organization resources, so incident responders need to know the collateral impact before using it.
A mature design uses layered controls. First, an application switch stops accepting new tasks. Second, a platform control scales the workload to zero or removes network egress. Third, app suspension revokes the identity at GitHub. Finally, uninstalling the app removes the installation if recovery is not expected. Document who can perform each step and how long it takes to propagate.
Run a revocation exercise before production. Start a harmless request stream, suspend the installation, verify that new tokens or requests fail, and confirm that the service does not fall back to another credential. Then restore access and validate recovery. This rehearsal exposes cached credentials, excessive retries, and unclear ownership while the stakes are low.
A staged adoption plan
Begin with one bounded, asynchronous workload whose output can be reviewed. Register an app with the minimum necessary permissions, install it in a noncritical organization or controlled environment, and attach explicit application limits. Instrument token renewal, request counts, retry behavior, model selection, and outcome metrics.
Next, verify billing attribution and map the client ID to the service catalog. Exercise the organization budget behavior, application pause switch, and installation suspension. Confirm that model restrictions produce understandable errors and that operators can distinguish policy denial from authentication failure.
Only then increase concurrency or give the agent access to consequential tools. Server-to-server authentication solves continuity and ownership of the Copilot request, not authorization for every downstream action. Tool permissions, repository access, environment credentials, change approval, and human review remain separate controls.
GitHub’s preview gives platform teams a better foundation for operating Copilot-powered services: an identity attached to the workload instead of the employee. The payoff will come from the practices built around it. Short-lived tokens, explicit credential selection, cost guardrails, attribution, and tested revocation are what convert a new authentication option into a dependable production boundary.
