Skip to content
NewsProduct launch

GitHub Copilot adds server-to-server authentication so agents skip a signed-in user

· by

The short version

GitHub Copilot's SDK can now authenticate as an organization-owned GitHub App instead of a person, letting automated services make Copilot requests without tying usage to any one employee's login, per GitHub's October 27, 2026 changelog.

GitHub Copilot adds server-to-server authentication so agents skip a signed-in user

A Copilot-powered service can now authenticate to GitHub as the organization that owns it, not as whichever employee happened to be logged in when someone wired up the integration. GitHub moved that capability, server-to-server authentication for the Copilot SDK, into public preview on October 27, 2026, per its changelog.

What

The mechanism runs through a GitHub App rather than a user account. An organization owner creates a GitHub App, grants it the read-only "Copilot Requests" organization permission, and installs it on the org, GitHub's SDK documentation explains. From there, the app generates a short-lived installation access token (prefixed ghs_) and passes it to the Copilot SDK's token parameter, with useLoggedInUser set to false so the SDK uses that token instead of scanning for a developer's own credentials.

Those installation tokens expire after one hour, per the same documentation, which means any long-running agent or service has to mint a fresh token on a cycle rather than authenticate once and forget it. GitHub's guidance splits the restart path by architecture: a child process should get a new client instance with the refreshed token, while an existing runtime needs the host process itself restarted to pick up the new credential.

Once a request flows through, it is attributed and billed to the organization that owns the installation, and that org's existing model policies, budgets, and spending controls apply automatically, GitHub's changelog says. No separate per-app policy configuration is required to bring a new service under the org's existing spending guardrails.

Auditing an app's usage means cross-referencing a CSV, not the dashboard

The visibility GitHub shipped alongside this feature is more manual than the authentication flow itself. Org owners can spot app-attributed Copilot usage through the app_client_id field in AI usage CSV reports, but that field alone only identifies the app by its numeric client ID, not a readable name, according to GitHub's administration documentation. Resolving which app that ID belongs to requires a second step: cross-referencing it against the REST API's "List app installations for an organization" endpoint to pull the matching app_slug. There is no single dashboard view that shows app-attributed usage with the app's name already attached.

Revocation has two distinct levels, and they are not interchangeable. Suspending an app's installation pauses its Copilot access, while uninstalling removes it outright, and either action also blocks that installation's access to the organization's other resources, not just Copilot, per the same documentation. A platform team granting one app broad org access to solve a narrow Copilot use case inherits that wider blast radius if the installation is ever suspended or pulled for an unrelated reason.

For a team building an internal agent or automated service on the Copilot SDK today, the practical checklist is now: scope the GitHub App to read-only "Copilot Requests," build token-refresh logic for the one-hour expiry into the service's startup path, and budget time to manually reconcile the CSV export against the installations API if usage needs to be audited by app name rather than client ID.

Context and reactions

GitHub has spent much of October layering administrative controls onto Copilot's agent and automation surface rather than shipping new end-user features. The company gave enterprises a model policy API on October 19 so admins could manage which models are available across an enterprise, its orgs, and its teams programmatically rather than through the UI alone, per that changelog entry. It had already given enterprises centralized deny, ask, and allow rules for Copilot's shell commands, file access, and network domains when managed permissions for agent operations reached general availability on September 9, per GitHub's changelog. Server-to-server authentication extends that same pattern to identity: where managed permissions controls what an agent can do, this feature controls who, or what, an agent is allowed to say it is when it does it. Neither GitHub nor Microsoft has issued commentary on the server-to-server feature beyond the changelog post itself, and no independent security researcher had weighed in within the first day of the preview.

What to watch next

Watch whether GitHub adds per-app usage controls, such as rate limits or model policies scoped to one GitHub App rather than inherited wholesale from the organization, since the current preview only supports org-wide inheritance. Also watch for the preview-to-GA timeline; GitHub's changelog does not commit to a date.

Sources