GitHub je uvedel preverjanje pristnosti med strežniki za aplikacije, ustvarjene s Copilotom SDK, kar omogoča samodejnim delovnim obremenitvam dostop do Copilota brez zanašanja na poverilnice prijavljenega razvijalca.

Funkcija, objavljena v javnem predogledu 27. oktobra, uporablja GitHub aplikacijo, nameščeno v organizaciji. Aplikacija pridobi kratkotrajni namestitveni žeton, uporaba Copilota pa se pripiše in zaračuna organizaciji, ki je lastnik namestitve. Politike modelov organizacije, proračuni in nadzor porabe veljajo tudi za zahteve, ki jih naredi aplikacija.

To spremeni operativni model za ekipe, ki vgrajujejo Copilot v notranje storitve, avtomatizacijo repozitorija ali orodja za razvijalce, usmerjena k strankam. Preverjanje pristnosti lahko zdaj predstavlja samo delovno obremenitev in ne katerega koli zaposlenega, ki jo je pooblastil.

Od uporabniških poverilnic do identitete aplikacije

Številne integracije posrednikov se začnejo z žetonom osebnega dostopa ali drugo poverilnico, povezano s posameznim razvijalcem. To je lahko priročno med prototipom, vendar povzroča težave, ko integracija postane trajna storitev. Zaposleni zamenjajo vloge, poverilnice potečejo ali so preklicane, zaradi revizijskih zapisov pa lahko avtomatizirana dejavnost izgleda kot človeška dejavnost.

Nova pot

GitHub uporablja namestitveni žeton, izdan aplikaciji GitHub. Namestitveni žetoni so kratkotrajni in obsegajo namestitev in dovoljenja aplikacije, zaradi česar so bolj primerni za nenadzorovane delovne obremenitve kot dolgotrajne poverilnice uporabnika.

Razlikovanje je pomembno za upravljanje. Organizacija lahko identificira aplikacijo, odgovorno za porabo Copilot, namesto da vsako zahtevo pripiše nominalnemu operaterju. GitHub vključuje polje app_client_id v poročilih CSV o uporabi umetne inteligence, kar lastnikom omogoča, da med analizo ločijo uporabo, ki izvira iz aplikacije.

Za ekipe, ki gradijo AI API nadzorno raven za skupine razvijalcev, je to uporaben vzorec identitete: človeški uporabniki, računi za avtomatizacijo in nameščene aplikacije ne smejo deliti nerazločljivih poverilnic ali zapisov zaračunavanja.

Obračunavanje sledi organizaciji

Zahteve, overjene na ta način, porabijo dodatek za kopilota organizacije in jih urejajo njeni obstoječi pravilniki o modelih, proračuni in nadzor porabe. To daje skrbnikom možnost, da se na enem mestu odločijo, katere modele lahko uporablja aplikacija in koliko skupne porabe umetne inteligence dovoli organizacija.

Prav tako pomeni, da lastniki aplikacij ne morejo obravnavati dostopa med strežniki kot neodvisnega bazena zmogljivosti. Zasedena integracija lahko črpa iz istega proračuna organizacije kot druge primerne dejavnosti Copilot. Ekipe bodo morale spremljati samodejno porabo skupaj z interaktivno uporabo in se odločiti, kako naj incidenti, ponovni poskusi in nepričakovane zanke zahtev vplivajo na skupne omejitve.

Trenutni predogled ne podpira ločenega proračuna za vsako aplikacijo ali namestitev. Polje app_client_id lahko pomaga pri retrospektivnem dodeljevanju, vendar poročanje glede na aplikacijo ni enakovredno uveljavljanju stroge zgornje meje, specifične za aplikacijo. Organizacije, ki potrebujejo izolacijo, morda še vedno potrebujejo svojo merilno plast ali AI API nadzor porabe za ekipe pred avtomatiziranimi delovnimi obremenitvami.

Kaj morajo razvijalci spremeniti

Razvijalci, ki sprejmejo to funkcijo, morajo ustvariti GitHub aplikacijo, jo namestiti v ustrezno organizacijo in zamenjati poverilnice aplikacije za namestitveni žeton. Aplikacija nato uporabi ta kratkotrajni žeton, ko kliče prek Copilot SDK. Sistemi za uvajanje morajo zato obravnavati izdajo in obnovo žetona, namesto da bi statičnega žetona razvijalca shranjevali za nedoločen čas.

Operativni zapisi morajo ohraniti GitHub identiteto aplikacije in organizacijo, ki se zaračuna za vsako zahtevo. To je še posebej pomembno za platforme, ki služijo več organizacijam: žetona, izdanega za eno namestitev, ne smete ponovno uporabiti za usmerjanje delovne obremenitve druge stranke, izvoze uporabe pa je treba uskladiti s pravilnim najemnikom.

Model vpliva tudi na izstop. Če odstranite enega razvijalca, vam ni treba več onemogočiti integracije v lasti organizacije, medtem ko odstranitev GitHub aplikacije ali spreminjanje njenih dovoljenj zagotavlja bolj neposreden nadzor nad samo aplikacijo. Praktični rezultat je čistejše ločevanje med identiteto delovne sile in identiteto delovne obremenitve.

Preostale omejitve

Preverjanje pristnosti med strežniki je še vedno javni predogled, zato GitHub lahko spremeni svojo pogodbo, preden je splošno dostopen. GitHub ni napovedal podpore za namestitve na ravni podjetja ali osebne račune prek te poti preverjanja pristnosti.

Pomanjkanje proračunov za posamezne aplikacije je najbolj neposredna vrzel v nadzoru. Organizacije lahko vidijo, katera aplikacija je ustvarila uporabo, vendar še ne morejo vsaki aplikaciji ali namestitvi dodeliti neodvisnega proračuna Copilot. To postane pomembnejše, ko podjetja uvedejo več agentov za kodiranje, pregledovalne storitve in avtomatizacije skladišč v eni organizaciji.

Tudi s to omejitvijo izdaja vzpostavlja jasnejši model lastništva za strojno ustvarjen promet Copilot. Preverjanje pristnosti, pravilnik in zaračunavanje so zdaj povezani z nameščeno aplikacijo in njeno organizacijo, kar ustvarja bolj obrambno podlago za vztrajno avtomatizacijo kot izposojene poverilnice razvijalca.