GitHub zavedlo ověřování server-to-server pro aplikace vytvořené pomocí nástroje Copilot SDK, které umožňuje automatizovaným úlohám získat přístup k nástroji Copilot bez spoléhání se na přihlašovací údaje přihlášeného vývojáře.

Funkce zveřejněná ve veřejném náhledu 27. října využívá aplikaci GitHub nainstalovanou v organizaci. Aplikace získá krátkodobý instalační token a využití Copilota se připisuje a účtuje organizaci, která instalaci vlastní. Na požadavky aplikace se vztahují také modelové zásady, rozpočty a výdaje organizace.

To mění operační model pro týmy, které začleňují Copilota do interních služeb, automatizace úložišť nebo vývojářských nástrojů pro zákazníky. Autentizace nyní může představovat samotnou pracovní zátěž, nikoli toho, který zaměstnanec ji náhodou autorizoval.

Od přihlašovacích údajů uživatele k identitě aplikace

Mnoho integrací agentů začíná osobním přístupovým tokenem nebo jiným pověřením vázaným na jednotlivého vývojáře. To může být výhodné během prototypu, ale vytváří to problémy, když se integrace stane trvalou službou. Zaměstnanci mění role, platnost pověření vyprší nebo jsou odvolána a záznamy auditu mohou způsobit, že automatizovaná činnost bude vypadat jako lidská činnost.

Nová cesta

GitHub používá instalační token vydaný aplikaci GitHub. Instalační tokeny mají krátkou životnost a jejich rozsah závisí na instalaci a oprávněních aplikace, díky čemuž jsou vhodnější pro bezobslužné úlohy než dlouhodobé uživatelské pověření.

The distinction matters for governance. Organizace může identifikovat aplikaci odpovědnou za spotřebu Copilot namísto přiřazování každého požadavku jmenovitému operátorovi. GitHub obsahuje pole app_client_id v přehledech CSV o využití umělé inteligence, které vlastníkům umožňuje během analýzy oddělit použití pocházející z aplikace.

Pro týmy vytvářející AI API řídicí rovinu pro vývojářské týmy je to užitečný vzor identity: lidští uživatelé, automatizační účty a nasazené aplikace by neměly sdílet nerozeznatelné přihlašovací údaje nebo fakturační záznamy.

Billing follows the organization

Požadavky ověřené tímto způsobem spotřebovávají příspěvek organizace Copilot a řídí se jejími stávajícími modelovými zásadami, rozpočty a kontrolami výdajů. To dává administrátorům jedno místo, kde mohou rozhodnout, které modely může aplikace používat a jaké celkové výdaje na AI organizace povolí.

Znamená to také, že vlastníci aplikací nemohou přístup mezi servery považovat za nezávislý fond kapacity. Vytížená integrace může čerpat ze stejného organizačního rozpočtu jako jiná způsobilá aktivita Copilota. Týmy budou muset sledovat automatizovanou spotřebu spolu s interaktivním používáním a rozhodnout, jak by incidenty, opakování a neočekávané smyčky požadavků měly ovlivnit sdílené limity.

Aktuální náhled nepodporuje samostatný rozpočet pro každou aplikaci nebo instalaci. Pole app_client_id může pomoci se zpětnou atribucí, ale hlášení podle aplikace není ekvivalentní vynucení pevného stropu pro konkrétní aplikaci. Organizace, které potřebují izolaci, mohou stále vyžadovat vlastní měřicí vrstvu nebo AI API kontrolu výdajů pro týmy před automatizovanými úkoly.

What developers need to change

Vývojáři, kteří tuto funkci přijmou, musí vytvořit GitHub aplikaci, nainstalovat ji do příslušné organizace a vyměnit přihlašovací údaje aplikace za instalační token. Aplikace pak tento krátkodobý token použije při volání prostřednictvím Copilota SDK. Implementační systémy se proto musí zabývat vydáváním a obnovováním tokenů, nikoli ukládáním statického tokenu vývojáře na dobu neurčitou.

Provozní záznamy by měly uchovávat GitHub identitu aplikace i organizaci účtovanou za každý požadavek. To je důležité zejména pro platformy sloužící více organizacím: token vydaný pro jednu instalaci nesmí být znovu použit ke směrování pracovní zátěže jiného zákazníka a exporty využití by měly být odsouhlaseny se správným tenantem.

Model také ovlivňuje offboarding. Odstranění jednoho vývojáře již nemusí deaktivovat integraci vlastněnou organizací, zatímco odinstalování aplikace GitHub nebo změna jejích oprávnění poskytuje přímější kontrolu nad samotnou aplikací. Praktickým výsledkem je čistší oddělení identity pracovní síly a identity pracovní zátěže.

Zbývající limity

Ověření server-to-server je stále veřejný náhled, takže GitHub může změnit svou smlouvu před obecnou dostupností. GitHub neoznámil podporu pro instalace na podnikové úrovni nebo osobní účty prostřednictvím této ověřovací cesty.

Nejčastějším nedostatkem kontroly je nedostatek rozpočtů na jednotlivé aplikace. Organizace mohou vidět, která aplikace generovala využití, ale zatím nemohou každé aplikaci nebo instalaci přiřadit nezávislý rozpočet Copilot. To nabývá na významu, protože společnosti nasazují více kódovacích agentů, kontrolní služby a automatizaci úložišť pod jednou organizací.

I s tímto omezením zavádí vydání jasnější model vlastnictví pro strojově generovaný provoz Copilota. Autentizace, zásady a fakturace se nyní připojují k nainstalované aplikaci a její organizaci, což vytváří obhajitelnější základ pro trvalou automatizaci než vypůjčené přihlašovací údaje vývojáře.