«Остановитесь в поисках единственной защиты — её нет»: инженер Microsoft разложил автономию агента в проде на четыре границы

«Агент знает исправление»: где демо перестаёт быть демо

Материал начинается со сцены, знакомой каждому дежурному: два часа ночи, сработал пейджер, линк где-то в дата-центре начал флапать, несколько алермов скоррелировались в один инцидент, и on-call инженер делает то, что делали всегда — открывает пять вкладок, по одной на систему, и собирает картину случившегося из фрагментов.

Microsoft построила ИИ-агента, который делает эту реконструкцию сам: тянет состояние устройства, читает телеметрию, сопоставляет недавние изменения, классифицирует отказ и пишет чистую сводку в инцидент раньше, чем человек закончил логиниться; он же знает и исправление. По словам автора, именно здесь демо заканчивается: если агент «знает исправление», вопрос в том, разрешать ли системе погасить BGP-сессию на устройстве, через которое идёт живой клиентский трафик — чтение можно перепроверить, а запись это действие, которое уже произошло. Как только агент получает возможность менять продакшн, все свойства, на которые можно было не обращать внимания на этапе чтения, становятся источником клиентского риска.

Отсюда неудобный вывод, к которому авторы возвращаются несколько раз: нет одной вещи, которую можно построить, чтобы агент стал безопасен в проде — ни более умная модель, ни более строгий промпт, ни хитрый guardrail; безопасная автономия требует стека.

Агент — это не модель

Прежде чем строить слои, автор разбирается с определением: спросите десять разработчиков, что такое агент, и получите десять ответов, причём большинство из них будут примерами, а не определениями — и эта размытость скрывает главное. Его формулировка: агент — не модель; модель это блистательная недетерминированная часть в середине, а агент — детерминированный софт вокруг неё, та часть, которая решает, о чём модель спрашивают, что ей позволено сделать с ответом, до каких инструментов она дотягивается и что происходит, когда она ошибается.

Модель поставляет интеллект, агент поставляет суждение о том, насколько этому интеллекту доверять и чего ему можно касаться. С такой рамкой интересная инженерия в агентной системе — это обычно обёртка, а весь вопрос безопасности переформулируется: сделать агента безопасным — это меньше про умную модель в середине и больше про лучшую детерминированную оболочку вокруг неё.

Конкретно оболочка, которую авторы натягивают на модель при исполнении, — это в основном детерминированный workflow с несколькими узкими шагами модели, проверяемыми по схеме: именно она превращает «модель один раз что-то сообразила» в «эти шаги выполняются одинаково каждый раз». Как это называть — harness, агент, оркестратор, playbook — не важно; несущая идея одна: детерминированный софт осознанно и в заданных пределах использует недетерминированную модель.

«Сложное в автономии — авторизация, а не интеллект»

Отрицательный пример у автора выглядит так: представьте, что агенту дали сервисный аккаунт с широким доступом, shell, способный выполнить что угодно, и суровый системный промпт со списком всего, чего делать нельзя. Всё нужное для починки проблемы у такого агента есть, но что именно мешает ему совершить действие, которое совершать не следовало?

Ответ разложен по частям: широко привилегированный сервисный аккаунт даёт агенту больше доступа, чем у позвавшего его человека; неограниченный shell затягивает в радиус поражения всё, до чего дотягивается аккаунт и машина; системный промпт помогает направлять поведение, но не может обеспечить права, — модель может неверно понять инструкцию или попасть под влияние вредоносного текста в логе или в ответе инструмента. Вывод, который авторы формулируют прямо: безопасность продакшна не может зависеть только от инструкций модели.

Отсюда их тезис: трудная часть автономии — авторизация, а не интеллект. Современные модели пугающе хорошо соображают, как исправить проблему, и настоящий вопрос звучит иначе: что этой штуке разрешено делать, под чьей личностью, через какой интерфейс и с чьим согласием — скучно, детерминированно и есть вся игра.

Четыре границы: личность, инструмент, мутация, время

Как только границы начали складывать стопкой, архитектура распалась на четыре слоя — Identity, Tool, Mutation, Time; каждый отвечает на свой вопрос, ни один не достаточен сам по себе, и в этом суть. Прочитанные одним предложением, они звучат так: агент действует только как позвавший его человек (личность), добирается до продакшна только через контролируемый интерфейс (инструмент), читает свободно, но обязан остановиться перед любым изменением (мутация) и тем меньше зависит от живого рассуждения, чем чаще он это делает (время). Два слоя из четырёх — контроль безопасности в буквальном смысле: права на личность и доступ к инструментам это место, где орудует злоумышленник или галлюцинация, поэтому самые твёрдые стены стоят там.

Личность: агент не получает собственный мощный аккаунт, он действует от имени позвавшего его человека и ограничен реальными правами этого человека; там, где сервисную личность не обойти, берётся более узкая из двух — личность составная (человек плюс агент), и побеждает строгая. Политики доступа при этом принадлежат командам, владеющим инструментами, описаны по каждому инструменту и меняются обычным pull request, где команда-владелец обязательный ревьюер: merge выдаёт доступ, revert его отзывает.

Инструмент: агент никогда не получает голый shell — всё, что он умеет, стоит за единым типизированным интерфейсом инструментов, каждый инструмент авторизуется отдельно, каждый вызов структурирован и залогирован. Формулировка автора точная: враг не командная строка, а неограниченная. Сырой shell нельзя управлять, потому что вокруг bash не поставить ни границу прав, ни схему, ни чистый аудит, а командная строка, вызванная как один узкий объявленный инструмент за интерфейсом, — можно. Поэтому «MCP против CLI» — ложная дихотомия: нужны оба, выбранные по уровню доверия, — обычная функция или sandboxed CLI для низкорисковых локальных работ внутри доверенной границы, и MCP для всего, что её пересекает, поскольку MCP бесплатно даёт минимальные привилегии, изоляцию учётных данных, структурированный аудит, хуки человеческого одобрения и ограничение скорости.

Мутация: диагностика идёт сама, а любое изменение продакшна останавливается и ждёт человека. Автор честно называет это место самым трудным: соблазн пропустить «безопасно выглядящие» записи велик, а авторы не пропускают — ворота это код в движке исполнения, а не строка в промпте, а доверие пропустить ворота заработано по процедуре и по типу действия, но никогда не выдано модели за то, что она умная.

Время: в первый раз инцидент разбирается рассуждением от начала до конца, что дорого и недетерминированно, но большинство инцидентов не новы — когда один и тот же путь рассуждения оказывается успешным достаточно часто, его кристаллизуют в детерминированный playbook, работающий с нулём вызовов модели. Агент становится механизмом обнаружения новых проблем, а не постоянным налогом на старые, а меньше живого рассуждения означает сразу и меньшую стоимость, и более высокую воспроизводимость, и меньшую поверхность и для галлюцинации, и для атаки.

Конкретный инцидент: `show interface status`

Дальше автор делает разбор на примере того самого инцидента, потому что он показывает, где одиночный контроль отказал бы. Агент получает от устройства вывод show interface status — это неструктурированный текст, и это как раз та работа, которую языковая модель делает хорошо, поэтому парсить дают ей, но решать ей не дают. Выход модели ограничен схемой (interface: string; status: enum[connected, errdisabled, notconnect]; vlan: int), затем проверяется детерминированным assert — «status in [connected, errdisabled, notconnect]», и только после этого обычный детерминированный код выбирает действие: при status == 'errdisabled' вызывается recover-interface, шаг записи, который останавливается на человеческое одобрение, иначе объявляется no-action.

В самом playbook это записано как шаг извлечения с комментарием «LLM parses unstructured CLI output into typed JSON», шаг проверки с комментарием «deterministic: reject anything off-schema», шаг решения с комментарием «deterministic: no model in the decision» и переход «then: recover-interface # a WRITE step -> pauses for human approval». Это и есть паттерн, который авторы называют deterministic skeleton, probabilistic filling: языковая модель здесь семантический парсер, она никогда не решатель и никогда не держит учётные данные, которыми исполняется изменение.

Почему одного слоя всегда мало

На более сложном запросе — сгенерировать BGP-конфигурацию для нового устройства — та же система выдаст нечто совершенно корректное на вид, но достаточно часто, чтобы это имело значение, изобретёт ASN, сошлётся на несуществующую route policy или тихо пропустит конвенцию конкретного дата-центра, которой никакой промптинг надёжно не научит. Генерация конфигураций — синтез нового (novel synthesis), самое ненадёжное, что делает модель, и одновременно самое рискованное, потому что результат попадает рядом с продакшном.

Дальше автор прогоняет контрфактику по одному слою за раз. Уберите личность — агент работает с «god-mode»-учётными данными, и галлюцинированный конфиг отправляется с полномочиями, которых не было ни у кого из участников того созвона. Уберите интерфейс инструментов и дайте голый shell — не останется даже способа назвать «отправку BGP-конфига» отдельным, авторизуемым и аудируемым действием: это просто ещё одна команда, к которой некуда прикрепить RBAC или ворота одобрения. Уберите ворота мутации — выдуманный ASN дойдёт до устройства, потому что конфиг выглядел нормально и никто не остановился спросить. Уберите время и кристаллизацию — вы платите полную недетерминированную стоимость рассуждения на каждом рутинном инциденте вечно, то есть гоняете самый рискованный режим исполнения даже на задачах, решённых месяцы назад.

Каждое удаление ломает систему, и каждое ломает её по-своему: нет одной точки, укрепив которую можно закрыть все четыре — именно это и означает defense in depth. Автор видит здесь общий сдвиг: в этой области растёт консенсус, что политика это то, что обязан обеспечивать runtime, а не то, о чём просят модель. Microsoft направила этот инстинкт на физическую инфраструктуру, и отличие, по его словам, в одном: когда их runtime ошибается, радиус поражения — не плохой pull request, а клиентский трафик, и это неприемлемо.

Что здесь проверено, а что остаётся инженерной позицией

Честная оговорка, которую стоит держать в голове: это инженерный разбор, а не анонс и не отчёт об испытаниях. В тексте нет ни одного измерения — ни задержек, ни стоимости, ни числа обработанных инцидентов, ни доли успешных автоматических исправлений; нет названий моделей, участвующих в шагах, нет имён заказчиков и нет сроков, то есть нет ни одного числа, которое можно было бы перепроверить на сторонних данных.

Релизом материал тоже не является: продукт, API, цена и дата доступности в нём не объявлены, а сам он опубликован в Microsoft Command Line — издании Microsoft для инженеров (в подвале страницы стоит «A Microsoft publication»), у текста есть автор: Arun Malik, Principal Software Engineer, Azure Networking, Microsoft, дата 2026.10.13.

Полезное здесь — не результат, а конструкция: четыре границы, каждая отказывает закрыто, и асимметрия «читай свободно, меняй только с человеком», которую можно примерить к собственному стеку. Косвенное подтверждение, что это не одиночная заметка в блоге, а линия издания: страница ведёт к соседним deep dive того же Command Line — «Introducing Microsoft-Decision-1, our model for fast decision-making» (9 октября 2026) и «Bringing local models and sandboxed tools to Windows and GitHub Copilot» (7 октября 2026), и оба этих материала уже разобраны в нашем архиве.

Вывод автора — прямым текстом: если команда переходит от copilot к autopilot, самое полезное, что можно ей сказать, — перестать искать защиту, потому что её нет; нужно выбрать четыре границы или свой эквивалентный набор и построить их как отдельные детерминированные слои, каждый из которых отказывает закрыто, а затем позволить модели быть блистательной внутри них — стек и есть автопилот.