GitHub ha introduït l'autenticació de servidor a servidor per a aplicacions creades amb Copilot SDK, que ofereix a les càrregues de treball automatitzades una manera d'accedir a Copilot sense dependre de les credencials d'un desenvolupador iniciat.
La funció, publicada en previsualització pública el 27 d'octubre, utilitza una aplicació GitHub instal·lada en una organització. L'aplicació obté un testimoni d'instal·lació de curta durada i l'ús de Copilot s'atribueix i es factura a l'organització propietaria de la instal·lació. Els models de polítiques, pressupostos i controls de despesa de l'organització també s'apliquen a les sol·licituds fetes per l'aplicació.
Això canvia el model operatiu dels equips que incrusten Copilot als serveis interns, l'automatització del dipòsit o les eines de desenvolupament orientades al client. L'autenticació ara pot representar la càrrega de treball en si mateixa en lloc de qualsevol empleat que l'autoritzés.
Des de les credencials d'usuari fins a la identitat de l'aplicació
Moltes integracions d'agents comencen amb un testimoni d'accés personal o una altra credencial vinculada a un desenvolupador individual. Això pot ser convenient durant un prototip, però crea problemes quan la integració es converteix en un servei persistent. Els empleats canvien de rol, les credencials caduquen o es revoquen, i els registres d'auditoria poden fer que l'activitat automatitzada sembli activitat humana.
El camí nou deGitHub utilitza un testimoni d'instal·lació emès a una aplicació GitHub. Els testimonis d'instal·lació tenen una durada curta i s'abasten mitjançant la instal·lació i els permisos de l'aplicació, la qual cosa els fa més adequats per a càrregues de treball desateses que una credencial d'usuari de llarga durada.
La distinció és important per a la governança. Una organització pot identificar l'aplicació responsable del consum de Copilot en lloc d'atribuir cada sol·licitud a un operador nominal. GitHub inclou un camp app_client_id als informes CSV d'ús d'IA, que permet als propietaris separar l'ús originat per l'aplicació durant l'anàlisi.
Per als equips que creen un pla de control AI API per a equips de desenvolupadors, aquest és un patró d'identitat útil: els usuaris humans, els comptes d'automatització i les aplicacions desplegades no haurien de compartir credencials o registres de facturació indistinguibles.
La facturació segueix l'organització
Les sol·licituds autenticades d'aquesta manera consumeixen la dotació de Copilot de l'organització i es regeixen per les polítiques de models, els pressupostos i els controls de despesa existents. Això ofereix als administradors un lloc on decidir quins models pot utilitzar una aplicació i quanta despesa total en IA permetrà l'organització.
També vol dir que els propietaris d'aplicacions no poden tractar l'accés de servidor a servidor com un conjunt de capacitat independent. Una integració ocupada pot extreure's del mateix pressupost organitzatiu que altres activitats Copilot elegibles. Els equips hauran de supervisar el consum automatitzat juntament amb l'ús interactiu i decidir com els incidents, els reintents i els bucles de sol·licituds inesperats haurien d'afectar els límits compartits.
La previsualització actual no admet un pressupost independent per a cada aplicació o instal·lació. El camp app_client_id pot ajudar amb l'atribució retrospectiva, però els informes per aplicació no equivalen a fer complir un sostre específic de l'aplicació. Les organitzacions que necessiten aïllament encara poden requerir la seva pròpia capa de mesura o controls de la despesa AI API per als equips davant les càrregues de treball automatitzades.
Què han de canviar els desenvolupadors
Els desenvolupadors que adopten la funció han de crear una aplicació GitHub, instal·lar-la a l'organització corresponent i intercanviar les credencials de l'aplicació per un testimoni d'instal·lació. Aleshores, l'aplicació utilitza aquest testimoni de curta durada quan truca a través del Copilot SDK. Per tant, els sistemes de desplegament han de gestionar l'emissió i la renovació de testimonis en lloc d'emmagatzemar un testimoni de desenvolupador estàtic indefinidament.
Els registres operatius haurien de conservar tant la identitat de l'aplicació GitHub com l'organització cobrada per cada sol·licitud. Això és especialment important per a plataformes que donen servei a diverses organitzacions: un testimoni emès per a una instal·lació no s'ha de reutilitzar per encaminar la càrrega de treball d'un altre client i les exportacions d'ús s'han de conciliar amb l'inquilí correcte.
El model també afecta l'offboarding. L'eliminació d'un desenvolupador ja no ha de desactivar una integració propietat de l'organització, mentre que desinstal·lar l'aplicació GitHub o canviar-ne els permisos proporciona un control més directe sobre l'aplicació en si. El resultat pràctic és una separació més neta entre la identitat de la força de treball i la identitat de la càrrega de treball.
Els límits restants
L'autenticació de servidor a servidor encara és una previsualització pública, de manera que GitHub pot canviar el seu contracte abans de la disponibilitat general. GitHub no ha anunciat suport per a instal·lacions a nivell d'empresa o comptes personals mitjançant aquest camí d'autenticació.
La manca de pressupostos per aplicació és la bretxa de control més immediata. Les organitzacions poden veure quina aplicació ha generat l'ús, però encara no poden assignar a cada aplicació o instal·lació un pressupost independent de Copilot. Això es fa més important a mesura que les empreses despleguen diversos agents de codificació, serveis de revisió i automatitzacions de dipòsits en una mateixa organització.
Fins i tot amb aquesta limitació, la versió estableix un model de propietat més clar per al trànsit de Copilot generat per màquina. L'autenticació, la política i la facturació s'adjunten ara a una aplicació instal·lada i a la seva organització, creant una base més defensable per a l'automatització persistent que les credencials de desenvolupador prestades.