Runtime-контроль ИИ-агентов: контролировать нужно не модель, а действие
Пока одни компании пытаются усилить фильтрацию промптов, ИИ-агенты уже самостоятельно вызывают инструменты, подключаются к MCP-серверам, обращаются к платёжным API, запускают команды в операционной системе и получают доступ к ключам на рабочих станциях. В такой среде одной защиты языковой модели недостаточно: необходимо контролировать конкретное действие непосредственно перед его выполнением.
Именно действие становится основной единицей безопасности. Промпт можно проверить на наличие инъекций или запрещённых инструкций, но только перехват вызова инструмента способен остановить потенциально опасную операцию до того, как она произойдёт.
Почему одного фильтра промптов недостаточно
ИИ-агент работает не только с текстом. Он формирует план, выбирает инструменты, передаёт аргументы, обращается к внешним моделям, читает файлы, выполняет команды и взаимодействует с другими агентами. Даже безопасный на первый взгляд запрос может привести к рискованному результату, если агент получил чрезмерные полномочия.
Поэтому полноценный runtime-контроль должен включать два взаимосвязанных контура. Первый отвечает за анализ семантики: обнаруживает инъекции, попытки обхода ограничений, токсичный контент, подозрительные запросы и обращения к внешним моделям. Второй контролирует сами действия: проверяет полномочия, список разрешённых инструментов, параметры вызова и контекст сессии.
В архитектуре INFERA AI.SafeAgent быстрые проверки выполняются рядом с агентом. Компонент контролирует права, разрешённые инструменты, аргументы вызовов, MCP-обёртки и локальные ограничения. При недоступности контрольного сервиса используется режим fail-closed: операция блокируется, а не выполняется вслепую.
INFERA AI.Firewall выполняет более тяжёлые семантические проверки. Через шлюз проходят анализ инъекций, попыток обойти политики, длинных текстов и маршрутизации запросов к внешним LLM. На хосте такие классификаторы намеренно не запускаются, поскольку они увеличивают задержку и могут сделать агента непригодным для рабочих сценариев.
Политики создаются и компилируются на control plane, после чего доставляются агентам в исполняемом виде. Благодаря этому решение по большинству вызовов принимается быстро и не требует постоянного обращения к центральному сервису.
Где должен находиться перехват
Единой точки контроля для всех агентов не существует. Среда исполнения определяет, каким способом можно остановить действие до его запуска. На практике применяются:
- MCP-wrapper для серверов и инструментов;
- hook-адаптеры для IDE и CLI, включая Claude Code, Cursor, Codex и аналогичные среды;
- eBPF в Linux для контроля системных вызовов;
- ETW в Windows;
- хостовый агент INFERA AI.SafeAgent;
- принудительный исходящий трафик через INFERA AI.Firewall и его base_url.
Ключевой принцип прост: если для конкретного действия нет точки перехвата, его нельзя считать контролируемым. Наличие агента в реестре ещё не означает, что организация способна остановить его обращение к инструменту или внешнему сервису.
Три уровня зрелости контроля
Удобно разделять агентов на три уровня.
Уровень У0 - обнаружение. Агент найден, но его владелец, состав компонентов и назначение не оформлены. Политика отсутствует, поэтому безопасным такой агент считаться не может.
Уровень У1 - допуск и сканирование. Компоненты проверены, агент описан и выведен из категории Shadow AI. Однако его действия ещё не проходят через полноценный движок допуска.
Уровень У2 - управление по политике. Для агента назначен профиль доступа, а каждый перехваченный вызов оценивается правилами. Только на этом уровне можно говорить о runtime-контроле и режиме deny-by-default.
Именно доля агентов на У2, а не размер общего реестра, показывает реальную зрелость защиты. Отдельно следует отслеживать теневые сущности, которые уже используются сотрудниками, но ещё не получили карточку, владельца и набор ограничений.
Что входит в профиль доступа
Профиль доступа должен описывать не абстрактную "надёжность" агента, а конкретные границы его поведения. В него входят:
- разрешённые модели и внешние провайдеры;
- допустимые MCP-серверы и инструменты;
- перечень операций чтения и записи;
- ограничения на типы и значения аргументов;
- разрешённые сетевые направления;
- доступ к файлам, переменным окружения и секретам;
- допустимые команды операционной системы;
- требования к журналированию;
- условия обязательного согласования человеком;
- правила для новых версий, скиллов и расширений.
Профиль должен быть версионным. Если в агент добавился новый инструмент или изменился набор полномочий, прежняя политика не должна автоматически считаться достаточной.
Как обрабатывается вызов
Типовой сценарий выглядит так:
1. Агент планирует действие - вызывает инструмент, MCP-сервис, модель или команду ОС.
2. Точка перехвата останавливает вызов до фактического исполнения.
3. Движок находит скомпилированную политику конкретного агента и её версию.
4. Проверяется белый список полномочий.
5. Анализируются инструмент и параметры вызова.
6. При необходимости выполняется семантическая проверка через шлюз.
7. Система выносит вердикт.
8. Только после разрешения действие передаётся исполнителю.
Возможные решения не ограничиваются вариантами "разрешить" и "запретить". Система может сохранить событие, замаскировать чувствительные данные, запросить согласование человека, временно приостановить агента или отправить операцию на дополнительную проверку.
Например, агент без карточки переводится в карантин. Новый MCP-сервер сначала сканируется. Инструмент, отсутствующий в профиле, блокируется с уведомлением службы безопасности. Попытка передать секрет во внешний сервис может быть остановлена или разрешена только после редактирования параметров.
Shadow AI: почему видимость начинается с рабочего места
Если сотрудник на ноутбуке обращается к неподконтрольной внешней LLM, это уже событие безопасности. Оно относится к Shadow AI, даже если запрос не проходит через корпоративный шлюз.
Без хостового агента организация видит только трафик, который проходит через известные прокси и шлюзы. Локальные CLI-инструменты, плагины IDE, автономные скиллы и обращения к API могут остаться незаметными. Поэтому для полноценной картины требуется контроль рабочей станции: процессы, сетевые соединения, используемые модели, секреты и действия инструментов.
Однако обнаружение - лишь начало. Найденный агент должен получить владельца, описание, оценку компонентов и понятный жизненный цикл: допуск, изменение, повторное сканирование, отзыв и удаление.
HITL как операционный процесс
Human-in-the-loop - это не простая кнопка "спросить человека". Если согласование встроено в рабочий процесс формально, сотрудники быстро начинают подтверждать любые запросы автоматически.
Рабочий HITL должен определять, какие операции требуют участия человека, кто имеет право их подтверждать, сколько действует решение и что происходит при отсутствии ответа. Желательно показывать оператору не только название инструмента, но и цель операции, аргументы, источник данных, предполагаемый эффект и уровень риска.
Особенно важно отделять одноразовое разрешение от постоянного. Подтверждение перевода средств не должно автоматически открывать агенту доступ ко всем будущим платежам.
Сканирование агентной цепочки поставок
Безопасность агента зависит не только от его основной модели. Риски могут находиться в MCP-сервере, расширении IDE, стороннем скилле, библиотеке, контейнере или скрипте установки.
Перед выдачей доступа необходимо проверять происхождение компонентов, версии, подписи, зависимости, сетевые обращения и запрашиваемые разрешения. Повторная проверка требуется после обновлений: изменение инструмента может расширить его возможности без заметного изменения пользовательского интерфейса.
Полезно разделять первоначальное сканирование и постоянный мониторинг. Первое отвечает на вопрос "что установлено", второе - "что изменилось и как компонент ведёт себя сейчас".
Какие сценарии закрывать в первую очередь
На начальном этапе целесообразно сосредоточиться на действиях с высоким потенциальным ущербом:
- доступ к платёжным и финансовым API;
- чтение и экспорт секретов;
- выполнение команд ОС;
- запись в продуктивные базы данных;
- отправка данных во внешние модели;
- изменение конфигурации облачной инфраструктуры;
- создание новых токенов и учётных записей;
- массовая отправка сообщений или файлов;
- изменение политик безопасности;
- доступ к персональным и коммерчески чувствительным данным.
Для каждого сценария нужно определить владельца, допустимый уровень автоматизации, обязательные точки перехвата и условия аварийной остановки.
Практическая модель внедрения
Начинать стоит с инвентаризации, но не останавливаться на ней. Сначала фиксируются агенты, модели, MCP-сервера, расширения и рабочие станции. Затем определяются критичные действия и подключаются соответствующие перехваты.
После этого вводятся базовые профили: чтение разрешено, запись ограничена, доступ к секретам запрещён по умолчанию, внешние модели допускаются только через корпоративный шлюз. Для исключений создаются отдельные правила с владельцем и сроком действия.
Следующий шаг - перевод наиболее рискованных агентов на У2, настройка журналирования и контроль качества решений. В логах должны сохраняться агент, пользователь, сессия, инструмент, аргументы, результат проверки, версия политики и итоговый вердикт. Это необходимо не только для расследований, но и для анализа ложных блокировок.
Главная идея runtime-контроля заключается в смене фокуса. Недостаточно знать, какая модель используется и какие агенты существуют в компании. Нужно понимать, какое действие агент собирается выполнить, от чьего имени, с какими аргументами и сможет ли система остановить его до исполнения. Именно такой подход превращает перечень обнаруженных агентов в управляемый контур безопасности.