GitHub Copilot gets server-to-server authentication for agents

The problem this change solves

Until this feature launched, on October 27, 2026, any agent or service built with the GitHub Copilot SDK had to operate on behalf of an authenticated user. The token used to call Copilot's AI models was, in some way, tied to a person: a developer's credentials, a service account disguised as a user, or a login flow that required someone on the other end.

For small automations this was never a big deal. But for those building autonomous agents that run in the background, without supervision on every call, the model created real friction. Billing and usage were attributed to a specific person, who might leave the company or have access revoked, and there was no way to separate, in the organization's reports, how much consumption came from automation and how much came from direct human use.

According to GitHub's changelog, the new feature introduces what the post itself calls "workload-owned identity": an identity that belongs to the workload, not the user. This helps agents and automated services operate at greater scale without tying authentication and consumption to individuals.

How it works in practice

Server-to-server authentication uses a mechanism already familiar to the GitHub ecosystem: GitHub Apps installed in organizations. The flow described in the changelog follows three steps:

1. Grant the GitHub App the organization permission "Copilot Requests", which is read-only;
2. Install the app in the organization that will consume Copilot;
3. Generate a short-lived installation access token and pass it to the GitHub Copilot SDK in calls.

It's essentially the same machine-to-machine pattern that GitHub already uses in other parts of the platform, such as the automatic GITHUB_TOKEN in GitHub Actions, which is also born from an App installation token. What's new is that this pattern now applies to calls to Copilot.

In code terms, any service written against the Copilot SDK that today depends on user login or a personal access token can swap that credential for an installation access token obtained via the Apps API. The token expires quickly, as is standard for GitHub App installation tokens, which reduces the risk window if it leaks.

Who owns usage and billing

Every call made with this token is attributed and billed to the organization that owns the App installation, not to a user. This has two direct implications.

• Model policies, budgets, and spending controls configured by the organization now also apply to the agent. If the org restricted usage to certain models, such as GPT-6.1 Terra mentioned in another post from the same changelog, the agent respects the same limit.
• Organization owners gain granular visibility: it's possible to review which Apps have access to Copilot and identify, in the AI usage CSV reports, the consumption attributed to each App via the app_client_id field.

To revoke access, simply suspend or uninstall the App. There's no need to rotate a user token or deactivate anyone's account, which simplifies an agent's lifecycle: provision, operate, and, if something goes wrong, cut off access in a single place.

What this replaces and why it matters to builders

Before this change, teams that wanted to automate tasks with Copilot (automatic pull request review, documentation generation, issue triage) had two imperfect options: use the credentials of a real user, which creates dependency on a person and billing headaches, or build their own proxy layer to decouple Copilot usage from the identity of whoever is logged in.

Server-to-server authentication solves this with infrastructure GitHub already maintains. Those who already use Apps for integrations with GitHub's REST or GraphQL API don't need to learn a new model: it's the same installation token, applied to a new permission.

In short: the practical gain is that Copilot automation stops depending on a logged-in person and gains its own identity, its own billing, and isolated revocation.

When it's worth using, and when it isn't

This authentication model makes sense for autonomous agents that run continuously in CI/CD pipelines, reviewing code or generating artifacts without human intervention on every call, for internal organization bots that serve entire teams without tying usage to whoever configured the bot, and for third-party services published as GitHub Apps that offer Copilot-based features to multiple customer organizations.

On the other hand, there's no reason to change anything if Copilot usage remains the traditional kind: a developer interacting with Copilot Chat or the Copilot CLI on their own machine. That flow stays authenticated by the user, as it always was, because there individual attribution is exactly the desired behavior: the organization wants to know who's using what.

It's worth remembering that the feature is in public preview. At GitHub, that usually means the API surface may change before general availability, and that teams who already put production agents on top of it should follow the changelog so as not to be caught off guard by a contract change.

What remains open

The changelog doesn't detail specific rate limits for calls made via installation token, nor whether there's any SLA difference compared to user-authenticated calls. The published material also doesn't include a complete code example showing the swap from the user flow to the installation token in the SDK, only a reference to the server-to-server authentication documentation, which anyone implementing it needs to consult directly.

For organizations that already have internal GitHub Apps and some level of automation running on top of Copilot, the change reduces workarounds. For those who haven't built anything automated yet, it's, above all, a signal: GitHub is treating agents as first-class citizens at the platform's own authentication layer, not as an appendage of user login.