GitHub a introdus autentificarea de la server la server pentru aplicațiile create cu Copilot SDK, oferind încărcăturilor de lucru automate o modalitate de a accesa Copilot fără a se baza pe acreditările unui dezvoltator conectat.

Funcția, lansată în previzualizare publică pe 27 octombrie, folosește o aplicație GitHub instalată într-o organizație. Aplicația obține un simbol de instalare de scurtă durată, iar utilizarea Copilot este atribuită și facturată organizației care deține instalarea. Politicile model, bugetele și controalele de cheltuieli ale organizației se aplică, de asemenea, solicitărilor făcute de aplicație.

Acest lucru schimbă modelul operațional pentru echipele care încorporează Copilot în serviciile interne, automatizarea depozitelor sau instrumentele de dezvoltare orientate către clienți. Autentificarea poate reprezenta acum volumul de lucru în sine, mai degrabă decât orice angajat care a autorizat-o.

De la datele de conectare ale utilizatorului la identitatea aplicației

Multe integrări de agenți încep cu un simbol de acces personal sau cu o altă autentificare legată de un dezvoltator individual. Acest lucru poate fi convenabil în timpul unui prototip, dar creează probleme atunci când integrarea devine un serviciu persistent. Angajații își schimbă rolurile, acreditările expiră sau sunt revocate, iar înregistrările de audit pot face ca activitatea automatizată să arate ca o activitate umană.

Noua cale a lui

GitHub folosește un simbol de instalare emis către o aplicație GitHub. Indicatoarele de instalare sunt de scurtă durată și sunt acoperite prin instalarea și permisiunile aplicației, ceea ce le face mai potrivite pentru sarcinile de lucru nesupravegheate decât o acreditări de utilizator cu durată lungă de viață.

Distincția contează pentru guvernare. O organizație poate identifica aplicația responsabilă pentru consumul Copilot în loc să atribuie fiecare cerere unui operator nominal. GitHub include un câmp app_client_id în rapoartele CSV de utilizare a AI, permițând proprietarilor să separe utilizarea provenită din aplicație în timpul analizei.

Pentru echipele care construiesc un AI API plan de control pentru echipele de dezvoltatori, acesta este un model de identitate util: utilizatorii umani, conturile de automatizare și aplicațiile implementate nu ar trebui să partajeze acreditări sau înregistrări de facturare care nu pot fi distinse.

Facturarea urmează organizația

Solicitările autentificate în acest fel consumă alocația Copilot a organizației și sunt guvernate de politicile, bugetele și controalele de cheltuieli existente. Acest lucru le oferă administratorilor un loc în care să decidă ce modele poate folosi o aplicație și cât de mult va permite organizația cheltuială totală cu IA.

De asemenea, înseamnă că proprietarii de aplicații nu pot trata accesul de la server la server ca pe un grup independent de capacitate. O integrare aglomerată poate preleva din același buget organizațional ca și alte activități Copilot eligibile. Echipele vor trebui să monitorizeze consumul automatizat împreună cu utilizarea interactivă și să decidă cum incidentele, reîncercările și buclele de solicitări neașteptate ar trebui să afecteze limitele partajate.

Previzualizarea actuală nu acceptă un buget separat pentru fiecare aplicație sau instalare. Câmpul app_client_id poate ajuta la atribuirea retrospectivă, dar raportarea după aplicație nu este echivalentă cu aplicarea unui plafon strict specific aplicației. Organizațiile care au nevoie de izolare pot necesita în continuare propriul strat de măsurare sau AI API controale pentru cheltuieli pentru echipe în fața sarcinilor de lucru automatizate.

Ce trebuie să schimbe dezvoltatorii

Dezvoltatorii care adoptă funcția trebuie să creeze o aplicație GitHub, să o instaleze în organizația relevantă și să schimbe datele de conectare ale aplicației cu un simbol de instalare. Apoi, aplicația folosește acel token de scurtă durată atunci când apelează prin Copilot SDK. Prin urmare, sistemele de implementare trebuie să se ocupe de emiterea și reînnoirea token-ului, mai degrabă decât să stocheze un jeton de dezvoltator static pe termen nelimitat.

Înregistrările operaționale ar trebui să păstreze atât identitatea aplicației GitHub, cât și organizația taxată pentru fiecare solicitare. Acest lucru este deosebit de important pentru platformele care deservesc mai multe organizații: un token emis pentru o instalare nu trebuie reutilizat pentru a direcționa volumul de lucru al altui client, iar exporturile de utilizare ar trebui să fie reconciliate cu chiriașul corect.

Modelul afectează și offboarding-ul. Eliminarea unui dezvoltator nu mai trebuie să dezactiveze o integrare deținută de organizație, în timp ce dezinstalarea aplicației GitHub sau modificarea permisiunilor acesteia oferă un control mai direct asupra aplicației în sine. Rezultatul practic este o separare mai clară între identitatea forței de muncă și identitatea volumului de muncă.

Limitele rămase

Autentificarea de la server la server este încă o previzualizare publică, așa că GitHub își poate modifica contractul înainte de disponibilitatea generală. GitHub nu a anunțat suport pentru instalări la nivel de întreprindere sau conturi personale prin această cale de autentificare.

Lipsa bugetelor per aplicație este cea mai imediată breșă de control. Organizațiile pot vedea ce aplicație a generat utilizarea, dar nu pot încă atribui fiecărei aplicații sau instalări un buget independent Copilot. Acest lucru devine mai important pe măsură ce companiile implementează mai mulți agenți de codare, servicii de revizuire și automatizări ale depozitelor sub o singură organizație.

Chiar și cu această limitare, versiunea stabilește un model de proprietate mai clar pentru traficul Copilot generat de mașini. Autentificarea, politica și facturarea se atașează acum la o aplicație instalată și la organizarea acesteia, creând o bază mai sigură pentru automatizarea persistentă decât acreditările de dezvoltator împrumutate.