GitHub je uveo autentifikaciju od poslužitelja do poslužitelja za aplikacije izgrađene s Copilotom SDK, dajući automatiziranim radnim opterećenjima način pristupa Copilotu bez oslanjanja na vjerodajnice prijavljenog razvojnog programera.
Ova značajka, objavljena u javnom pregledu 27. listopada, koristi GitHub aplikaciju instaliranu u organizaciji. Aplikacija dobiva kratkotrajni instalacijski token, a korištenje Copilota pripisuje se i naplaćuje organizaciji koja posjeduje instalaciju. Pravila modela organizacije, proračuni i kontrole potrošnje također se primjenjuju na zahtjeve koje postavlja aplikacija.
Ovo mijenja operativni model za timove koji ugrađuju Copilot u interne usluge, automatizaciju repozitorija ili alate za razvojne programere okrenute klijentima. Provjera autentičnosti sada može predstavljati samo radno opterećenje, a ne bilo kojeg zaposlenika koji ju je autorizirao.
Od korisničkih vjerodajnica do identiteta aplikacije
Mnoge integracije agenata počinju osobnim pristupnim tokenom ili drugom vjerodajnicom povezanom s pojedinačnim programerom. To može biti zgodno tijekom prototipa, ali stvara probleme kada integracija postane trajna usluga. Zaposlenici mijenjaju uloge, vjerodajnice ističu ili se poništavaju, a revizijski zapisi mogu učiniti da automatizirana aktivnost izgleda kao ljudska aktivnost.
Nova stazaGitHub koristi instalacijski token izdan aplikaciji GitHub. Instalacijski tokeni kratkog su vijeka i obuhvaćeni su instalacijom i dopuštenjima aplikacije, što ih čini prikladnijima za radna opterećenja bez nadzora od dugotrajnih korisničkih vjerodajnica.
Razlika je važna za upravljanje. Organizacija može identificirati aplikaciju odgovornu za potrošnju Copilota umjesto da svaki zahtjev pripisuje nominalnom operateru. GitHub uključuje polje app_client_id u CSV izvješćima o korištenju umjetne inteligencije, omogućujući vlasnicima da odvoje korištenje koje potječe iz aplikacije tijekom analize.
Za timove koji grade AI API kontrolnu razinu za razvojne timove, ovo je koristan obrazac identiteta: ljudski korisnici, računi za automatizaciju i implementirane aplikacije ne bi trebali dijeliti nerazlučive vjerodajnice ili evidenciju naplate.
Naplata slijedi organizaciju
Zahtjevi provjereni na ovaj način troše dopuštenje za Copilot organizacije i upravljaju se prema postojećim modelima pravila, proračunima i kontrolama potrošnje. To daje administratorima jedno mjesto na kojem mogu odlučiti koje modele aplikacija može koristiti i koliku će ukupnu potrošnju umjetne inteligencije organizacija dopustiti.
To također znači da vlasnici aplikacija ne mogu tretirati pristup između poslužitelja kao neovisni skup kapaciteta. Zauzeta integracija može crpiti iz istog organizacijskog proračuna kao i druge prihvatljive Copilot aktivnosti. Timovi će morati pratiti automatiziranu potrošnju uz interaktivnu upotrebu i odlučiti kako bi incidenti, ponovni pokušaji i neočekivane petlje zahtjeva trebali utjecati na dijeljena ograničenja.
Trenutni pregled ne podržava zasebni proračun za svaku aplikaciju ili instalaciju. Polje app_client_id može pomoći s retrospektivnim pripisivanjem, ali izvješćivanje po aplikaciji nije jednako provođenju stroge gornje granice specifične za aplikaciju. Organizacije koje trebaju izolaciju i dalje mogu zahtijevati vlastiti mjerni sloj ili AI API kontrole potrošnje za timove ispred automatiziranih radnih opterećenja.
Što programeri trebaju promijeniti
Razvojni programeri koji usvajaju značajku moraju izraditi GitHub aplikaciju, instalirati je u relevantnoj organizaciji i zamijeniti vjerodajnice aplikacije za instalacijski token. Aplikacija zatim koristi taj kratkotrajni token kada poziva preko Copilot SDK. Sustavi za implementaciju stoga moraju upravljati izdavanjem i obnavljanjem tokena, a ne pohranjivanjem statičnog razvojnog tokena na neodređeno vrijeme.
Operativni zapisi trebaju čuvati i GitHub identitet aplikacije i organizaciju koja se naplaćuje za svaki zahtjev. To je posebno važno za platforme koje opslužuju više organizacija: token izdan za jednu instalaciju ne smije se ponovno upotrijebiti za usmjeravanje radnog opterećenja drugog korisnika, a izvozi korištenja trebaju se uskladiti s ispravnim zakupcem.
Model također utječe na offboarding. Uklanjanje jednog razvojnog programera više ne mora onemogućiti integraciju u vlasništvu organizacije, dok deinstaliranje aplikacije GitHub ili promjena njezinih dopuštenja pruža izravniju kontrolu nad samom aplikacijom. Praktični rezultat je čistije razdvajanje između identiteta radne snage i identiteta radnog opterećenja.
Preostala ograničenja
Provjera autentičnosti od poslužitelja do poslužitelja još uvijek je javni pregled, pa GitHub može promijeniti svoj ugovor prije opće dostupnosti. GitHub nije najavio podršku za instalacije na razini poduzeća ili osobne račune kroz ovaj put provjere autentičnosti.
Nedostatak proračuna po aplikaciji najneposredniji je nedostatak kontrole. Organizacije mogu vidjeti koja je aplikacija generirala korištenje, ali još ne mogu svakoj aplikaciji ili instalaciji dodijeliti neovisni Copilot proračun. To postaje sve značajnije kako tvrtke uvode više agenata za kodiranje, usluge pregleda i automatizaciju repozitorija u jednoj organizaciji.
Čak i uz to ograničenje, izdanje uspostavlja jasniji model vlasništva za strojno generirani Copilot promet. Autentifikacija, pravila i naplata sada se povezuju s instaliranom aplikacijom i njezinom organizacijom, stvarajući branjiviji temelj za trajnu automatizaciju od posuđenih vjerodajnica razvojnog programera.