MITR

Руководителю организации: действия автономных агентов как вопрос ответственности

Раздел адресован генеральному директору, собственнику бизнеса и членам совета директоров — тем, кто принимает решение о внедрении автономных агентов и отвечает за его последствия.

MITR отвечает на все три вопроса квитанцией, которая формируется автоматически при каждом действии агента.

Принцип работы

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

Проверка одного действия занимает единицы миллисекунд. Агент выполняет разрешённые операции без ожидания ручных согласований, а служба безопасности получает проверяемый журнал решений.

Что получает организация

• Предотвращение ущерба вместо его расследования: в режиме запрета действие, допустимость которого не доказана, не исполняется. Защиту начинают с необратимых действий: удаления данных, платежей и отправки информации за периметр.
• Доказательную базу для проверок и споров: вместо пояснительной записки организация предъявляет выборку квитанций: какие действия совершал агент, на основании каких правил они были разрешены, что было остановлено и почему.
• Свободу выбора поставщиков искусственного интеллекта: MITR безразлично, какая модель предложила действие — отечественная или зарубежная, открытая или закрытая: он проверяет само действие. Агентов можно менять, не пересматривая защиту.
• Собственные правила: правило допуска хранится как файл данных, и служба информационной безопасности добавляет или изменяет правила без переписывания программного кода.

Как MITR закрывает риски организации

Каждому риску, который возникает с приходом агентов, соответствуют механизм MITR и проверяемый результат.

Чем ИБ 3.0 отличается от привычной защиты

Безопасность прежних поколений (ИБ 2.0) исходит из допущения, что внутри периметра работают свои сотрудники, а угроза приходит снаружи. Автономный агент снимает это допущение: программа работает внутри защищённого периметра без статуса должностного лица, а её ошибка или скрытая в прочитанном документе команда злоумышленника оформляется как штатный вызов.

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

Подробнее о трёх поколениях защиты — в разборе «ИБ 3.0: что это такое и какую задачу решает».

Подключение агентов по протоколу MCP — с доказательством и квитанцией

Автономные агенты подключаются к инструментам и информационным системам по открытому протоколу MCP (Model Context Protocol). Протокол играет роль розетки единого образца: любой агент подключается к любой системе — базе данных, почте, учётной программе, репозиторию кода. Протокол определяет, как подключиться, но не отвечает на вопрос, допустимо ли конкретное действие.

подключение через MITR = протокол MCP + доказательство допустимости до исполнения + квитанция после него

Для агента подключение через MITR ничем не отличается от обычного: MITR отвечает по протоколу MCP как обычный сервер, а открытый пакет устанавливается как обёртка вокруг уже подключённого MCP-сервера. Для организации у каждого вызова появляются разрешение и след.

Возможности действующей версии

Действующая версия MITR работает непрерывно с 24 апреля 2026 года: через MITR проходят действия кодовых агентов и служебных ботов института. Ниже перечислены возможности, которые действующая версия предоставляет уже сейчас.

Путь внедрения

Внедрение проходит шесть шагов, и ни на одном из них работа агентов не останавливается. Состав поставки, требования к площадке и сроки по ступеням описаны на странице «Пилот MITR у заказчика».

1. Пробная установка: специалист разворачивает открытый пакет на своей машине без доступа в сеть и проверяет механизм на собственных сценариях.
2. Обследование: составляется перечень агентов, систем, к которым они подключены, и действий, которые они совершают, а необратимые действия выделяются отдельно.
3. Правила допуска: политика организации переводится в правила допуска, которые служба информационной безопасности читает и изменяет без изменения программного кода.
4. Наблюдение: MITR встраивается в разрыв между агентами и системами в режиме наблюдения: действия не задерживаются, решения записываются. Через 30 суток организация получает отчёт о том, какие действия совершались, какие были бы остановлены, по какому правилу и какова доля ложных остановок.
5. Запрет: классы необратимых действий — удаление данных, платежи, отправка информации за периметр — поочерёдно переводятся в режим запрета после того, как по каждому из них определена доля ложных остановок.
6. Эксплуатация: квитанции становятся материалом для внутреннего аудита и проверок регулятора. Для значимых объектов КИИ и закрытых сетей MITR разворачивается на собственных серверах заказчика.

Регулирование и КИИ

Применение автономных агентов не освобождает организацию от действующих требований к защите информации. Шлюз MITR обеспечивает соблюдение этих норм на участках, где операцию вместо сотрудника вызывает программный агент.

Перечень сверен с действующими редакциями актов. Проверено: 18.10.2026. Приведённый обзор служит справочным ориентиром по действующим нормам; вывод о применимости требований к конкретной системе делает сама организация. Разбор приказа № 117 — в материале «Приказ ФСТЭК № 117 и искусственный интеллект».

Позиция на рынке

Рынок средств защиты систем искусственного интеллекта в России уже сформирован, и отличие MITR определяется предметом проверки: проверяется действие, решение принимает решатель, а квитанцию перепроверяет сторонний специалист.

Чем MITR отличается от известных решений

Проверка действия по правилу появилась не в MITR: ей посвящены промышленные системы авторизации и исследовательские работы о защите агентов. Ниже шесть решений, с которыми MITR сравнивают чаще всего, и признаки, по которым они расходятся; каждое описание взято из первоисточника в последнем столбце и сверено 26 октября 2026 года.

Отличие MITR складывается из трёх признаков, взятых вместе. Решатель выносит доказательство по каждому действию, а не по политике целиком, как Zelkova, и не простым вычислением правила, как Open Policy Agent и Cedar. Факты для доказательства MITR берёт из источников, назначенных организацией, и в этом он ближе всего к разделению потоков данных в CaMeL. Каждое решение оставляет квитанцию в цепи с внешней меткой времени, которую посторонний пересчитывает без участия разработчика: журнал решений есть и у Open Policy Agent, но цепи и метки времени в его описании нет.

У сравнения есть и обратная сторона. Модель языка Cedar построена в средстве доказательства Lean, тогда как код MITR формальной проверки ещё не проходил, и собственный компактный решатель с дедуктивной проверкой кода стоит в программе работ. Zelkova и Cedar работают в промышленном масштабе облачного поставщика, а MITR пока держит действия агентов самого института, и первой внешней площадкой станет пилот у заказчика.

Специалисту по безопасности и архитектору: устройство, протокол, проверка

Раздел адресован руководителю службы информационной безопасности, архитектору информационных систем и инженеру по безопасности, которым руководитель направил эту страницу. Здесь изложено, что именно проверяется, как подключается MITR, что он возвращает, как ведёт себя при отказе и где проходят границы его применимости.

Предмет проверки

Шлюз MITR проверяет сам вызов внешнего инструмента: имя операции, её аргументы, адресата и наблюдаемые факты. Рассуждение модели вероятностно и правилами не регулируется; вызов дискретен, поэтому его допустимость решается формально и до исполнения. Контроль одной модели другой отвергнут по построению: надзирающая модель уступает поднадзорной в разнообразии (закон необходимого разнообразия Эшби), а её вердикт сам остаётся вероятностным.

Как принимается решение

• Правило допуска (контракт) — файл данных, в котором заданы посылки, условие безопасности и класс действия. Решатель SMT доказывает, что при переданных фактах действие не нарушает условия безопасности. Если доказательство не получено, действие не допускается.
• Для каждого класса действий задаётся один из трёх режимов: наблюдение (решение записывается, действие не задерживается), предупреждение (агент получает предупреждение) или запрет (недоказанное действие не исполняется).
• Ответ MITR содержит вердикт, а при отказе — перечень нарушенных условий правила и варианты исправления. К ответу прилагается квитанция с порядковым номером и хешем по алгоритму безопасного хеширования SHA (вариант SHA-256), сцепленным с предыдущей записью.
• Словарь распознаваемых действий пополняется по журналу обращений: предложенное правило принимается только после прогона на корпусе прежних действий, через ту же проверку и с квитанцией. Первое такое правило вошло в словарь 25 сентября 2026 года.

Поведение при отказе

• Сбой проверки внутри MITR приводит к отказу: действие не проходит и тогда, когда доказательству помешала ошибка.
• Действие, которого правила не распознали, считается недоказанным. С 24 октября 2026 года для таких действий включён запрет по умолчанию, а само обращение направляется в разбор словаря.
• Недоступность узла проверки для класса в режиме запрета автоматически переводит вызов в состояние отказа; с 24 октября 2026 года закрепление этого правила во всех точках подключения подтверждено прибором проверки обхода.

Цифры замеров

Замеры сняты на рабочем сервере института. Разброс задержки под промышленной нагрузкой определяется на совместном стенде.

Подключение

• По протоколу MCP: MITR подключается как обычный MCP-сервер, адрес и токен выдаются при внедрении.
• HTTP-вызовом проверки из собственного кода до исполнения действия — с тем же ответом и той же квитанцией.
• Обёрткой вокруг собственного MCP-сервера с помощью открытого пакета mcp-sentinel; быстрый старт приведён ниже.
• Одним импортом в агент на Python с помощью открытого пакета iss-agent-kit.

Где хранятся данные

Пробные пакеты работают целиком на машине специалиста — без сети, без учётной записи и без обращения к серверам института. Размещение MITR при внедрении согласуется с заказчиком; для значимых объектов КИИ и закрытых сетей шлюз разворачивается в инфраструктуре заказчика.

Что предъявляется проверяющему

Проверяющему предъявляется выборка из цепи квитанций: действие, правило, факты, вердикт и время. Целостность цепи пересчитывается открытым проверщиком на стандартной библиотеке Python без установки ПО института. Якоря цепи MITR и проверщик опубликованы на asi5.ru/console/verify/.

Границы применимости

Внутреннее устройство MITR и его расчётное обоснование (классы необратимости, порядок проверки и инварианты) подробно разобраны на странице «MITR: устройство и обоснование».

Что проверить за час

1. Пакет ставится без доступа в сеть, и на нём видно, что разрушающий запрос к базе данных останавливается; команды приведены в быстром старте ниже.
2. Собственный MCP-сервер оборачивается пакетом, и видно, какую причину отказа получает агент.
3. Журнал пакета пересчитывается проверщиком из одного файла, и правка одной записи нарушает цепь.
4. Якоря цепи полной версии MITR пересчитываются по данным, опубликованным на asi5.ru/console/verify/.
5. Границы применимости сверяются с задачей организации, а вопросы, на которые страница не отвечает, принимаются через форму связи.

Пробные пакеты: открытый код без регистрации

Три открытых пакета специалист устанавливает у себя за несколько минут, в том числе без доступа в сеть. Каждый файл заверен контрольной суммой, исходный код опубликован.

mcp-sentinel — защита вызовов MCP

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

iss-ledger-117 — журнал по ГОСТ Р 34.11-2012

Журнал решений, сцепленный хеш-функцией «Стрибог», и проверщик из одного файла для изолированной машины.

Быстрый старт: подключение защиты к собственному MCP-серверу

Уязвимый MCP-сервер не запускается напрямую — он оборачивается в mcp-sentinel wrap, и каждый вызов инструмента проверяется до исполнения, а ответ сервера — до передачи агенту. Пакет написан на чистом Python без сторонних зависимостей и ставится без доступа в сеть.

Установка

# изолированный контур: файлы .whl скачаны заранее, сеть не нужна
pip install --no-index --find-links ./wheels mcp-sentinel
# с доступом в сеть: только каталог института, PyPI не спрашивается
pip install --no-index --find-links https://isslab.ru/wp-content/uploads/iss-utils/index.html mcp-sentinel

Конфигурация клиента

Конфигурация клиента — раздел mcpServers файла настроек агентной среды разработки. Реквизиты базы в образце подставляются из переменных окружения, а их значения выдаёт хранилище секретов организации. Открытый пакет ключей не держит: он стоит обёрткой вокруг сервера, которому реквизиты выдаёт сама организация, а свойство «ключи только у MITR» относится к полной версии MITR при установке у заказчика. Журнал пишется в каталог, доступный процессу агента.

{
  "mcpServers": {
    "postgres-secure": {
      "command": "mcp-sentinel",
      "args": ["wrap", "--ledger", "/home/dev/.local/state/mcp-sentinel/audit.jsonl", "--agent", "dev-agent", "--",
               "npx", "-y", "@modelcontextprotocol/server-postgres", "postgresql://${PGUSER}:${PGPASSWORD}@localhost/prod"]
    }
  }
}

Проверка одного вызова из консоли

mcp-sentinel check --tool sql_query \
  --args '{"query": "DROP TABLE users;"}'
# BLOCK — разрушающая операция DROP TABLE остановлена, код выхода 2

Агент на Python: подключение одним импортом

Пакет iss-agent-kit оборачивает функцию агента и пишет решение по каждому вызову в журнал по ГОСТ Р 34.11-2012.

from iss_agent_kit import AgentGuard
guard = AgentGuard(ledger_path="audit/agent_gost.jsonl")
result = guard.run(execute_sql, "sql_query", {"query": "SELECT id FROM users WHERE id = 1;"})

Команды этого раздела исполняются при приёмке каждой версии в чистом окружении без сети — теми же строками, что напечатаны здесь. Журнал по пути --ledger ведётся цепочкой по ГОСТ Р 34.11-2012 и пересчитывается внешним проверщиком без установки чужого программного обеспечения.

С чего начать

Первый шаг — пробная установка у специалиста и разговор о внедрении. Наблюдение в течение 30 суток проходит без остановки работы агентов и завершается отчётом по квитанциям: какие действия совершались, какие были бы остановлены, на основании каких правил и какова доля ложных остановок. Состав поставки, требования к площадке и сроки пилота — на странице «Пилот MITR у заказчика».