GitHub wprowadzono uwierzytelnianie między serwerami dla aplikacji zbudowanych przy użyciu rozwiązania Copilot SDK, zapewniając zautomatyzowanym obciążeniom możliwość dostępu do rozwiązania Copilot bez polegania na poświadczeniach zalogowanego programisty.

Ta funkcja, udostępniona w publicznej wersji zapoznawczej 27 października, korzysta z aplikacji GitHub zainstalowanej w organizacji. Aplikacja uzyskuje krótkotrwały token instalacji, a użycie Copilot jest przypisywane i rozliczane organizacji będącej właścicielem instalacji. Zasady modelu organizacji, budżety i kontrola wydatków mają również zastosowanie do żądań wysyłanych przez aplikację.

Zmienia to model operacyjny zespołów osadzających Copilot w usługach wewnętrznych, automatyzacji repozytoriów lub narzędziach programistycznych skierowanych do klienta. Uwierzytelnianie może teraz reprezentować samo obciążenie pracą, a nie dowolnego pracownika, który je autoryzował.

Od danych uwierzytelniających użytkownika do tożsamości aplikacji

Wiele integracji agentów rozpoczyna się od osobistego tokena dostępu lub innego poświadczenia powiązanego z indywidualnym programistą. Może to być wygodne podczas tworzenia prototypu, ale stwarza problemy, gdy integracja staje się usługą trwałą. Pracownicy zmieniają role, uprawnienia wygasają lub zostają unieważnione, a zapisy audytu mogą sprawić, że zautomatyzowane działania będą wyglądać jak działania człowieka.

Nowa ścieżka

GitHub wykorzystuje token instalacyjny wydany dla aplikacji GitHub. Tokeny instalacji są krótkotrwałe i ograniczone do instalacji aplikacji i uprawnień, dzięki czemu lepiej nadają się do obciążeń bez nadzoru niż długotrwałe poświadczenia użytkownika.

Rozróżnienie ma znaczenie dla zarządzania. Organizacja może zidentyfikować aplikację odpowiedzialną za wykorzystanie Copilot zamiast przypisywać każde żądanie nominalnemu operatorowi. GitHub zawiera pole app_client_id w raportach CSV dotyczących wykorzystania AI, umożliwiając właścicielom oddzielenie użycia pochodzącego z aplikacji podczas analizy.

W przypadku zespołów budujących AI API płaszczyznę kontroli dla zespołów programistów jest to przydatny wzorzec tożsamości: użytkownicy będący ludźmi, konta usługi Automation i wdrożone aplikacje nie powinny mieć wspólnych danych uwierzytelniających ani zapisów rozliczeniowych.

Rozliczenia podążają za organizacją

Żądania uwierzytelnione w ten sposób zużywają limit Copilot organizacji i podlegają istniejącym zasadom modelu, budżetom i kontroli wydatków. Dzięki temu administratorzy mogą w jednym miejscu decydować, z jakich modeli może korzystać aplikacja i na jakie łączne wydatki na sztuczną inteligencję pozwoli organizacja.

Oznacza to również, że właściciele aplikacji nie mogą traktować dostępu między serwerami jako niezależnej puli wydajności. Zajęta integracja może korzystać z tego samego budżetu organizacyjnego, co inne kwalifikujące się działania Copilot. Zespoły będą musiały monitorować zautomatyzowane zużycie wraz z użytkowaniem interaktywnym i decydować, w jaki sposób incydenty, ponowne próby i nieoczekiwane pętle żądań powinny wpływać na wspólne limity.

Bieżąca wersja zapoznawcza nie obsługuje oddzielnego budżetu dla każdej aplikacji lub instalacji. Pole app_client_id może pomóc w atrybucji retrospektywnej, ale raportowanie według aplikacji nie jest równoznaczne z egzekwowaniem sztywnego pułapu specyficznego dla aplikacji. Organizacje wymagające izolacji mogą nadal potrzebować własnej warstwy pomiarowej lub AI API kontroli wydatków dla zespołów przed zautomatyzowanymi obciążeniami.

Co programiści muszą zmienić

Programiści korzystający z tej funkcji muszą GitHub utworzyć aplikację, zainstalować ją w odpowiedniej organizacji i wymienić dane uwierzytelniające aplikacji na token instalacyjny. Następnie aplikacja używa tego krótkotrwałego tokenu podczas wywoływania za pośrednictwem drugiego pilota SDK. Dlatego systemy wdrożeniowe muszą obsługiwać wydawanie i odnawianie tokenów, zamiast przechowywać statyczny token programisty przez czas nieokreślony.

Rekordy operacyjne powinny zawierać zarówno tożsamość GitHub aplikacji, jak i organizację obciążaną za każde żądanie. Jest to szczególnie ważne w przypadku platform obsługujących wiele organizacji: token wydany dla jednej instalacji nie może być ponownie używany do kierowania obciążenia innego klienta, a eksport wykorzystania powinien być uzgodniony z właściwym dzierżawcą.

Model wpływa również na odejście od klienta. Usunięcie jednego programisty nie musi już wyłączać integracji należącej do organizacji, natomiast odinstalowanie aplikacji GitHub lub zmiana jej uprawnień zapewnia bardziej bezpośrednią kontrolę nad samą aplikacją. Praktycznym rezultatem jest wyraźniejsze oddzielenie tożsamości pracowników od tożsamości obciążenia pracą.

Pozostałe limity

Uwierzytelnianie między serwerami jest nadal w publicznej wersji zapoznawczej, więc GitHub może zmienić swoją umowę przed powszechnym udostępnieniem. GitHub nie ogłosił obsługi instalacji na poziomie przedsiębiorstwa ani kont osobistych za pośrednictwem tej ścieżki uwierzytelniania.

Brak budżetów na aplikację to najbardziej bezpośrednia luka w kontroli. Organizacje mogą zobaczyć, która aplikacja wygenerowała użycie, ale nie mogą jeszcze przypisać każdej aplikacji lub instalacji niezależnego budżetu Copilot. Staje się to coraz ważniejsze, gdy firmy wdrażają wielu agentów kodujących, usługi recenzowania i automatyzację repozytoriów w ramach jednej organizacji.

Nawet przy tym ograniczeniu w tej wersji ustanowiono jaśniejszy model własności dla ruchu Copilot generowanego maszynowo. Uwierzytelnianie, zasady i rozliczenia są teraz powiązane z zainstalowaną aplikacją i jej organizacją, tworząc łatwiejszą do obrony podstawę trwałej automatyzacji niż pożyczone dane uwierzytelniające programisty.