Michael JohnsonAI agent může určit, proč síťové připojení selhává, a poté navrhnout opravu, která zasahuje do provozní infrastruktury. V technickém článku z 13. října Microsoft popsala vrstvenou architekturu, v níž samostatná softwarová pravidla omezují přístup agenta a kontrolují jeho činnost.
Autor článku Arun Malik, hlavní inženýr Azure Networking ve společnosti Microsoft, rozebírá scénář nestabilního připojení v datacentru. Agent shromažďuje stav zařízení a telemetrii, porovnává nedávné změny, klasifikuje výpadek a připravuje souhrn. Poté může systém přejít k nápravě — například deaktivovat relaci BGP na zařízení přenášejícím uživatelský provoz — prostřednictvím kontrolních mechanismů stanovených architekturou.
Microsoft popisuje čtyři hranice: identitu, nástroje, změny a čas. Agent jedná v rozsahu oprávnění uživatele, který jej spustil, přistupuje k systémům prostřednictvím řízeného rozhraní, před změnou stavu produkčního prostředí se zastaví a vyžádá si potvrzení člověka; úspěšné opakované postupy lze časem ustálit jako deterministické scénáře.
Oprávnění agenta odpovídají oprávněním uživatele
První hranicí jsou přihlašovací údaje. V navrženém uspořádání agent jedná jménem uživatele a nedostává více oprávnění než on. Pokud je nutný servisní účet, jeho oprávnění mají být ještě užší. Tím se omezuje dopad chyby nebo škodlivého textu v protokolech a odpovědích nástrojů: model nemůže získat oprávnění, která nemá uživatel ani vyhrazený účet.
Druhou hranicí jsou nástroje. Každá operace se provádí prostřednictvím typovaného rozhraní, prochází samostatnou autorizací, přijímá strukturované vstupní údaje a zanechává záznam v protokolu. Malik upřesňuje, že problémem není samotný příkazový řádek, ale nekontrolovaný přístup k shellu: úzce vymezený příkaz lze zpřístupnit jako řízený nástroj, zatímco volný přístup k shellu ztěžuje oddělení oprávnění a audit.
Čtení a změny vyžadují odlišná pravidla
Diagnostiku lze v popsané architektuře provádět automaticky. Akce měnící stav produkčního systému se pozastaví, dokud ji neschválí člověk. Podle autora má toto omezení vynucovat kód běhového prostředí, nikoli pouze pokyn pro model. Model může zpracovat nestrukturovaný výstup zařízení, ale rozhodnutí o akci a kontrola oprávnění zůstávají na programové logice.
Článek uvádí příklad se síťovým rozhraním: model převede výstup příkazu na strukturovaná pole, validátor je porovná se schématem a deterministická podmínka zvolí další krok. Pokud krok mění konfiguraci, provedení čeká na schválení. Text zadání je tak oddělen od oprávnění měnit síť.
Čtvrtá hranice se týká opakovatelnosti. Microsoft navrhuje převádět ověřené diagnostické postupy na deterministické scénáře, které lze ve známých případech spustit bez dalšího volání modelu. Podle společnosti to snižuje náklady na opakované uvažování, zvyšuje reprodukovatelnost a zmenšuje prostor pro chyby a útoky. Publikace neuvádí kvantitativní výsledky nasazení v produkčním prostředí.
Co je vhodné před nasazením ověřit
Materiál Microsoftu je technickým popisem architektury a scénáře, nikoli nezávislým hodnocením spolehlivosti hotového produktu. Praktický postup pro týmy navrhující vlastní agenty: vázat akce na identitu uživatele, vyjmenovat povolené operace, typovat a zaznamenávat volání, oddělit čtení od zápisu a vyžadovat výslovné potvrzení změn. Opakované případy lze po ověření podmínek spuštění a výsledku převést na běžné scénáře.
Hlavní závěr se týká rozdělení rolí: model pomáhá analyzovat neznámý incident a vytvářet strukturovaný výstup, zatímco vykonávací systém určuje, které operace jsou povolené a kdy je třeba potvrzení. Právě takové rozdělení Microsoft navrhuje pro přechod od doporučení operátorovi k omezené automatizaci síťové infrastruktury.