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 році. Змінилися швидкість, масштаб і кількість паралельних дій, а частина активності може відбуватися через штатні інструменти та довірені облікові записи. Тому відсутність експлойту або очевидно викраденого пароля не гарантує, що внутрішня активність безпечна.

Спеціалізовані засоби для захисту мовних моделей та агентів розробляються, але, за матеріалом, поки не стали масовими. Частину ризиків можна відстежувати вже наявними засобами: за відхиленнями від нормальної поведінки, масовими запитами автентифікації, нестандартними напрямами доступу та переліком незареєстрованих агентів. Для промпт-атаки важливими можуть бути саме наслідки виконання інструкції, а не її формулювання. Отже, на практиці ключове питання — чи видно службі безпеки, що саме агент робить і до чого має доступ.