GitHub bevezette a kiszolgálók közötti hitelesítést a Copilot SDK segítségével épített alkalmazásokhoz, lehetővé téve az automatizált munkaterhelések számára a Copilot elérését anélkül, hogy egy bejelentkezett fejlesztő hitelesítő adataira támaszkodna.
Az október 27-én nyilvános előnézetben megjelent funkció egy szervezetre telepített GitHub alkalmazást használ. Az alkalmazás egy rövid élettartamú telepítési tokent kap, és a másodpilóta használatot a rendszer a telepítést birtokló szervezethez rendeli és számlázza ki. A szervezet modellszabályzata, költségkerete és költségszabályozása az alkalmazás által benyújtott kérésekre is vonatkozik.
Ez megváltoztatja azoknak a csapatoknak a működési modelljét, amelyek a Copilotot belső szolgáltatásokba, adattár-automatizálásba vagy ügyfélközpontú fejlesztői eszközökbe ágyazzák. A hitelesítés most magát a munkaterhelést képviselheti, nem pedig azt, hogy melyik alkalmazott engedélyezte azt.
A felhasználói hitelesítő adatoktól az alkalmazásazonosítókig
Sok ügynökintegráció személyes hozzáférési tokennel vagy más, egy egyéni fejlesztőhöz kötött hitelesítési adattal kezdődik. Ez kényelmes lehet egy prototípus során, de problémákat okoz, ha az integráció tartós szolgáltatássá válik. Az alkalmazottak szerepkört váltanak, a hitelesítési adatok lejárnak vagy visszavonásra kerülnek, és az ellenőrzési rekordok az automatizált tevékenységeket emberi tevékenységnek tűnhetik.
AGitHub új elérési útja egy GitHub alkalmazáshoz kiadott telepítési tokent használ. A telepítési tokenek rövid életűek, és az alkalmazás telepítésén és engedélyein keresztül hatókörükhöz kapcsolódik, így jobban megfelelnek a felügyelet nélküli munkaterhelésnek, mint a hosszú élettartamú felhasználói hitelesítő adatok.
A megkülönböztetés a kormányzás szempontjából fontos. A szervezet azonosíthatja a másodpilóta fogyasztásért felelős alkalmazást ahelyett, hogy minden kérést egy névleges kezelőhöz rendelne. A GitHub tartalmaz egy app_client_id mezőt az AI-használati CSV-jelentésekben, amely lehetővé teszi a tulajdonosok számára, hogy az elemzés során elkülönítsék az alkalmazásból származó használatot.
Az AI API vezérlősíkot fejlesztő csapatok számára építő csapatok számára ez egy hasznos identitásminta: az emberi felhasználók, az automatizálási fiókok és a telepített alkalmazások nem oszthatnak meg megkülönböztethetetlen hitelesítő adatokat vagy számlázási rekordokat.
A számlázás a szervezetet követi
Az így hitelesített kérelmek a szervezet másodpilóta-juttatását veszik igénybe, és a meglévő modellszabályzatok, költségvetések és kiadásellenőrzések szabályozzák őket. Így az adminisztrátorok egy helyen dönthetik el, hogy egy alkalmazás mely modelleket használhatja, és mennyi összesített mesterséges intelligencia-költést enged meg a szervezet.
Ez azt is jelenti, hogy az alkalmazástulajdonosok nem kezelhetik a szerverek közötti hozzáférést független kapacitáskészletként. Egy elfoglalt integráció ugyanabból a szervezeti költségvetésből meríthet, mint a többi jogosult Copilot tevékenység. A csapatoknak figyelniük kell az automatizált fogyasztást az interaktív használat mellett, és el kell dönteniük, hogy az incidensek, az újrapróbálkozások és a váratlan kérések hogyan befolyásolják a megosztott korlátokat.
A jelenlegi előnézet nem támogatja az egyes alkalmazásokhoz vagy telepítésekhez külön költségkeretet. A app_client_id mező segíthet a visszamenőleges hozzárendelésben, de az alkalmazásonkénti jelentés nem egyenlő a szigorú alkalmazás-specifikus plafon érvényesítésével. Az elszigetelést igénylő szervezeteknek továbbra is szükségük lehet saját mérési rétegre vagy AI API ráfordításvezérlőkre a csapatok számára az automatizált munkaterhelések előtt.
Amit a fejlesztőknek változtatniuk kell
A funkciót alkalmazó fejlesztőknek létre kell hozniuk egy GitHub alkalmazást, telepíteni kell a megfelelő szervezetre, és az alkalmazás hitelesítő adatait telepítési tokenre kell cserélniük. Az alkalmazás ezután ezt a rövid életű tokent használja, amikor a másodpilóta SDK-on keresztül hív. A telepítési rendszereknek ezért kezelniük kell a token kiadását és megújítását, nem pedig a statikus fejlesztői tokent korlátlan ideig tárolniuk.
A működési rekordoknak meg kell őrizniük a GitHub alkalmazásazonosítót és az egyes kérésekért felszámított szervezetet. Ez különösen fontos a több szervezetet kiszolgáló platformok esetében: az egyik telepítéshez kiadott tokent nem szabad újra felhasználni egy másik ügyfél munkaterhelésének irányítására, és a használati exportálást össze kell egyeztetni a megfelelő bérlővel.
A modell az offboardozásra is hatással van. Egy fejlesztő eltávolításával többé nem kell letiltani a szervezet tulajdonában lévő integrációt, míg a GitHub alkalmazás eltávolítása vagy az engedélyek módosítása közvetlenebb ellenőrzést biztosít magának az alkalmazásnak. A gyakorlati eredmény a munkaerő-azonosság és a terhelési identitás tisztább elválasztása.
A fennmaradó korlátok
A kiszolgálók közötti hitelesítés továbbra is nyilvános előzetes, így a GitHub módosíthatja a szerződését az általános elérhetőség előtt. GitHub nem jelentette be, hogy támogatja a vállalati szintű telepítéseket vagy a személyes fiókokat ezen a hitelesítési útvonalon keresztül.
Az alkalmazásonkénti költségkeretek hiánya a legközvetlenebb ellenőrzési hiányosság. A szervezetek láthatják, hogy melyik alkalmazás generált használatot, de még nem rendelhetnek minden alkalmazáshoz vagy telepítéshez független másodpilóta költségvetést. Ez egyre jelentősebbé válik, mivel a vállalatok több kódoló ügynököt telepítenek, áttekintő szolgáltatásokat és adattár-automatizálásokat helyeznek el egyetlen szervezet alatt.
A kiadás még ezzel a korlátozással is tisztább tulajdonosi modellt hoz létre a gép által generált másodpilóta forgalom számára. A hitelesítés, a házirend és a számlázás mostantól egy telepített alkalmazáshoz és annak szervezetéhez kapcsolódik, így a kölcsönzött fejlesztői hitelesítő adatoknál védhetőbb alapot teremt a tartós automatizáláshoz.