GitHub har introduceret server-til-server-godkendelse for applikationer bygget med Copilot SDK, hvilket giver automatiserede arbejdsbelastninger en måde at få adgang til Copilot uden at være afhængig af en udviklers legitimationsoplysninger, der er logget ind.
Funktionen, der blev udgivet i offentlig forhåndsvisning den 27. oktober, bruger en GitHub-app installeret på en organisation. Appen får en kortvarig installationstoken, og Copilot-brug tilskrives og faktureres til den organisation, der ejer installationen. Organisationens modelpolitikker, budgetter og udgiftskontrol gælder også for anmodninger fra appen.
Dette ændrer driftsmodellen for teams, der integrerer Copilot i interne tjenester, lagerautomatisering eller kundevendte udviklerværktøjer. Godkendelse kan nu repræsentere selve arbejdsbyrden i stedet for den medarbejder, der tilfældigvis har godkendt den.
Fra brugeroplysninger til applikationsidentitet
Mange agentintegrationer begynder med et personligt adgangstoken eller en anden legitimationsoplysninger knyttet til en individuel udvikler. Det kan være praktisk under en prototype, men det skaber problemer, når integrationen bliver en vedvarende service. Medarbejdere skifter roller, legitimationsoplysninger udløber eller tilbagekaldes, og revisionsregistreringer kan få automatiseret aktivitet til at ligne menneskelig aktivitet.
GitHubs nye sti bruger et installationstoken, der er udstedt til en GitHub-app. Installationstokens er kortlivede og dækkes gennem appens installation og tilladelser, hvilket gør dem bedre egnede til uovervågede arbejdsbelastninger end en langvarig brugerlegitimationsoplysninger.
Skelnen har betydning for styring. En organisation kan identificere den applikation, der er ansvarlig for Copilot-forbrug i stedet for at tilskrive enhver anmodning til en nominel operatør. GitHub inkluderer et app_client_id-felt i AI-brug CSV-rapporter, hvilket giver ejere mulighed for at adskille app-origineret brug under analyse.
For teams, der bygger et AI API kontrolplan for udviklerteams, er dette et nyttigt identitetsmønster: menneskelige brugere, automatiseringskonti og implementerede applikationer bør ikke dele loginoplysninger eller faktureringsoplysninger, der ikke kan skelnes.
Fakturering følger organisationen
Anmodninger, der er godkendt på denne måde, bruger organisationens Copilot-godtgørelse og er styret af dens eksisterende modelpolitikker, budgetter og udgiftskontrol. Det giver administratorer ét sted at beslutte, hvilke modeller en applikation må bruge, og hvor mange samlede AI-udgifter organisationen vil tillade.
Det betyder også, at applikationsejere ikke kan behandle server-til-server-adgang som en uafhængig pulje af kapacitet. En travl integration kan trække fra det samme organisationsbudget som andre kvalificerede Copilot-aktiviteter. Teams skal overvåge automatiseret forbrug sammen med interaktiv brug og beslutte, hvordan hændelser, genforsøg og uventede anmodningsløkker skal påvirke delte grænser.
Den aktuelle forhåndsvisning understøtter ikke et separat budget for hver app eller installation. Feltet app_client_id kan hjælpe med retrospektiv tilskrivning, men rapportering efter applikation svarer ikke til at håndhæve et hårdt applikationsspecifikt loft. Organisationer, der har brug for isolering, kan stadig kræve deres eget målerlag eller AI API forbrugskontrol for teams foran automatiske arbejdsbelastninger.
Hvad udviklere skal ændre
Udviklere, der anvender funktionen, skal oprette en GitHub-app, installere den på den relevante organisation og udveksle appens legitimationsoplysninger med et installationstoken. Applikationen bruger derefter det kortvarige token, når du ringer gennem Copilot SDK. Implementeringssystemer skal derfor håndtere tokenudstedelse og fornyelse i stedet for at gemme et statisk udviklertoken på ubestemt tid.
Driftsregistreringer bør bevare både GitHub-appens identitet og den organisation, der opkræves for hver anmodning. Det er især vigtigt for platforme, der betjener flere organisationer: Et token, der er udstedt til én installation, må ikke genbruges til at dirigere en anden kundes arbejdsbyrde, og brugseksport bør afstemmes med den korrekte lejer.
Modellen påvirker også offboarding. Fjernelse af en udvikler behøver ikke længere at deaktivere en organisationsejet integration, mens afinstallation af GitHub-appen eller ændring af dens tilladelser giver en mere direkte kontrol over selve applikationen. Det praktiske resultat er en renere adskillelse mellem arbejdsstyrkens identitet og arbejdsbyrdens identitet.
De resterende grænser
Server-til-server-godkendelse er stadig en offentlig forhåndsvisning, så GitHub kan ændre sin kontrakt, før den er tilgængelig. GitHub har ikke annonceret understøttelse af installationer på virksomhedsniveau eller personlige konti via denne godkendelsessti.
Manglen på budgetter pr. app er det mest umiddelbare kontrolgab. Organisationer kan se, hvilken app der genererede brug, men de kan endnu ikke tildele hver app eller installation et uafhængigt Copilot-budget. Det bliver mere betydningsfuldt, efterhånden som virksomheder implementerer flere kodningsagenter, anmeldelsestjenester og lagerautomatiseringer under én organisation.
Selv med denne begrænsning etablerer udgivelsen en klarere ejerskabsmodel for maskingenereret Copilot-trafik. Godkendelse, politik og fakturering er nu knyttet til en installeret applikation og dens organisation, hvilket skaber et mere forsvarligt grundlag for vedvarende automatisering end lånte udviklerlegitimationsoplysninger.