On 27 October 2026 GitHub announced server-to-server authentication for Copilot, in public preview. Until now, Copilot requests were tied to a person who had signed in. Agents and automated services built with the GitHub Copilot SDK can now authenticate as a GitHub App installed on an organisation instead.
What GitHub says changed
A developer creates a GitHub App with the read-only “Copilot Requests” organisation permission. An organisation owner installs it. The service then passes a short-lived installation token to the Copilot SDK. Requests are attributed to, and billed to, the organisation that owns the installation, and that organisation’s model policies, budgets and spending controls apply.
Owners can see app-attributed usage in the AI usage CSV reports through an app_client_id field, and can cut access off by suspending or uninstalling the app. GitHub describes it as a workload-owned identity, so automated use is not tied to any one person’s credentials. It is a preview, not general availability, and GitHub’s announcement gives no plan tiers or pricing changes.
Why it matters outside engineering
AI coding has moved from a tool one developer uses to automated services that run on their own: nightly review bots, migration agents, support tooling. Each needs to act as something. Borrowing a developer’s login is the shortcut, and it is the one that causes trouble when that person leaves or when the bill arrives with no owner.
This is the same direction we covered with GitHub’s recent admin controls for Copilot models: AI usage is becoming something an organisation governs, not something individuals quietly run up.
So what
If you commission software that includes AI agents, ask who the agent runs as, who pays for it, and how you would switch it off. A supplier should be able to answer in one sentence each. Our AI-assisted development work keeps access scoped to your organisation and your budget, not to an individual’s account. To scope an AI product, start a project.