GitHub ha introdotto l'autenticazione server-server per le applicazioni create con Copilot SDK, offrendo ai carichi di lavoro automatizzati un modo per accedere a Copilot senza fare affidamento sulle credenziali di uno sviluppatore che ha effettuato l'accesso.

La funzionalità, rilasciata in anteprima pubblica il 27 ottobre, utilizza un'app GitHub installata in un'organizzazione. L'app ottiene un token di installazione di breve durata e l'utilizzo di Copilot viene attribuito e fatturato all'organizzazione proprietaria dell'installazione. Le policy del modello, i budget e i controlli della spesa dell'organizzazione si applicano anche alle richieste effettuate dall'app.

Ciò cambia il modello operativo per i team che incorporano Copilot in servizi interni, automazione del repository o strumenti di sviluppo rivolti al cliente. L'autenticazione ora può rappresentare il carico di lavoro stesso anziché il dipendente che lo ha autorizzato.

Dalle credenziali dell'utente all'identità dell'applicazione

Molte integrazioni degli agenti iniziano con un token di accesso personale o un'altra credenziale legata a un singolo sviluppatore. Ciò può essere utile durante la fase di prototipo, ma crea problemi quando l'integrazione diventa un servizio persistente. I dipendenti cambiano ruolo, le credenziali scadono o vengono revocate e i record di controllo possono far sembrare l'attività automatizzata un'attività umana.

Il nuovo percorso di

GitHub utilizza un token di installazione rilasciato a un'app GitHub. I token di installazione hanno vita breve e rientrano nell'ambito dell'installazione e delle autorizzazioni dell'app, il che li rende più adatti ai carichi di lavoro non presidiati rispetto alle credenziali utente di lunga durata.

La distinzione è importante per la governance. Un'organizzazione può identificare l'applicazione responsabile del consumo di Copilot invece di attribuire ogni richiesta ad un operatore nominale. GitHub include un campo app_client_id nei report CSV sull'utilizzo dell'AI, consentendo ai proprietari di separare l'utilizzo originato dall'app durante l'analisi.

Per i team che creano un piano di controllo AI API per i team di sviluppatori, questo è un modello di identità utile: gli utenti umani, gli account di automazione e le applicazioni distribuite non devono condividere credenziali o record di fatturazione indistinguibili.

La fatturazione segue l'organizzazione

Le richieste autenticate in questo modo consumano la franchigia del copilota dell'organizzazione e sono regolate dalle norme del modello esistente, dai budget e dai controlli della spesa. Ciò offre agli amministratori un posto dove decidere quali modelli può utilizzare un'applicazione e quanta spesa aggregata per l'AI consentirà l'organizzazione.

Ciò significa anche che i proprietari delle applicazioni non possono considerare l'accesso da server a server come un pool di capacità indipendente. Un'integrazione impegnativa può attingere allo stesso budget organizzativo di altre attività copilota idonee. I team dovranno monitorare il consumo automatizzato insieme all'uso interattivo e decidere in che modo gli incidenti, i nuovi tentativi e i cicli di richieste imprevisti dovrebbero influenzare i limiti condivisi.

L'anteprima corrente non supporta un budget separato per ogni app o installazione. Il campo app_client_id può aiutare con l'attribuzione retrospettiva, ma il reporting per applicazione non equivale a imporre un tetto rigido specifico per l'applicazione. Le organizzazioni che necessitano di isolamento potrebbero comunque richiedere un proprio livello di misurazione o AI API controlli della spesa per i team a fronte dei carichi di lavoro automatizzati.

Cosa devono cambiare gli sviluppatori

Gli sviluppatori che adottano la funzionalità devono creare un'GitHub app, installarla nell'organizzazione pertinente e scambiare le credenziali dell'app con un token di installazione. L'applicazione utilizza quindi quel token di breve durata quando chiama tramite il Copilot SDK. I sistemi di distribuzione devono quindi gestire l'emissione e il rinnovo dei token anziché archiviare un token sviluppatore statico a tempo indeterminato.

I record operativi devono preservare sia l'identità dell'app GitHub sia l'organizzazione addebitata per ciascuna richiesta. Ciò è particolarmente importante per le piattaforme che servono più organizzazioni: un token emesso per un'installazione non deve essere riutilizzato per instradare il carico di lavoro di un altro cliente e le esportazioni di utilizzo devono essere riconciliate con il tenant corretto.

Il modello influisce anche sull'offboarding. La rimozione di uno sviluppatore non deve più disabilitare un'integrazione di proprietà dell'organizzazione, mentre la disinstallazione dell'app GitHub o la modifica delle sue autorizzazioni fornisce un controllo più diretto sull'applicazione stessa. Il risultato pratico è una separazione più netta tra identità della forza lavoro e identità del carico di lavoro.

I limiti rimanenti

L'autenticazione da server a server è ancora un'anteprima pubblica, quindi GitHub potrebbe modificare il proprio contratto prima della disponibilità generale. GitHub non ha annunciato il supporto per installazioni di livello aziendale o account personali tramite questo percorso di autenticazione.

La mancanza di budget per app è la lacuna di controllo più immediata. Le organizzazioni possono vedere quale app ha generato utilizzo, ma non possono ancora assegnare a ciascuna app o installazione un budget Copilot indipendente. Ciò diventa ancora più significativo quando le aziende distribuiscono più agenti di codifica, servizi di revisione e automazioni dei repository sotto un'unica organizzazione.

Anche con questa limitazione, la versione stabilisce un modello di proprietà più chiaro per il traffico Copilot generato dalla macchina. L'autenticazione, i criteri e la fatturazione sono ora collegati a un'applicazione installata e alla sua organizzazione, creando una base più difendibile per l'automazione persistente rispetto alle credenziali degli sviluppatori prese in prestito.