Michael JohnsonШІ-агент може визначити, чому мережеве з’єднання працює з перебоями, а потім запропонувати виправлення, що впливає на робочу інфраструктуру. В інженерній статті від 13 жовтня Microsoft описала багаторівневу архітектуру, у якій окремі програмні правила обмежують доступ агента та перевіряють його дії.
Автор матеріалу Арун Малік, головний інженер Azure Networking у Microsoft, розглядає сценарій нестабільного з’єднання в центрі обробки даних. Агент збирає дані про стан пристроїв і телеметрію, зіставляє нещодавні зміни, класифікує збій і готує зведення. Потім система може перейти до виправлення — наприклад, вимкнути BGP-сеанс на пристрої, яким проходить користувацький трафік, — за допомогою передбачених архітектурою засобів контролю.
Microsoft описує чотири межі: ідентичність, інструменти, зміни й час. Агент діє в межах прав людини, яка його викликала, звертається до систем через контрольований інтерфейс, зупиняється перед зміною стану production-системи й чекає на підтвердження людини, а успішні повторювані процедури з часом можна закріплювати як детерміновані сценарії.
Права агента відповідають правам користувача
Перша межа — облікові дані. У запропонованій схемі агент діє від імені користувача й не отримує більше дозволів, ніж має той. Якщо потрібен сервісний обліковий запис, його права мають бути ще вужчими. Це обмежує наслідки помилки або шкідливого тексту в журналах і відповідях інструментів: модель не може отримати привілеї, яких немає в користувача чи виділеного облікового запису.
Друга межа — інструменти. Кожна операція оформлюється через типізований інтерфейс, проходить окрему авторизацію, приймає структуровані вхідні дані й залишає запис у журналі. Малік уточнює, що обмеження стосуються не самого командного рядка, а неконтрольованого доступу до оболонки: вузьку команду можна надати як контрольований інструмент, тоді як вільний доступ до shell ускладнює розмежування повноважень і аудит.
Для читання та змін потрібні різні правила
Діагностика в описаній архітектурі може виконуватися автоматично. Дія, що змінює стан production-системи, призупиняється до схвалення людиною. За словами автора, це обмеження має забезпечуватися кодом середовища виконання, а не лише інструкцією для моделі. Модель може обробити неструктурований вивід пристрою, але рішення про дію та перевірка дозволів залишаються за програмною логікою.
У статті наведено приклад із мережевим інтерфейсом: модель перетворює вивід команди на структуровані поля, валідатор звіряє їх зі схемою, а детермінована умова вибирає подальшу дію. Якщо крок змінює конфігурацію, виконання чекає на схвалення. Так текст завдання відокремлюється від повноважень змінювати мережу.
Четверта межа стосується повторюваності. Microsoft пропонує закріплювати перевірені шляхи діагностики як детерміновані сценарії, які у знайомих випадках можуть виконуватися без нового виклику моделі. За твердженням компанії, це скорочує витрати на повторне міркування, підвищує відтворюваність і зменшує поверхню для помилок та атак. У публікації не наведено кількісних результатів промислового впровадження.
Що варто перевірити під час упровадження
Матеріал Microsoft — інженерний опис архітектури та сценарію, а не незалежна оцінка надійності готового продукту. Практичний порядок дій для команд, які проєктують власних агентів: прив’язати дії до особи користувача, перелічити дозволені операції, типізувати й журналювати виклики, розділити читання та запис і вимагати чіткого підтвердження змін. Повторювані випадки можна переводити у звичайні сценарії після перевірки умов запуску й результату.
Основний висновок стосується розподілу ролей: модель допомагає розбирати невідомий інцидент і формувати структурований результат, а система виконання визначає, які операції дозволені та коли потрібне підтвердження. Саме такий розподіл Microsoft пропонує для переходу від підказок оператору до обмеженої автоматизації мережевої інфраструктури.