GitHub Copilot agents can now use organization-owned identities

What GitHub released

GitHub's October 27 changelog [1] announces server-to-server authentication for GitHub Apps in public preview. Services built with the Copilot SDK can make requests for an organization without a signed-in user's token.

Usage follows the organization installation. GitHub says the organization's model policies, budgets and spending controls apply, and the app appears in AI usage reports through the app_client_id field.[1]

This changes identity and accounting, not the agent's authorization to every downstream system. Repository, deployment, cloud and database permissions still need separate controls.

When to use a GitHub App

Use the app flow for a shared service, scheduled worker or external CI system that should survive employee departures and should charge usage to the organization. It also gives administrators one installation they can inspect, suspend or uninstall.[1][4]

GitHub's server authentication guide [2] says GitHub Actions should use its built-in GITHUB_TOKEN instead. For an organization-owned repository, the workflow grants its built-in token copilot-requests: write. That workflow-token permission differs from the read-only Copilot Requests organization permission assigned to a GitHub App.

Keep user authentication for interactive products where each person needs their own identity and Copilot entitlement. Moving every client to one app identity would erase useful user-level boundaries.

How the authentication flow works

• Create a GitHub App with the Copilot Requests organization permission set to read-only, then install it on the organization that should own usage.[2]
• Authenticate the app itself with a signed JSON Web Token, then request an installation access token for the target installation.[3]
• Pass the short-lived installation token through the Copilot SDK's explicit GitHub token option. GitHub's current guide says to disable automatic signed-in-user discovery for this flow.[2]
• Refresh the installation token before it expires. GitHub documents a one-hour lifetime and recommends using an SDK such as Octokit to handle regeneration.[2][3]
• Record the installation ID and app client ID in operational metadata, but never log the private key, JWT or installation token.

A safe rollout checklist

• Create a dedicated app for one service rather than sharing a broad app across unrelated agents.
• Request only Copilot Requests access and confirm the installation scope before minting the first token.
• Store the app private key in the service's secret manager, rotate it, and ensure logs redact token-shaped values.
• Set organization model policy, budget and spending controls before enabling production traffic.
• Test token expiry, refresh, organization suspension and app uninstall. The service should stop safely when identity is revoked.
• Export usage and match app_client_id to the expected installation. Alert on an unknown app or a sudden request increase.
• Keep tool credentials separate from Copilot authentication and give each tool the smallest practical permission set.
• Document how to disable the app and drain queued work without switching to a personal access token.

Limits and trade-offs

• The feature is a public preview, so interfaces, required permissions and availability can change.[1]
• An installation token proves which app installation made the Copilot request. It does not make generated code safe or grant authority to deploy it.
• Organization attribution can simplify cost ownership, but teams still need per-job metadata to connect a request spike to a specific workflow.
• A compromised app private key can let an attacker mint installation tokens until administrators revoke the key or installation.
• Suspending or uninstalling the app stops future access, but teams should also cancel queued jobs and inspect recent usage.[4]

Frequently asked questions

• Does the agent need a user's Copilot subscription? GitHub says this flow needs organization policy rather than an individual user subscription.[2]
• Who pays for requests? GitHub attributes and bills usage to the organization that owns the app installation.[1]
• How long does the token last? GitHub documents a one-hour expiry for installation access tokens.[2][3]
• Can an owner identify the app in reports? Yes. GitHub documents app_client_id in AI usage CSV reports for app-attributed usage.[1][4]
• How can an owner revoke access? Suspend or uninstall the GitHub App, then verify that the service can no longer mint or use tokens.[1][4]
• Should GitHub Actions use this app flow? GitHub recommends the built-in GITHUB_TOKEN for organization-owned repository workflows when possible.[2]