Zero Networks разобрала три сценария, в которых ИИ-агенты помогают злоумышленнику перемещаться внутри корпоративной сети. Для свина-инженера здесь знакомая проблема: инструмент получил доступ к данным, а границы его полномочий остались где-то между настройками и благими намерениями. В отчёте Lateral Movement Exposure Report 2026 речь идёт о скорости, масштабе и действиях под доверенными учётными записями.

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

Подсказка в письме может заставить агента вывести данные

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

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

Другое направление защиты — следить за поведением агента и разрешёнными ему зонами. Если инструмент должен работать с CRM, базой знаний и Jira, обращения к Outlook, каталогу пользователей или файловому серверу уже не соответствуют описанной роли. Подозрительным может быть и необычный объём операций с данными. Логика проста: доступ агента должен соответствовать тому, что он реально делает.

Для одного агента с чётко определёнными функциями политики можно задать вручную. Когда инструментов много или их роли меняются, в материале предлагается обучать ML-модель на нормальном поведении и выявлять отклонения. Можно сочетать оба подхода: очевидные границы закрепить правилами, а менее предсказуемые отклонения поручить модели. Агент, которому для краткого изложения письма вдруг понадобился файловый сервер, сам подсказывает, что правила доступа стоит проверить.

Перебор NTLM-хешей превращается в массовую проверку

Второй сценарий начинается с рабочей станции, с которой злоумышленник получил сохранённые NTLM-хеши. Затем их можно проверять на доступных внутренних системах. Человек, действуя вручную, ограничился бы несколькими приоритетными целями; ИИ-агент способен проверять тысячи одновременно. Метод давно известен. Просто теперь у него появился очень старательный исполнитель.

В отчёте, как его пересказывает автор материала, 43,2% внутренней аутентификации всё ещё основано на NTLM. Чем больше систем принимают этот механизм, тем больше потенциальных целей для такого перебора. Это не означает, что каждая из них будет скомпрометирована: указанная доля описывает распространённость использования NTLM, а не частоту успешных атак.

Сетевой сигнал в этом случае — всплеск запросов аутентификации: один хост обращается ко множеству других во внутренней сети. В примере для обычной рабочей станции это несколько обращений к файловой SMB-сети в день; тысячи запросов вместо привычного уровня уже требуют внимания. Такой всплеск указывает на разведку или ненормальную активность, хотя сам по себе не объясняет, что именно её вызвало.

Для отслеживания можно использовать отдельные модели обнаружения для NTLM, Kerberos и LDAP. Некоторые сценарии, в частности подбор паролей, можно описать детерминированными правилами. При этом у всплеска может быть и обыденное объяснение: например, скрипт продолжает многократно входить в систему с паролем, срок действия которого истёк. Поэтому сигнал стоит рассматривать как повод выяснить причину, а не как автоматическое доказательство атаки.

Неучтённый агент оставляет слепую зону

Третий сценарий — так называемый Shadow AI. Разработчик подключает внутреннюю языковую модель к личному MCP-серверу, у которого есть доступ к корпоративной базе данных. «Личный» здесь означает, что сервер развернули для собственных задач, а не то, что он изолирован от корпоративной сети. Согласно приведённому в материале утверждению, с одной такой скомпрометированной машины в среднем доступны 85% внутренних систем.

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

Практический ответ — инвентаризация: нужно знать, какие агенты запущены, с какими системами они взаимодействуют и какие данные могут получать. Именно отсутствие учёта делает такой инструмент похожим на Shadow IT, только с готовой автоматизацией и доступом к корпоративным данным. В материале также отмечается, что обнаруживать такие агенты можно по их наличию или по обращениям к доменам и сетям, характерным для ИИ-сервисов.

Защита начинается с видимости и границ доступа

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

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