GitHub Copilot SDK con autenticazione server-to-server: come si attiva

Il 27 ottobre 2026 GitHub ha aperto in public preview l'autenticazione server-to-server per Copilot: una GitHub App installata su un'organizzazione può far fare richieste a Copilot a nome dell'organizzazione, senza le credenziali di una persona. Riguarda chi costruisce agenti e servizi con il Copilot SDK e finora doveva appoggiarsi a un utente autenticato. Il cambiamento è meno vistoso di un nuovo modello, ma è quello che separa un esperimento sul portatile da un agente che gira su un server con un'identità sua.

Cosa cambia con l'autenticazione server-to-server di Copilot

Finora un servizio costruito sul Copilot SDK si appoggiava alle credenziali di un utente. Secondo il changelog di GitHub, ora le richieste sono legate a un'identità di workload: l'app, installata sull'organizzazione.

Sul fronte dei costi, l'uso viene attribuito e fatturato all'organizzazione proprietaria dell'installazione. Valgono le policy sui modelli, i budget e i controlli di spesa dell'organizzazione. I proprietari possono vedere quali app hanno accesso, ritrovare l'uso delle app nei report CSV dell'uso AI tramite il campo app_client_id e revocare l'accesso sospendendo o disinstallando l'app. Il changelog non cita requisiti di piano, limiti d'uso né prezzi, quindi su questi punti non c'è niente da riportare. Se stai valutando la funzione, è un'informazione da chiedere a GitHub o da verificare nelle impostazioni della tua organizzazione prima di progettare un servizio che ci si appoggia.

Come si attiva: i passaggi della documentazione

Il changelog riassume tre passaggi: dare alla GitHub App il permesso di organizzazione Copilot Requests in sola lettura, installare l'app sull'organizzazione, passare al Copilot SDK un token di accesso di installazione di breve durata. La pagina della documentazione entra nel dettaglio e vale la pena leggerla, perché alcune parti si capiscono solo lì.

Per servizi e sistemi di integrazione continua, la sequenza è questa:

1. Crea una GitHub App con il permesso di organizzazione "Copilot Requests" su "Read-only".
2. Installala sull'organizzazione che deve ricevere la fatturazione.
3. Genera un token di installazione che includa "organization_copilot_requests": "read".
4. Passa il token ghs_ all'SDK con l'opzione esplicita (gitHubToken, github_token o l'equivalente del linguaggio) e imposta useLoggedInUser: false.

L'ultimo punto è il più facile da sbagliare. Con useLoggedInUser: false, il runtime ignora i token nelle variabili d'ambiente come COPILOT_GITHUB_TOKEN, quindi l'opzione esplicita è obbligatoria. Solo se ti colleghi a un runtime già avviato (un URI esistente) imposti COPILOT_GITHUB_TOKEN sul processo del runtime. Non c'è nessun ripiego sulle credenziali di un utente salvate.

I token di installazione scadono dopo un'ora. La documentazione chiede di generarne uno nuovo prima della scadenza e di riavviare il client dell'SDK, o il runtime se è in-process o esistente, con il nuovo token. Per un agente che lavora a lungo significa scrivere il rinnovo fin dall'inizio, non scoprirlo dopo sessanta minuti.

Se lavori dentro GitHub Actions su un repository di un'organizzazione, non serve nessuna app: aggiungi copilot-requests: write ai permessi del workflow, passi GITHUB_TOKEN all'applicazione tramite il blocco env e verifichi che la policy "Allow use of Copilot CLI billed to the organization" sia attiva.

Limiti e punti da controllare prima di usarla

La funzione è in public preview, quindi dettagli e comportamenti possono cambiare. La documentazione precisa inoltre che l'organizzazione deve consentire le richieste Copilot da parte delle installazioni di GitHub App, e che i modelli disponibili dipendono dalla policy Copilot dell'organizzazione e dal supporto del runtime incluso nell'SDK. Non c'è un elenco ufficiale degli scenari non supportati: i limiti noti sono quelli già detti, a partire dall'ignorare i token nelle variabili d'ambiente.

Un consiglio pratico: se avevi già un agente con un token personale, non sostituire tutto in un colpo. Crea l'app, installala su un'organizzazione di prova, esegui uno stesso compito con le due identità e confronta nel report CSV come compaiono le richieste con app_client_id. Il token di installazione, poi, vede solo quello che il permesso concede: tienilo in sola lettura per Copilot Requests e non aggiungere altri permessi all'app solo perché l'interfaccia lo consente.

Perché conta per chi mette agenti in azienda

La mia lettura è che il vantaggio non sia la comodità, è la tracciabilità. Un agente che lavora con le credenziali di una persona rende impossibile distinguere cosa ha fatto la persona e cosa ha fatto la macchina. Con un'app dedicata hai un'identità revocabile e un costo che si legge a parte. È lo stesso ragionamento che faccio quando parlo di quali permessi dare all'AI in azienda: l'agente non deve ereditare tutto ciò che può fare chi lo accende. E la domanda su chi controlla gli agenti AI in azienda trova qui una risposta tecnica, un'identità separata con un proprietario preciso.

Resta un limite da dichiarare: questa è un'autenticazione, non un sistema di approvazione. Cosa può fare l'agente una volta dentro lo decidono le impostazioni di cui parlo nella pagina sulle assisted permissions di Copilot, e l'inquadramento del prodotto per un team sta in Copilot aziendale: cos'è. Prima di spostare un servizio in produzione su un'anteprima, decidi chi possiede l'app, chi riceve gli avvisi di spesa e chi la sospende se qualcosa va storto.