Michael JohnsonAgent AI może ustalić, dlaczego połączenie sieciowe działa nieprawidłowo, a następnie zaproponować rozwiązanie ingerujące w działającą infrastrukturę. W artykule inżynieryjnym z 13 października Microsoft opisał warstwową architekturę, w której odrębne reguły programowe ograniczają dostęp agenta i sprawdzają jego działania.
Autor materiału, Arun Malik, główny inżynier Azure Networking w Microsoft, omawia scenariusz niestabilnego połączenia w centrum danych. Agent zbiera stan urządzeń i telemetrię, porównuje ostatnie zmiany, klasyfikuje awarię i przygotowuje podsumowanie. Następnie system może przejść do naprawy — na przykład wyłączyć sesję BGP na urządzeniu obsługującym ruch użytkowników — korzystając ze środków kontroli przewidzianych w architekturze.
Microsoft opisuje cztery granice: tożsamość, narzędzia, zmiany i czas. Agent działa w granicach uprawnień osoby, która go uruchomiła, komunikuje się z systemami przez kontrolowany interfejs, zatrzymuje się przed zmianą stanu środowiska produkcyjnego i czeka na zatwierdzenie przez człowieka, a sprawdzone, powtarzalne procedury można z czasem utrwalić jako deterministyczne scenariusze.
Uprawnienia agenta wynikają z uprawnień użytkownika
Pierwszą granicą są dane uwierzytelniające. W proponowanym schemacie agent działa w imieniu użytkownika i nie otrzymuje szerszych uprawnień. Jeśli potrzebne jest konto usługi, jego uprawnienia powinny być jeszcze węższe. Ogranicza to skutki błędu lub złośliwego tekstu w logach i odpowiedziach narzędzi: model nie może uzyskać uprawnień, których nie ma użytkownik ani wydzielone konto.
Drugą granicą są narzędzia. Każda operacja jest udostępniana przez typowany interfejs, podlega osobnej autoryzacji, przyjmuje ustrukturyzowane dane wejściowe i pozostawia wpis w dzienniku. Malik wyjaśnia, że ograniczeniu podlega nie sama linia poleceń, lecz niekontrolowany dostęp do powłoki: wąskie polecenie można udostępnić jako kontrolowane narzędzie, natomiast swobodny dostęp do powłoki utrudnia rozdzielenie uprawnień i audyt.
Odczyt i zmiana wymagają odrębnych reguł
Diagnostyka w opisanej architekturze może odbywać się automatycznie. Działanie zmieniające stan systemu produkcyjnego zostaje wstrzymane do czasu zatwierdzenia przez człowieka. Według autora ograniczenie to powinno być egzekwowane przez kod środowiska wykonawczego, a nie wyłącznie przez instrukcję dla modelu. Model może analizować nieustrukturyzowane dane wyjściowe urządzenia, ale decyzja o działaniu i kontrola uprawnień pozostają po stronie logiki programowej.
W artykule podano przykład interfejsu sieciowego: model przekształca wynik polecenia w ustrukturyzowane pola, walidator sprawdza je względem schematu, a deterministyczny warunek wybiera dalsze działanie. Jeśli krok zmienia konfigurację, wykonanie czeka na zatwierdzenie. W ten sposób treść zadania jest oddzielona od uprawnień do modyfikowania sieci.
Czwarta granica dotyczy powtarzalności. Microsoft proponuje utrwalanie sprawdzonych ścieżek diagnostycznych jako deterministycznych scenariuszy, które w znanych przypadkach mogą działać bez ponownego wywoływania modelu. Według firmy ogranicza to koszty ponownego wnioskowania, zwiększa powtarzalność wyników i zmniejsza powierzchnię błędów oraz ataków. Publikacja nie przedstawia ilościowych wyników wdrożenia przemysłowego.
Co warto sprawdzić przed wdrożeniem
Materiał Microsoftu to inżynieryjny opis architektury i scenariusza, a nie niezależna ocena niezawodności gotowego produktu. Praktyczna kolejność działań dla zespołów projektujących własnych agentów: powiązać działania z tożsamością użytkownika, określić dozwolone operacje, typować i rejestrować wywołania, oddzielić odczyt od zapisu oraz wymagać wyraźnego zatwierdzenia zmian. Powtarzalne przypadki można przekształcać w zwykłe procedury po sprawdzeniu warunków uruchomienia i wyników.
Główny wniosek dotyczy rozdzielenia ról: model pomaga analizować nieznany incydent i tworzyć ustrukturyzowany wynik, a system wykonawczy określa, które operacje są dozwolone i kiedy potrzebne jest zatwierdzenie. Taki właśnie podział Microsoft proponuje jako drogę od podpowiedzi dla operatora do ograniczonej automatyzacji infrastruktury sieciowej.