GitHub је увео аутентификацију сервер-сервер за апликације направљене помоћу Цопилот-а SDK, дајући аутоматизованим радним оптерећењима начин да приступе Цопилот-у без ослањања на акредитиве пријављеног програмера.

Ова функција, објављена у јавном прегледу 27. октобра, користи апликацију GitHub инсталирану у организацији. Апликација добија краткотрајни токен за инсталацију, а коришћење Цопилот-а се приписује и наплаћује организацији која је власник инсталације. Смернице модела организације, буџети и контроле потрошње такође се примењују на захтеве апликације.

Ово мења оперативни модел за тимове који уграђују Цопилот у интерне услуге, аутоматизацију спремишта или алатке за програмере окренуте клијентима. Потврда идентитета сада може представљати сам посао, а не било који запослени који га је овластио.

Од корисничких акредитива до идентитета апликације

Многе интеграције агената почињу са личним токеном за приступ или другим акредитивима везаним за индивидуалног програмера. То може бити згодно током прототипа, али ствара проблеме када интеграција постане трајна услуга. Запослени мењају улоге, акредитиви истичу или се опозивају, а записи ревизије могу учинити да аутоматизована активност изгледа као људска активност.

Нова путања

GitHub користи инсталациони токен издат апликацији GitHub. Инсталациони токени су кратког века и обухватају инсталацију и дозволе апликације, што их чини погоднијим за радна оптерећења без надзора него дуговечни кориснички акредитиви.

Разлика је важна за управљање. Организација може да идентификује апликацију одговорну за потрошњу копилота уместо да приписује сваки захтев номиналном оператеру. GitHub укључује поље app_client_id у ЦСВ извештајима о коришћењу вештачке интелигенције, омогућавајући власницима да одвоје коришћење засновано на апликацији током анализе.

За тимове који граде АИ API контролну раван за тимове програмера, ово је користан образац идентитета: људски корисници, аутоматизовани налози и примењене апликације не би требало да деле акредитиве или записе о обрачуну који се не могу разликовати.

Обрачун прати организацију

Захтеви оверени на овај начин троше додатак за копилот организације и регулишу се њеним постојећим смерницама модела, буџетима и контролама потрошње. То даје администраторима једно место да одлуче које моделе апликација може да користи и колико ће укупна потрошња на вештачку интелигенцију организација дозволити.

То такође значи да власници апликација не могу да третирају приступ сервер-серверу као независну групу капацитета. Заузета интеграција може да црпи из истог организационог буџета као и друга квалификована активност копилота. Тимови ће морати да прате аутоматизовану потрошњу заједно са интерактивном употребом и одлуче како би инциденти, поновни покушаји и неочекиване петље захтева требало да утичу на дељена ограничења.

Тренутни преглед не подржава посебан буџет за сваку апликацију или инсталацију. Поље app_client_id може помоћи у ретроспективном приписивању, али извештавање по апликацији није еквивалентно примени строгог лимита специфичног за апликацију. Организације којима је потребна изолација можда ће и даље захтевати сопствени слој за мерење или АИ API контроле потрошње за тимове испред аутоматизованих радних оптерећења.

Шта програмери треба да промене

Програмери који усвајају ову функцију морају да направе апликацију GitHub, да је инсталирају у релевантној организацији и размене акредитиве апликације за токен за инсталацију. Апликација затим користи тај краткотрајни токен када позива преко копилота SDK. Системи за примену стога морају да управљају издавањем и обнављањем токена, а не да чувају статички токен програмера на неодређено време.

Оперативни записи треба да чувају и GitHub идентитет апликације и организацију која се наплаћује за сваки захтев. То је посебно важно за платформе које опслужују више организација: токен издат за једну инсталацију не сме се поново користити за усмеравање радног оптерећења другог клијента, а извоз коришћења треба да се усклади са исправним закупцем.

Модел такође утиче на прелазак са брода. Уклањање једног програмера више не мора да онемогући интеграцију у власништву организације, док деинсталирање апликације GitHub или промена њених дозвола пружа директнију контролу над самом апликацијом. Практични резултат је јасније раздвајање између идентитета радне снаге и идентитета радног оптерећења.

Преостала ограничења

Потврда идентитета између сервера је и даље јавни преглед, тако да GitHub може да промени уговор пре опште доступности. GitHub није најавио подршку за инсталације на нивоу предузећа или личне налоге преко ове путање за потврду идентитета.

Недостатак буџета по апликацији је најнепосреднији недостатак у контроли. Организације могу да виде која је апликација генерисана коришћењем, али још увек не могу свакој апликацији или инсталацији доделити независни Цопилот буџет. То постаје значајније јер компаније примењују више агената за кодирање, услуге прегледа и аутоматизације складишта у оквиру једне организације.

Чак и са тим ограничењем, издање успоставља јаснији модел власништва за машински генерисан Цопилот саобраћај. Потврда идентитета, смернице и обрачун сада се везују за инсталирану апликацију и њену организацију, стварајући одбрањивију основу за трајну аутоматизацију од позајмљених акредитива програмера.