GitHub въведе удостоверяване от сървър към сървър за приложения, изградени с Copilot SDK, като дава на автоматизираните работни натоварвания начин за достъп до Copilot, без да разчитат на идентификационни данни на влязъл програмист.

Функцията, пусната в публичен преглед на 27 октомври, използва GitHub приложение, инсталирано в организация. Приложението получава токен за краткотрайна инсталация и използването на Copilot се приписва и таксува на организацията, която притежава инсталацията. Правилата на модела на организацията, бюджетите и контролите върху разходите също се прилагат за заявки, направени от приложението.

Това променя оперативния модел за екипи, вграждащи Copilot във вътрешни услуги, автоматизация на хранилища или ориентирани към клиента инструменти за разработчици. Удостоверяването вече може да представлява самото натоварване, а не всеки служител, който го е упълномощил.

От потребителски идентификационни данни до идентичност на приложението

Много интеграции на агенти започват с личен токен за достъп или други идентификационни данни, свързани с отделен програмист. Това може да е удобно по време на прототип, но създава проблеми, когато интеграцията стане постоянна услуга. Служителите сменят ролите си, идентификационните данни изтичат или се отменят, а одитните записи могат да направят автоматизираната дейност да изглежда като човешка.

Новият път на

GitHub използва инсталационен токен, издаден на приложение GitHub. Инсталационните токени са краткотрайни и обхванати от инсталацията и разрешенията на приложението, което ги прави по-подходящи за необслужвани работни натоварвания, отколкото дълготрайни потребителски идентификационни данни.

Разликата има значение за управлението. Една организация може да идентифицира приложението, отговорно за потреблението на Copilot, вместо да приписва всяка заявка на номинален оператор. GitHub включва поле app_client_id в CSV отчетите за използване на AI, което позволява на собствениците да отделят използването, произтичащо от приложението, по време на анализ.

За екипи, които изграждат AI API контролна равнина за екипи на разработчици, това е полезен модел за самоличност: човешки потребители, акаунти за автоматизация и внедрени приложения не трябва да споделят неразличими идентификационни данни или записи за фактуриране.

Таксуването следва организацията

Заявките, удостоверени по този начин, изразходват разрешението за Copilot на организацията и се управляват от нейните съществуващи моделни политики, бюджети и контрол на разходите. Това дава на администраторите едно място да решат кои модели може да използва дадено приложение и колко общи разходи за AI организацията ще позволи.

Това също означава, че собствениците на приложения не могат да третират достъпа сървър към сървър като независим пул от капацитет. Натоварената интеграция може да черпи от същия организационен бюджет като друга допустима дейност на Copilot. Екипите ще трябва да наблюдават автоматизираното потребление заедно с интерактивното използване и да решат как инцидентите, повторните опити и неочакваните цикли на заявки трябва да повлияят на споделените ограничения.

Текущият преглед не поддържа отделен бюджет за всяко приложение или инсталация. Полето app_client_id може да помогне при ретроспективно приписване, но отчитането по приложение не е еквивалентно на налагането на твърд таван за конкретно приложение. Организациите, които се нуждаят от изолация, все пак може да изискват собствен измервателен слой или AI API контроли на разходите за екипи пред автоматизирани работни натоварвания.

Какво трябва да променят разработчиците

Разработчиците, които приемат функцията, трябва да създадат GitHub приложение, да го инсталират в съответната организация и да обменят идентификационните данни на приложението за инсталационен токен. След това приложението използва този краткотраен токен, когато извиква през Copilot SDK. Следователно системите за внедряване трябва да обработват издаването и подновяването на токени, вместо да съхраняват статичен токен на разработчика за неопределено време.

Оперативните записи трябва да запазват както GitHub самоличността на приложението, така и организацията, таксувана за всяка заявка. Това е особено важно за платформи, обслужващи множество организации: токен, издаден за една инсталация, не трябва да се използва повторно за насочване на натоварването на друг клиент, а експортираните данни за използване трябва да бъдат съгласувани с правилния клиент.

Моделът също така засяга излизането от борда. Премахването на един разработчик вече не трябва да деактивира интеграция, собственост на организация, докато деинсталирането на GitHub приложението или промяната на неговите разрешения осигурява по-директен контрол върху самото приложение. Практическият резултат е по-ясно разделение между идентичността на работната сила и идентичността на работното натоварване.

Оставащите ограничения

Удостоверяването от сървър към сървър все още е публична предварителна версия, така че GitHub може да промени своя договор преди общата наличност. GitHub не е обявил поддръжка за инсталации на корпоративно ниво или лични акаунти чрез този път за удостоверяване.

Липсата на бюджети за приложение е най-непосредствената празнина в контрола. Организациите могат да видят кое приложение е генерирало използване, но все още не могат да присвоят на всяко приложение или инсталация независим бюджет на Copilot. Това става все по-важно, тъй като компаниите внедряват множество кодиращи агенти, услуги за преглед и автоматизирани хранилища в една организация.

Дори и с това ограничение, изданието установява по-ясен модел на собственост за машинно генерирания Copilot трафик. Удостоверяването, политиката и таксуването вече се свързват с инсталирано приложение и неговата организация, създавайки по-защитима основа за постоянна автоматизация от заетите идентификационни данни на програмист.