Michael JohnsonИИ-агент может определить, почему сбоит сетевое соединение, а затем предложить исправление, затрагивающее рабочую инфраструктуру. В инженерной статье от 13 октября Microsoft описала слоистую архитектуру, в которой отдельные программные правила ограничивают доступ агента и проверяют его действия.
Автор материала, Арун Малик, главный инженер Azure Networking в Microsoft, разбирает сценарий нестабильного соединения в дата-центре. Агент собирает состояние устройств и телеметрию, сопоставляет недавние изменения, классифицирует сбой и готовит сводку. Затем система может перейти к исправлению — например, отключению BGP-сессии на устройстве с пользовательским трафиком — через предусмотренные архитектурой средства контроля.
Microsoft описывает четыре границы: идентичность, инструменты, изменения и время. Агент действует в пределах прав вызвавшего его человека, обращается к системам через контролируемый интерфейс, останавливается перед изменением production-состояния для подтверждения человеком, а успешные повторяемые процедуры со временем можно закреплять как детерминированные сценарии.
Права агента следуют за правами пользователя
Первая граница — учётные данные. В предложенной схеме агент действует от имени пользователя и не получает больше его разрешений. Если необходима сервисная учётная запись, её права должны быть ещё уже. Это ограничивает последствия ошибки или вредоносного текста в логах и ответах инструментов: модель не может получить привилегии, которых нет у пользователя или выделенной учётной записи.
Вторая граница — инструменты. Каждая операция оформляется через типизированный интерфейс, проходит отдельную авторизацию, принимает структурированные входные данные и оставляет запись в журнале. Малик уточняет, что ограничивают не саму командную строку, а неуправляемый доступ к оболочке: узкую команду можно предоставить как контролируемый инструмент, тогда как свободный shell затрудняет разграничение полномочий и аудит.
Чтение и изменение требуют разных правил
Диагностика в описанной архитектуре может выполняться автоматически. Действие, меняющее состояние production-системы, приостанавливается до одобрения человека. По словам автора, это ограничение должно обеспечиваться кодом исполнительной среды, а не только инструкцией модели. Модель может разобрать неструктурированный вывод устройства, но решение о действии и проверка разрешений остаются за программной логикой.
В статье приведён пример с сетевым интерфейсом: модель преобразует вывод команды в структурированные поля, валидатор сверяет их со схемой, а детерминированное условие выбирает дальнейшее действие. Если шаг меняет конфигурацию, выполнение ждёт одобрения. Таким образом, текст задачи отделён от полномочий на изменение сети.
Четвёртая граница касается повторяемости. Microsoft предлагает закреплять проверенные пути диагностики как детерминированные сценарии, которые в знакомых случаях могут выполняться без нового вызова модели. По утверждению компании, это сокращает расходы на повторное рассуждение, повышает воспроизводимость и уменьшает поверхность для ошибок и атак. В публикации не приведены количественные результаты промышленного внедрения.
Что полезно проверить при внедрении
Материал Microsoft — инженерное описание архитектуры и сценария, а не независимая оценка надёжности готового продукта. Практический порядок для команд, проектирующих собственных агентов: привязать действия к личности пользователя, перечислить разрешённые операции, типизировать и журналировать вызовы, разделить чтение и запись и требовать явного подтверждения для изменений. Повторяемые случаи можно переводить в обычные сценарии после проверки условий запуска и результата.
Основной вывод относится к разделению ролей: модель помогает разбирать неизвестный инцидент и формировать структурированный вывод, а исполнительная система определяет, какие операции разрешены и когда нужно подтверждение. Именно такое разделение Microsoft предлагает для перехода от подсказок оператору к ограниченной автоматизации сетевой инфраструктуры.