GitHub ir ieviesusi autentifikāciju starp serveriem lietojumprogrammām, kas izveidotas ar Copilot SDK, nodrošinot automatizētām darba slodzēm iespēju piekļūt Copilot, nepaļaujoties uz pierakstītā izstrādātāja akreditācijas datiem.
Funkcija, kas tika izlaista publiskajā priekšskatījumā 27. oktobrī, izmanto GitHub, kas ir instalēta organizācijā. Lietojumprogramma iegūst īslaicīgu instalācijas pilnvaru, un Copilot lietojums tiek attiecināts uz organizāciju, kurai pieder instalācija, un par to tiek iekasēts rēķins. Organizācijas modeļu politikas, budžeti un izdevumu kontroles attiecas arī uz lietotnes veiktajiem pieprasījumiem.
Tādējādi tiek mainīts darbības modelis komandām, kas iegulst Copilot iekšējos pakalpojumos, repozitoriju automatizācijā vai klientu izstrādātāju rīkos. Autentifikācija tagad var atspoguļot pašu darba slodzi, nevis to, kurš darbinieks to ir pilnvarojis.
No lietotāja akreditācijas datiem līdz lietojumprogrammas identitātei
Daudzas aģentu integrācijas sākas ar personīgo piekļuves pilnvaru vai citu akreditācijas informāciju, kas saistīta ar atsevišķu izstrādātāju. Tas var būt ērti prototipa laikā, taču tas rada problēmas, kad integrācija kļūst par pastāvīgu pakalpojumu. Darbinieki maina lomas, akreditācijas dati beidzas vai tiek atsaukti, un audita ieraksti var padarīt automatizētu darbību līdzīgu cilvēka darbībai.
GitHub jaunajā ceļā tiek izmantots instalācijas marķieris, kas izsniegts lietotnei GitHub. Instalācijas pilnvaras ir īslaicīgas, un to darbības joma ir atkarīga no lietotnes instalēšanas un atļaujām, tāpēc tās ir labāk piemērotas bez uzraudzības atstātām darba slodzēm nekā ilgstoša lietotāja akreditācijas dati.
Atšķirība ir svarīga pārvaldībai. Organizācija var identificēt lietojumprogrammu, kas ir atbildīga par Copilot patēriņu, tā vietā, lai katru pieprasījumu attiecinātu uz nominālo operatoru. GitHub AI lietojuma CSV pārskatos ietver lauku app_client_id, kas ļauj īpašniekiem analīzes laikā atdalīt lietotnes radīto lietojumu.
Komandām, kas veido AI API vadības plakni izstrādātāju komandām, šis ir noderīgs identitātes modelis: cilvēku lietotāji, automatizācijas konti un izvietotās lietojumprogrammas nedrīkst koplietot neatšķiramus akreditācijas datus vai norēķinu ierakstus.
Norēķini notiek pēc organizācijas
Šādi autentificēti pieprasījumi patērē organizācijas Copilot pabalstu, un tos regulē esošās modeļa politikas, budžeti un izdevumu kontroles. Tādējādi administratori var izlemt, kurus modeļus lietojumprogramma drīkst izmantot un cik lielus kopējos AI izdevumus organizācija atļaus.
Tas arī nozīmē, ka lietojumprogrammu īpašnieki nevar uzskatīt servera-servera piekļuvi kā neatkarīgu jaudas kopu. Noslogota integrācija var iegūt no tā paša organizatoriskā budžeta, ko izmanto citas piemērotas Copilot aktivitātes. Komandām būs jāuzrauga automatizētais patēriņš līdztekus interaktīvai lietošanai un jāizlemj, kā incidentiem, atkārtojumiem un negaidītām pieprasījumu cilpām vajadzētu ietekmēt kopīgotos ierobežojumus.
Pašreizējais priekšskatījums neatbalsta atsevišķu budžetu katrai lietotnei vai instalācijai. Lauks app_client_id var palīdzēt retrospektīvai attiecināšanai, taču pārskatu sniegšana pēc lietojumprogrammas nav līdzvērtīga stingru lietojumprogrammu griestu ieviešanai. Organizācijām, kurām nepieciešama izolācija, joprojām var būt nepieciešams savs mērīšanas slānis vai AI API tēriņu vadīklas komandām automatizētu darba slodžu priekšā.
Kas izstrādātājiem jāmaina
Izstrādātājiem, kas izmanto šo funkciju, ir jāizveido lietotne GitHub, jāinstalē tā attiecīgajā organizācijā un jāapmaina lietotnes akreditācijas dati pret instalēšanas pilnvaru. Lietojumprogramma pēc tam izmanto šo īslaicīgo marķieri, zvanot, izmantojot Copilot SDK. Tāpēc izvietošanas sistēmām ir jārīkojas ar pilnvaru izdošanu un atjaunošanu, nevis uz nenoteiktu laiku jāuzglabā statisks izstrādātāja pilnvaras.
Darbības ierakstos ir jāsaglabā gan lietotnes GitHub identitāte, gan organizācija, par kuru jāmaksā par katru pieprasījumu. Tas ir īpaši svarīgi platformām, kas apkalpo vairākas organizācijas: vienai instalācijai izsniegto pilnvaru nedrīkst atkārtoti izmantot, lai novirzītu cita klienta darba slodzi, un lietojuma eksportēšana ir jāsaskaņo ar pareizo nomnieku.
Modelis ietekmē arī izbraukšanu no borta. Noņemot vienu izstrādātāju, vairs nav jāatspējo organizācijai piederoša integrācija, savukārt lietotnes GitHub atinstalēšana vai tās atļauju maiņa nodrošina tiešāku kontroli pār pašu lietojumprogrammu. Praktiskais rezultāts ir skaidrāka darbaspēka identitātes un darba slodzes identitātes nošķiršana.
Pārējie ierobežojumi
Servera-servera autentifikācija joprojām ir publisks priekšskatījums, tāpēc GitHub var mainīt savu līgumu pirms vispārējas pieejamības. GitHub nav paziņojis par atbalstu uzņēmuma līmeņa instalācijām vai personīgajiem kontiem, izmantojot šo autentifikācijas ceļu.
Katrai lietotnei paredzēto budžetu trūkums ir vistiešākā kontroles atšķirība. Organizācijas var redzēt, kura lietotne radīja lietojumu, taču tās vēl nevar katrai lietotnei vai instalācijai piešķirt neatkarīgu Copilot budžetu. Tas kļūst vēl svarīgāks, jo uzņēmumi vienā organizācijā izvieto vairākus kodēšanas aģentus, pārskata pakalpojumus un repozitoriju automatizāciju.
Pat ar šo ierobežojumu, laidiens izveido skaidrāku īpašumtiesību modeli mašīnu ģenerētai Copilot datplūsmai. Autentifikācija, politika un norēķini tagad tiek pievienoti instalētai lietojumprogrammai un tās organizācijai, radot uzticamāku pamatu pastāvīgai automatizācijai nekā aizņemtie izstrādātāja akreditācijas dati.