SOC для мониторинга ИИ-агентов

Просрал сроки CFP и не подался на грядущий OFFZONE. Поэтому поделюсь тут в сжатой форме своими мыслями по поводу возможных решений по мониторингу безопасности ИИ-агентов. Отчасти можно считать эту тему развитием моего выступления про мониторинг безопасности LLM на форуме ГосСОПКА, но с более визионерским прицелом.

Итак, если посмотреть на рынок решений по мониторингу ИБ, то почти все из них построены вокруг трех сущностей: пользователь, процесс и устройство. Например:

• пользователь залогинился
• процесс запустился
• сервер отправил трафик
• контейнер открыл соединение.

Но ИИ-агент – это вообще не процесс, не пользователь и не устройство (или скорее это все в одном). У него есть цель, память, план, способность принимать решения, возможность выбирать инструменты, способность менять собственное состояние. То есть появляется объект, который намного ближе к человеку, чем к обычному приложению.

Я вообще бы их выделял в отдельную сущность – так будет гораздо правильнее с точки зрения ИБ.

Журналирование событий в SOC, соответственно, тоже должно измениться и учесть новую сущность, которая выходит за рамки привычных фиксируемых событий – «User logged in», «Process started», «File opened», «HTTP request», «Registry modified» и т.п., которых явно недостаточно для понимания деятельности ИИ-агента, которая описывается совсем иными событиями:

• Goal Accepted
• Goal Rejected
• Plan Generated
• Plan Updated
• Tool Selected
• Tool Rejected
• Memory Read
• Memory Updated
• Context Loaded
• Knowledge Retrieved
• Reasoning Started
• Reasoning Finished
• Human Approval Requested
• Human Approval Granted
• Goal Completed
• Goal Failed

Напоминает действия человека, не так ли?

Соответственно, как когда-то появились телеметрия с оконечных устройств, сети и решений по управлению идентификацией, так сейчас должна появиться агентская телеметрия, которая станет отдельным потоком данных для SOCа. Причем интересен не сам факт вызова модели, который легко отслеживается. Сегодня большинство компаний уже фиксируют промпты и ответы модели (привет, LLM Firewall), число токенов, задержки, используемые модели и т.п. Но это уровень API, а ИИ-агент живет немного выше. Для него важны не токены, а «почему он решил это сделать?».

Это третье поколение решений по безопасности ИИ – AI Security 3.0, о котором я вчера написал в Telegram-канале, как развитие модерируемой мной на Softline Security Summit антипленарной дискуссии.

Например, появляется событие «Goal Accepted». Через минуту – «Plan Generated», а потом одно за другим – «Selected Tool = PowerShell», «Tool execution rejected», «Selected Tool = SSH», «Privilege escalation requested» и наконец «Approval bypass attempted». А это уже полноценная цепочка атаки со своими тактиками и техниками. Вместо привычной MITRE ATT&CK у нас появится уже MITRE ATLAS, ну или модель Сбера, которые будут оперировать другими тактиками, например, Goal Injection, Context Poisoning, Planning, Tool Selection, Execution, Memory Update и Persistence.

Кстати, насчет ATLAS. Эта матрица MITRE описывает, что может сделать противник в части ИИ, но она не определяет, какие именно события должен зарегистрировать ИИ-агент. Кроме того, ATLAS не полностью описывает внутреннее поведение самого агента. Поэтому SOCу придется обнаруживать не только злонамеренные атаки, но и ситуации, в которых:

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

Здесь может вообще не быть внешнего атакующего и, соответственно, классической TTP. Это может быть (и это ближе к модели угроз ИИ Сбера):

• ошибка планирования
• галлюцинация
• конфликт инструкций
• неверная конфигурация
• чрезмерные полномочия
• небезопасная композиция инструментов
• развивающееся поведение
• отказ человеческого надзора.

Вместо IOCов у нас появятся IOBы, то есть индикаторы поведения. Ведь агент почти никогда не использует что-то постоянное. Поэтому индикаторами и становятся поведенческие признаки, а не статические IP, hash, filename, domain, registry, mutex и т.п. Например, «агент за последние 5 минут сменил 12 инструментов», «агент пять раз перепланировал задачу» или “агент постоянно просит расширенные права”. Можно пофантазировать и предположить, что UEBA расширится до ABA (Agent Behavior Analytics), который сможет ловить такие цепочки: «получил задачу → загрузил память → прочитал 300 файлов → открыл терминал → попытался вызвать curl → открыл MCP → создал новую цель». Дальше больше. Должны появиться новые правила корреляции. Вместо «VPN Login → пользователь в офисе → MFA Failure» мы будем ловить что-то типа: «Goal Accepted → Unexpected Tool → Sensitive Memory Read → External MCP → Memory Updated».

SOC станет понимать не «что произошло», а «о чем думал агент?» или «почему агент решил именно так?». То есть объектом анализа становится не системный вызов, а цепочка принятия решений.

Другая идея. Вместо хронологии событий (timeline) может появиться дерево рассуждений ИИ-агента. Практически «process tree» в EDR, только для мышления агента.

Пока это все мои фантазии. И поэтому, на мой взгляд, именно в этой сфере в ближайшие годы могут появиться новые классы продуктов и функций:

1. Agent Telemetry – единая схема событий для любых агентных платформ (аналог OpenTelemetry, но для жизненного цикла агента), то есть описание того, что должен регистрировать агент.
2. Agent Behavior Analytics (AEBA или ABA) – профилирование нормального и аномального поведения агентов.
3. Detection Engineering для агентов – Sigma/YARA/NOVA-подобные правила, но описывающие цепочки целей, планов, инструментов и памяти. А тут всякие конвертеры, базы правил, паки экспертизы и все такое.
4. Agent Digital Forensics – реконструкция решений агента после инцидента: что он видел, что запомнил, какие планы строил и почему выбрал конкретный инструмент.
5. Agent Exposure Management – оценка “поверхности атаки” агентов: доступные инструменты, источники памяти, MCP-серверы, полномочия и делегированные возможности.
6. Agent Threat Hunting – поиск скрытых признаков компрометации в журналах рассуждений, памяти и цепочках выполнения задач.

Если реализовать первые три пункта, то, например, техника ATLAS, связанная с промпт-инъекциями, могла бы детектироваться не по самому тексту вредоносной инструкции и правилу корреляции на языке NOVA, а по цепочке: «Goal Accepted → External Source Retrieved → Context Changed → Plan Rebuilt → New Tool Selected → Sensitive Action Requested». Причем, если в случае с NOVA вам нужно прямым текстом задать текст конкретной инъекции, то под описанную цепочку попадут даже неизвестные и будущие инъекции. Или вот злоупотребление инструментами, которое можно было бы «поймать» с помощью цепочки поведенческих индикаторов: «Tool Selected → Permission Denied → Alternative Tool Selected → Same Resource Access Attempted → Approval Bypass Attempted».

У России, кстати, появляется шанс быть наравне со всем миром, а не повторять/импортозамещать западные решения, так как и на Западе сейчас почти нет отдельных решений по мониторингу ИБ ИИ-агентов.

Мне кажется, мы сейчас повторяем историю двадцатилетней давности. Тогда SIEM эволюционировал от простого сбора системных логов к анализу поведения пользователей, сетей и оконечных устройств. Сейчас начинается следующий этап: агент становится полноценной наблюдаемой сущностью корпоративной инфраструктуры. Не «процессом с ИИ внутри”, а новым цифровым субъектом, для которого нужны собственные телеметрия, модели поведения, правила корреляции и методики расследования. Если эта гипотеза окажется верной, то через несколько лет вопрос будет звучать уже не «поддерживает ли ваш SIEM ИИ?», а «умеет ли ваш SOC понимать поведение автономных агентов?». Это, как мне кажется, гораздо более интересная история, чем простое добавление LLM в интерфейс SIEM.

На самом деле такой вопрос заказчики могут начать задавать уже раньше. Думаю, на горизонте полугода-года опыт внедрения ИИ-агентов в России станет шире и тогда задача защиты этих сущностей станет более чем актуальной.

А пока можно использовать стандарт OpenTelemetry, который расширяется для целей мониторинга ИИ и который уже стандартизирует модель, токены, промпты, tool calls и результаты работы инструментов. С его помощью уже сейчас в SIEM можно передавать: agent.id, agent.name, agent.version, agent.framework, session.id, trace.id, parent.agent.id, model.name, model.provider, tool.name, tool.arguments, tool.result, tool.duration, tool.status, retrieval.source, retrieval.document, retrieval.result_count, user.id, service.identity, delegated.identity, input.prompt, output.response, token.count, latency, cost, error. Но именно тех событий, которые я описывал выше, пока нет как стандартных, – их приходится добавлять как custom events.

Если пробежаться по рынку решений, то по состоянию на начало августа 2026 года можно сделать уверенный вывод – универсального «EDR/SIEM для ИИ-агентов» пока нет, но есть хорошие средства разработки и трассировки, отдельные средства runtime-защиты, платформы инвентаризации и governance, а также первые продукты, действительно ориентированные на SOC. Я бы, упрощенно, выделил следующие классы таких решений:

Самая зрелая часть рынка – отладка и наблюдаемость (observability). Все уже достаточно хорошо умеют показать разработчику, почему агент ошибся (все как в обычном ИТ). Менее зрелый сегмент – runtime prevention; уже можно блокировать промпт-инъекции, опасный tool call или утечку данных. Самая незрелая часть рынка – как раз SOC detection engineering. Почти никто пока не дает полноценного набора:

• нормализованной схемы агентских событий
• правил корреляции
• привязки к MITRE ATLAS
• поведенческих профилей агентов
• расследования цепочек agent-to-agent
• ретроспективного threat hunting
• доказательной реконструкции цели, плана, памяти и действий.

Именно последний слой пока почти никем не закрыт «из коробки». Описанные выше вендоры предлагают собственные дашборды и функции, но единое SOC-представление агента как отдельной сущности в SOC, примерно как пользователя, хоста или рабочей нагрузки в облаке, рынок еще только начинает формировать. Интересно, кто из российских игроков ИБ пойдет в эту историю?

На этом пока прервусь. У меня еще есть часть рассуждений про проблему с огромным объемом событий, которые надо передавать в SIEM от ИИ-агентов (там их реально до хрена и они совсем иного размера, чем просто события ETW). Но про это я напишу в отдельной заметке.