On October 27, 2026, GitHub opened a public preview of server-to-server authentication for GitHub Copilot. Until now, any automated service calling Copilot had to borrow the credentials of a signed-in person. The new mechanism introduces an identity owned by the organization itself, built for agents and integrations that run without a human directly behind the wheel.
The problem it solves
A code-review agent, a documentation bot, or any service built on the Copilot SDK previously had to impersonate a user account to make requests. That dependency created two recurring headaches: billing and quotas stayed tied to that person, and the account being disabled or offboarded could silently break the service. The new mechanism decouples automated usage from any individual account.
How organization-owned identity works
The implementation builds on GitHub Apps already installed at the organization level. An administrator grants the app the read-only Copilot Requests organization permission, then installs it on the relevant organization. The service exchanges a short-lived installation access token for calls to the Copilot SDK, which then acts on behalf of the organization rather than any one developer.
| Before | With server-to-server authentication |
|---|---|
| Identity tied to a personal account | Identity owned by the organization |
| Billing attached to the user | Billing and quotas at the organization level |
| Service can break when someone leaves | Independent of any individual account |
| Limited traceability in usage reports | Attribution via the app_client_id field |
A simplified example of a call authenticated with an installation token, as documented by GitHub:
POST /copilot/requests HTTP/1.1
Host: api.github.com
Authorization: Bearer <installation_access_token>
Accept: application/vnd.github+json
X-GitHub-Api-Version: 2026-10-01
Usage is now attributed and billed to the organization that owns the installation, under the model policies and spending caps it has configured.
What administrators can control
Organization owners keep oversight of this new access path. They can review which apps are authorized to use Copilot, identify usage generated by each app in CSV usage reports through the app_client_id field, and revoke access by suspending or uninstalling the app.
Why it matters for agent-heavy teams
This move fits a broader pattern at GitHub, which already shipped a Copilot model policy API and is pushing assisted permissions toward general availability. Organization-owned identity rounds out that governance layer: it makes it practical, at scale, to run agents that call Copilot continuously without a single person carrying technical responsibility for the account behind it.
Key takeaways
GitHub is offering organizations their own identity for automated Copilot usage, in public preview since October 27, 2026. The mechanism relies on a GitHub App with the Copilot Requests permission and a short-lived installation token. Billing, model policies, and traceability now follow the organization rather than an individual account, simplifying the operation of long-running agents.
On the engagements where I’ve watched code-review bots fail silently because a service account expired or lost its permissions, this kind of decoupling is the right direction. The open question is whether the default quotas will be generous enough for an agent running continuously against an active repository — previews tend to disappoint exactly there once they reach production. — Simon Janvier
Further reading: GitHub’s official changelog announcement.
