GitHub announced GitHub Copilot server-to-server authentication on October 27, 2026, in public preview. A GitHub App installed on an organization can now use a short-lived installation access token with the Copilot SDK, allowing a service or agent to make Copilot requests without a signed-in user’s credentials. For QA teams building automated test triage, release-note analysis, or test-generation services, this changes the identity under test from a person to a workload.

What GitHub released

The preview is for GitHub Apps installed on organizations. The app needs the organization-level Copilot Requests permission set to read-only, then the service passes a short-lived installation token to the Copilot SDK. GitHub says usage is attributed and billed to the organization that owns the installation; its model policies, budgets, and spending controls apply.

Read-only is a potentially misleading label here: GitHub’s documentation explicitly notes that this permission authorizes requests that can consume the organization’s AI credits. The organization owner can review app access, find app-attributed usage through app_client_id in AI usage CSV reports, and remove access by suspending or uninstalling the app.

Why this matters for QA engineers

Workload identity can make a non-interactive QA agent less fragile than a workflow tied to one employee’s login or token. It also creates new acceptance criteria: correct organization attribution, policy enforcement, credit controls, token renewal, and a clean failure when access is revoked. Treat those as product behaviors, not just deployment details.

  • Repeatability: run the same agent test after a user leaves the team; the service should remain governed by the app installation, not that user.
  • Security: verify the runtime does not silently fall back to a developer’s stored CLI or OAuth credentials.
  • Cost visibility: confirm the organization can distinguish service usage in reporting before scaling scheduled runs.

A focused QA checklist

  • Identity test: use a valid GitHub App installation token and verify the intended organization receives the usage attribution.
  • Least-privilege test: request only the documented organization Copilot Requests permission. Review every additional permission before approving the app.
  • Token-lifecycle test: installation tokens expire after one hour. Test a request near expiry, refresh the token before it expires, and restart the client/runtime as the SDK documentation requires.
  • Credential-isolation test: set useLoggedInUser: false and verify a request fails with an absent or invalid installation token rather than using a local developer login.
  • Policy test: attempt a request for an organization-disallowed model and confirm it is rejected; then use an allowed model and record the result.
  • Revocation test: suspend or uninstall the app in a controlled environment and confirm subsequent requests fail, audit data remains usable, and the agent raises an actionable alert.

Keep the runtime explicit

GitHub’s SDK guidance recommends passing the installation token explicitly and disabling logged-in-user fallback. A minimal TypeScript-shaped pattern is:

const client = new CopilotClient({
  connection: RuntimeConnection.forStdio(),
  gitHubToken: process.env.INSTALLATION_TOKEN,
  useLoggedInUser: false
});

Do not put an installation token in a test fixture, log it, or persist it beyond its lifetime. In CI, use a secret manager and assert only non-sensitive signals: token-present, expected organization attribution, allowed-model result, and a predictable error category for a revoked or expired token.

One rollout guardrail

Start with a bounded, read-only QA workload: for example, classify a small set of synthetic failed-test summaries and store only the resulting labels and request metadata. Set a spending threshold, review app_client_id reporting, and make app suspension part of the runbook before connecting the agent to production test evidence. This feature is a public preview, so re-run the contract checks when GitHub updates the SDK or preview documentation.

Sources