GitHub heeft server-naar-server-authenticatie geïntroduceerd voor applicaties die zijn gebouwd met de Copilot SDK, waardoor geautomatiseerde productietaken een manier krijgen om toegang te krijgen tot Copilot zonder afhankelijk te zijn van de inloggegevens van een ingelogde ontwikkelaar.

De functie, die op 27 oktober als openbare preview is uitgebracht, maakt gebruik van een GitHub app die is geïnstalleerd in een organisatie. De app verkrijgt een installatietoken met een korte levensduur en het Copilot-gebruik wordt toegeschreven en gefactureerd aan de organisatie die eigenaar is van de installatie. Het modelbeleid, de budgetten en de uitgavencontroles van de organisatie zijn ook van toepassing op verzoeken die door de app worden ingediend.

Dit verandert het operationele model voor teams die Copilot inbedden in interne services, opslagautomatisering of klantgerichte ontwikkelaarstools. Authenticatie kan nu de werklast zelf vertegenwoordigen in plaats van welke medewerker deze dan ook heeft geautoriseerd.

Van gebruikersgegevens tot applicatie-identiteit

Veel agentintegraties beginnen met een persoonlijk toegangstoken of een andere inloggegevens die aan een individuele ontwikkelaar zijn gekoppeld. Dat kan handig zijn tijdens een prototype, maar het levert problemen op als de integratie een blijvende dienst wordt. Werknemers veranderen van rol, inloggegevens verlopen of worden ingetrokken, en auditgegevens kunnen ervoor zorgen dat geautomatiseerde activiteiten op menselijke activiteiten lijken.

Het nieuwe pad van

GitHub gebruikt een installatietoken dat is uitgegeven aan een GitHub app. Installatietokens zijn van korte duur en vallen onder de installatie en machtigingen van de app, waardoor ze beter geschikt zijn voor onbeheerde werklasten dan gebruikersreferenties met een lange levensduur.

Het onderscheid is van belang voor het bestuur. Een organisatie kan de applicatie identificeren die verantwoordelijk is voor het Copilot-verbruik, in plaats van elk verzoek toe te wijzen aan een nominale operator. GitHub bevat een app_client_id-veld in CSV-rapporten over AI-gebruik, waardoor eigenaren tijdens analyse het app-gebruik kunnen scheiden.

Voor teams die een AI API-controlevlak bouwen voor ontwikkelaarsteams is dit een nuttig identiteitspatroon: menselijke gebruikers, automatiseringsaccounts en geïmplementeerde applicaties mogen geen niet-onderscheidbare inloggegevens of factureringsgegevens delen.

Facturering volgt de organisatie

Verzoeken die op deze manier worden geverifieerd, verbruiken het Copilot-tegoed van de organisatie en vallen onder het bestaande modelbeleid, budgetten en uitgavencontroles. Dat geeft beheerders één plek om te beslissen welke modellen een applicatie mag gebruiken en hoeveel totale AI-uitgaven de organisatie zal toestaan.

Het betekent ook dat applicatie-eigenaren server-tot-server-toegang niet kunnen behandelen als een onafhankelijke capaciteitspool. Een drukke integratie kan putten uit hetzelfde organisatiebudget als andere in aanmerking komende Copilot-activiteiten. Teams moeten naast interactief gebruik ook het geautomatiseerde verbruik monitoren en beslissen hoe incidenten, nieuwe pogingen en onverwachte verzoeklussen de gedeelde limieten moeten beïnvloeden.

Het huidige voorbeeld ondersteunt geen afzonderlijk budget voor elke app of installatie. Het veld app_client_id kan helpen bij attributie met terugwerkende kracht, maar rapportage per applicatie is niet hetzelfde als het afdwingen van een hard applicatiespecifiek plafond. Organisaties die isolatie nodig hebben, hebben mogelijk nog steeds hun eigen meetlaag of AI API uitgavencontroles voor teams nodig vóór geautomatiseerde productietaken.

Wat ontwikkelaars moeten veranderen

Ontwikkelaars die de functie adopteren, moeten een GitHub app maken, deze installeren bij de relevante organisatie en de inloggegevens van de app inwisselen voor een installatietoken. De applicatie gebruikt vervolgens dat kortstondige token bij het bellen via de Copilot SDK. Implementatiesystemen moeten daarom de uitgifte en vernieuwing van tokens afhandelen in plaats van een statisch ontwikkelaarstoken voor onbepaalde tijd op te slaan.

Operationele gegevens moeten zowel de GitHub app-identiteit als de organisatie die voor elk verzoek in rekening wordt gebracht, behouden. Dat is vooral belangrijk voor platforms die meerdere organisaties bedienen: een token dat voor één installatie is uitgegeven, mag niet opnieuw worden gebruikt om de werklast van een andere klant te routeren, en gebruiksexports moeten worden afgestemd op de juiste tenant.

Het model heeft ook invloed op offboarding. Het verwijderen van één ontwikkelaar hoeft niet langer een integratie die eigendom is van de organisatie uit te schakelen, terwijl het verwijderen van de GitHub-app of het wijzigen van de rechten ervan een directere controle over de applicatie zelf biedt. Het praktische resultaat is een schonere scheiding tussen de identiteit van het personeel en de identiteit van de werklast.

De resterende limieten

Server-naar-server-authenticatie is nog steeds een openbare preview, dus GitHub kan het contract wijzigen voordat het algemeen beschikbaar is. GitHub heeft geen ondersteuning aangekondigd voor installaties op ondernemingsniveau of persoonlijke accounts via dit authenticatiepad.

Het gebrek aan budgetten per app is de meest directe controlekloof. Organisaties kunnen zien welke app het gebruik heeft gegenereerd, maar ze kunnen nog niet aan elke app of installatie een onafhankelijk Copilot-budget toekennen. Dat wordt belangrijker naarmate bedrijven meerdere codeeragenten, beoordelingsservices en opslagautomatiseringen onder één organisatie inzetten.

Zelfs met die beperking zorgt de release voor een duidelijker eigendomsmodel voor door machines gegenereerd Copilot-verkeer. Authenticatie, beleid en facturering zijn nu gekoppeld aan een geïnstalleerde applicatie en de organisatie ervan, waardoor een beter verdedigbare basis voor aanhoudende automatisering ontstaat dan geleende ontwikkelaarsgegevens.