Управление платформой · MCP-gateway в проде
Модный способ подключить ИИ к инфраструктуре — дать модели shell и надеяться на лучшее. Мы сделали наоборот: у агента закрытый каталог инструментов, тиры автономии и подтверждение человеком для всего, что меняет состояние. Каждый вызов попадает в журнал, который нельзя переписать задним числом.
Постановка задачи
Мы хотели, чтобы дежурная смена разбирала обращения быстрее: «куда делось письмо от контрагента», «почему зона не отдаётся», «что с очередью на узле». Такие вопросы отнимают часы и состоят из одинаковых шагов. Но прежде чем пускать к ним модель, пришлось ответить на три возражения — и они справедливые.
Агент с shell-доступом может выполнить что угодно, включая то, чего никто не задумывал. Проблема даже не в злом умысле: одна убедительно сформулированная команда в контексте — и на узле выполняется не то, что имелось в виду.
Ответ: закрытый каталог глаголов вместо консоли
«ИИ починил» — не формулировка для разбора инцидента. Нужна запись: кто инициировал, какой инструмент, с какими аргументами, что ответил узел и кто из инженеров за это отвечает.
Ответ: пер-вызов журнал с цепочкой хэшей
Прочитать статус — безопасно. Перезапустить службу на боевом узле — решение, у которого должен быть автор с фамилией, а не «сессия агента».
Ответ: тиры автономии и подтверждение для T2
Почтовые запросы адресуют персональные данные третьих лиц. Грант на узел сам по себе не отвечает на вопрос «чьи это письма» — нужна вторая граница, по аргументам запроса.
Ответ: проверка домена на стороне hub, до узла
Как устроен допуск
Между запросом модели и командой на узле стоят каталог, политика, тир автономии и — для изменяющих действий — живой инженер. Ни одна из преград не является «настройкой по умолчанию, которую забыли включить»: без прохождения всех четырёх вызов не уходит в туннель.
Преграда 1
Список глаголов закрыт: у каждого своё имя, тир, тайм-аут и схема аргументов. Аргументы проверяются на hub до отправки на узел — лишнее поле или значение вне диапазона отклоняются. Свободного shell и произвольного SQL в каталоге нет.
Преграда 2
Разрешения описываются правилами: какому субъекту, на каких узлах, инструменты какого тира. Всё, что не разрешено явно, запрещено. Отдельным флагом любой глагол можно перевести в режим обязательного подтверждения, даже если он не T2.
Преграда 3
T0 — только чтение. T1 — идемпотентные действия, которые ничего не разрушают. T2 — изменяющие: агент формирует предложение, инженер подтверждает его в панели, и только тогда вызов уходит на узел.
Преграда 4
Почтовые глаголы адресуют данные третьих лиц, поэтому у них есть вторая граница: домен в запросе обязан принадлежать заказчику, которому принадлежит узел. Проверка выполняется на hub — узел не должен решать, чьи это данные.
Тиры автономии
Тир определяет не «насколько умная модель», а насколько обратимо действие. Он же уезжает в аннотации протокола: клиент видит, что инструмент только читает, что он идемпотентен и что каталог закрыт.
| Тир | Что это | Примеры | Кто разрешает |
|---|---|---|---|
| T0 | Чтение. Ничего не меняет, повтор безопасен | статус узла и служб, состояние DNSSEC, проверка зоны, сводка отчётов DMARC, трейс доставки письма | политика, автономно |
| T1 | Действие без разрушения. Повтор даёт тот же результат | повторная проверка узла после изменения — по одному такому глаголу в каждом семействе | политика, автономно |
| T2 | Изменяющее действие с последствиями | правка конфигурации узла, перезапуск службы или таймера | инженер, вручную в панели |
Ни один тир не даёт агенту доступа к data plane в обход узла: агент разговаривает только с hub, hub — только с узлом, и оба прыжка идут по протоколу с закрытым набором операций.
Что умеет агент
Каталог собран не «на всякий случай», а из вопросов, которые дежурная смена задаёт каждый день. Глагол привязан к типу узла: почтового инструмента на DNS-узле просто не существует — политика откажет раньше, чем узел успеет ответить ошибкой.
hub_*
Обзор платформы, список узлов и заказчиков, состояние туннелей и синхронизации, здоровье ОС и контейнеров, DNS-сводки и записи зон, проверка делегирования, сводка и «несопоставленные» отчёты DMARC, состояние DNSBL и источников Threat Intelligence, журнал самих MCP-вызовов. Всё это — чтение.
pmgagent_*
Статус узла и служб, состояние кластера, очередь, аудит DANE, здоровье ОС,
сверка контрольных сумм, журналы. Плюс почтовая аналитика поверх трекера
доставки: mail_trace — что происходило с письмами конкретного
отправителя или получателя за последние часы, mail_stats — агрегаты
по потоку. Один глагол тира T1 — повторная проверка.
dnsagent_*
Статус BIND и состояние DNSSEC, обход мастеров и обнаружение зон, синтаксическая проверка зоны, срабатывания RPZ, здоровье ОС, сверка контрольных сумм, журналы. Тот же принцип: чтение автономно, изменения — через подтверждение.
Практическая польза выглядит буднично. Вопрос «письмо от контрагента не дошло — где оно?» раньше означал ssh на узел, поиск по журналам и пересказ результата словами. Теперь это один вызов с ответом в структурированном виде — и запись в журнале о том, кто и зачем этот вызов сделал.
Доказуемость
Каждый вызов — отдельная запись. Записи связаны в цепочку: каждая включает хэш предыдущей, поэтому удалить строку или подправить аргументы постфактум нельзя — расходятся все последующие хэши.
Что попадает в запись
время 2026-08-02T09:14:07Z
субъект agent:идентификатор агента решение allow | deny | proposed
ответственный инженер, выдавший грант причина правило политики
узел mxa инструмент pmgagent_mail_trace (T0)
аргументы { sender: "…", hours: 48 } секреты замаскированы
результат краткая сводка ответа узла хэш sha256(предыдущий + запись)Экспорт — в машинный формат, пригодный для передачи в SIEM заказчика.
Рядом с агентом в записи стоит ответственный инженер — тот, кто выдал грант. «Это сделал ИИ» перестаёт быть объяснением: у каждого вызова есть человек, который за него отвечает.
В журнал попадает не только выполненное, но и отклонённое: какой глагол запрашивали, почему отказали, какое правило сработало. По этим записям видно, куда агент пытался пойти и где его остановили.
Пароли, токены и ключи в аргументах маскируются рекурсивно, до записи. Журнал можно отдавать в SIEM и показывать аудитору, не вычищая его руками.
Права выдаются под задачу и на время, с ограничением по узлам и инструментам, а не «постоянной учётной записью робота». Закончилась работа — грант истёк.
Честно
Раздел, которого обычно нет в материалах про ИИ. Он здесь, потому что технический ЛПР всё равно спросит, а служба безопасности спросит дважды.
В каталоге нет глагола, который отдаёт содержимое письма, — это проверяется списком инструментов. Почтовая аналитика работает поверх трекера доставки: кто, кому, когда, каков итог.
Почтовый запрос с доменом, который не принадлежит заказчику этого узла, отклоняется на hub — до туннеля и до узла. Отказ попадает в журнал.
Изменяющие действия проходят через подтверждение человеком. Автономны только чтение и узкий набор идемпотентных проверок.
Агент и панель живут в control plane и в тракт доставки не встроены. Отключите ИИ-часть целиком — почта продолжит ходить, а узлы продолжат фильтровать на последних правилах.
И про статус: MCP-gateway работает в нашем проде — на собственных почтовых и DNS-узлах платформы. Это не пилот на стенде и не план на квартал, но и не коробочный продукт, который мы продаём отдельно: это способ, которым мы эксплуатируем сервис, который вы покупаете. Доступ инженеров заказчика к чтению обсуждается в пилоте индивидуально.
Вопросы
Мы. Агент — инструмент дежурной смены MSCS, а не кабинет для заказчика. Клиент получает результат: более быстрый разбор обращения и журнал, по которому видно, что именно делали с его узлом и кто за это отвечал. Доступ инженеров заказчика к части глаголов на чтение технически возможен и обсуждается в пилоте отдельно — обещать его страницей мы не будем, пока он не работает у кого-то в проде.
Каталог. У агента нет ни консоли, ни свободного SQL: есть закрытый список глаголов с описанными аргументами. Глагола нет в каталоге — вызов отклонён на hub, до туннеля. Аргументы проверяются по схеме там же: нельзя передать лишнее поле или значение вне допустимого диапазона. Дополнительно действует политика с запретом по умолчанию, а тип узла у глагола свой — почтовый глагол на DNS-узле просто не существует.
Всё, что меняет состояние необратимо, отнесено к тиру T2 и работает по схеме «предложение → подтверждение»: агент формирует заявку, инженер подтверждает её в панели, и только после этого вызов уходит на узел. Автономно выполняются чтение (T0) и узкий набор идемпотентных действий вроде повторной проверки (T1). Ответственный инженер записан в журнале рядом с каждым вызовом.
Тела писем в каталоге нет — такого глагола не существует, и это проверяется списком инструментов. Почтовые глаголы работают поверх трекера доставки и отдают метаданные: кто, кому, когда, каков итог доставки. Выдача дополнительно ограничена доменами заказчика: домен в запросе должен принадлежать тому, чей это узел, и проверка выполняется на hub до отправки запроса на узел.
Каждый вызов пишется отдельной записью: время, агент, ответственный инженер, узел, инструмент, тир, решение, причина и аргументы с замаскированными секретами. Записи связаны в цепочку хэшей — каждая включает хэш предыдущей, поэтому задним числом нельзя ни удалить строку, ни подменить её незаметно. Экспорт — в машинный формат, пригодный для передачи в SIEM.
Ничего. Агент и панель управления живут в control plane и в тракт доставки писем не встроены: узлы фильтруют почту на последних полученных правилах и при недоступной панели. ИИ ускоряет разбор и эксплуатацию, но не является условием работы почты — это принципиальное решение, а не следствие текущей зрелости.
Дальше
На пилоте показываем экран панели: каталог глаголов, запись предложенного действия, подтверждение инженером и цепочку аудита. Обычно после этого вопрос «а безопасно ли пускать ИИ к инфраструктуре» превращается в вопрос «а что ещё вы так умеете».