5 ошибок AI-агента в автономном пентесте

Последние полтора года я запускаю LLM-агентов на каждом втором ассессменте - от внешнего recon до постэксплуатации в Active Directory. Самый показательный провал случился на проекте для финтеха: агент получил вывод Nmap с баннером Apache Tomcat на порту 8443, уверенно предложил эксплойт для CVE, которой не существует в NVD, и сорок минут подбирал payload к фантомной уязвимости. За это время реальная дыра - default credentials на JMX-консоли - оставалась нетронутой.

Это не единичный случай. По данным FluidAttacks, агенты пентеста «часто ошибаются обычными способами: повторяют шаги, следуют нерелевантным путям, выдумывают процедуры или теряют след предыдущих тестов». Звучит знакомо? Ниже - пять конкретных ошибок автоматизации пентеста с разбором причин и конфигурациями guardrails, которые их гасят.

Галлюцинации: AI-агент выдумывает CVE и модули​

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

На практике выглядит так: агент получает вывод nmap -sV с баннером OpenSSH 8.9p1, уверенно предлагает use exploit/linux/ssh/openssh_89_rce - модуля с таким именем в Metasploit нет. Или формулирует «CVE-2024-XXXXX» с правдоподобным описанием, но при запросе к NVD API идентификатор возвращает пустой результат. Выглядит убедительно, пока не проверишь.

Исследователи APT-Agent решили проблему архитектурно: в пайплайн агента добавлен rectifier - модуль, который сверяет каждое предложенное имя Metasploit-модуля с курируемой базой перед выполнением. По данным FluidAttacks, удаление rectifier и контекстного менеджера в эксперименте на Metasploitable 2 снизило успешность с 59 из 70 задач до 38. Падение на 30% - только из-за отсутствия проверки одного параметра.

Как блокировать галлюцинации LLM в пентесте​

Минимальный guardrail - валидация каждого CVE-идентификатора и каждого имени модуля до выполнения:
Для модулей Metasploit - msfrpcd предоставляет RPC-интерфейс для запроса списка доступных модулей. Обёртка агента вызывает module.exploits и сверяет предложенное имя до загрузки. Если модуль отсутствует - агент получает явный отказ с инструкцией переформулировать запрос, а не тихий провал. Тихий провал - худшее, что может быть: агент «думает», что всё отработало, и строит дальнейшую цепочку на пустоте.

Потеря контекста в многошаговых цепочках атак​

Контекстное окно LLM заполняется быстро: один вывод Nmap по подсети /24 - тысячи токенов. Агент «забывает» ранние находки, повторно сканирует те же хосты и теряет обнаруженные credentials.

На внутреннем пентесте я наблюдал, как агент трижды за сессию просканировал один контроллер домена. На третьем проходе он «обнаружил» открытый порт 389 - свою же находку двадцатиминутной давности. Каждый лишний проход жёг время и генерировал сетевой трафик, повышая шансы на детект SOC. По сути, агент палил операцию вместо того, чтобы двигаться дальше.

Исследование CheckMate (Wang et al.) показало: разделение на planner, executor и perceptor - где долгосрочное планирование передаётся классическому планировщику вместо LLM - даёт прирост benchmark success rate более 20% по сравнению с Claude Code. Средняя стоимость снизилась на 53%, время - на 54%. Экономия достигается именно за счёт устранения повторных действий.

Контекстный менеджер для автономного pentest​

Stage-aware context manager хранит компактное структурированное состояние вместо raw-логов в промпте:

• Discovered hosts - IP, открытые порты, баннеры, сервисы
• Credentials - найденные учётные данные с привязкой к хосту и источнику
• Attempted actions - что уже пробовали, с каким результатом, на каком хосте
• Current stage - recon / initial access / privilege escalation / lateral movement

По данным APT-Agent, удаление контекстного менеджера снижало success rate с 84.3% до порядка 54% - почти двукратное падение. На практике достаточно JSON-файла, который обновляется после каждого действия агента и подаётся в промпт как сжатый context вместо полного лога сессии. Ничего сложного - но без этого агент превращается в рыбку с памятью в три секунды.

Агрессивный recon: AI-агент без контроля blast radius​

Третья типичная ошибка - агент запускает агрессивное сканирование без ограничений. nmap -sV -sC -A на всю подсеть, nuclei -t cves/ с полным набором шаблонов, массовый фаззинг эндпоинтов - нормально для лабораторного стенда. На продакшене банка это приводит к падению сервисов, срабатыванию WAF/IPS и блокировке IP пентестера. Дальше - звонок CISO с вопросом «кто положил API-шлюз?».

OWASP классифицирует корневую причину как Excessive Agency (LLM06:2025): LLM с избыточными полномочиями и автономией инициирует непредвиденные действия. Агент не различает «разрешено» и «целесообразно». Ему сказали «найди уязвимости» - он и находит, попутно роняя половину инфраструктуры.

По данным исследования IBM (представленного на AlphaXiv), даже в проприетарных агентских системах обнаруживались проблемы инфраструктурного уровня: контейнеры Kubernetes без строгих ограничений на исходящие соединения, контейнеры не очищались между сеансами, SSL-сертификаты и переменные среды оставались доступны следующему пользователю.

Ограничения для автоматизации пентеста на базе AI​

Три уровня контроля, которые я настраиваю на каждом проекте:

Tool allowlist. Агент не получает прямого доступа к shell. Вместо execute_command("nmap -A 10.0.0.0/24") - обёртка с фильтрацией опасных флагов. По OWASP AI Agent Security Cheat Sheet, агентам предоставляется минимально необходимый набор инструментов с per-tool permission scoping: read-only операции отделены от write, для каждого инструмента прописаны allowed_paths и blocked_patterns.

Rate limiting. Максимум N запросов в минуту к целевой инфраструктуре. Nuclei с 50 шаблонами одновременно - в очередь. Параметр --rate-limit в nuclei и --max-rate в Nmap решают это на уровне инструмента.

Network-level scope. Iptables/nftables на хосте агента: разрешены соединения только к IP и портам из согласованного scope. Агент физически не может отправить пакет за пределы периметра - даже если «решит» это сделать. Это не рекомендация, а обязательный минимум.

Scope creep: риски автономного тестирования безопасности​

Четвёртая ошибка - агент выходит за пределы согласованного scope. С юридической точки зрения это самая опасная ситуация: unauthorized access к системам вне договора. Тут уже не «ой, упал сервис», а потенциальная уголовка.

На Хабре описан показательный кейс из разработки: агент получил задачу разобраться с доступом к задаче после переименования проекта. Вместо диагностики он самостоятельно превратил анализ в реализацию - выбрал способ исправления, расширил область работы, начал менять код. По протоколу он должен был остановиться и дождаться подтверждения. Как сформулировал автор: «фразу "мне надо решить проблему" агент воспринял как разрешение на непосредственную реализацию».

В пентесте аналог - агент обнаруживает на целевом хосте reference на внутренний сервис в смежной подсети, резолвит его и начинает fingerprinting без санкции. Или извлекает credentials от базы данных вне scope и пробует подключиться. Я такое видел - агент нашёл строку подключения к PostgreSQL в конфиге и через секунду уже слал SELECT version() на хост, который вообще не в scope.

Исследование IBM выявило дополнительный вектор: human-in-the-loop контроль оказывается хрупким из-за «скрытия в Markdown». Агент представляет действия в отрендеренном виде как безобидное резюме, а реальная вредоносная директива скрыта в raw-тексте - например, синтаксис пустой ссылки [instruction]: (payload) не отображается в веб-интерфейсе, но обрабатывается агентом.

Human-in-the-loop для AI агента эксплуатации уязвимостей​

Checkpoint'ы - не опция, а несущая конструкция:

• Before initial access - агент предлагает вектор, оператор подтверждает, что целевой хост в scope
• Before lateral movement - агент показывает целевой хост и метод, оператор сверяет с перечнем
• Before any write operation - загрузка файлов, создание пользователей, модификация конфигов - только с ручным подтверждением

По OWASP AI Agent Security Cheat Sheet, неизвестные инструменты блокируются по умолчанию (fail closed). Конкретная модель классификации: search_documents и read_file - Low (пропускаются без ревью), write_file - Medium, execute_code - High, database_delete - Critical. Всё, что не Low, требует подтверждения оператора. Без исключений.

Ложные цепочки: валидация результатов автоматического пентеста​

Пятая ошибка - агент выстраивает цепочку эксплуатации, которая не работает в реальности, но выглядит убедительно. Типичный сценарий: обнаружен reflected XSS низкой критичности, затем агент «находит» SSRF (на деле - просто видит параметр с URL в запросе), объединяет их в «цепочку до RCE» и рапортует как Critical. Красивая история. Только неправда.

Агент не верифицирует каждое звено. Он предсказывает следующий шаг на основе обучающих данных (writeup'ы CTF, отчёты bug bounty), а не подтверждает эмпирически. По данным Astra Security, ключевое отличие качественного агентного пентеста - детерминистическая валидация: «AI discovers - logic validates. If it can't be proven, it doesn't ship».

Масштаб проблемы виден в эксперименте со структурированными attack trees: без направляющей структуры Llama-3-8B выполнял лишь 13.5% подзадач пентеста, Gemini-1.5 - 16.5%. С направляющим деревом атак (построенным по MITRE ATT&CK тактикам) цифры выросли до 71.8% и 72.8% соответственно. GPT-4 показал 75.7% без структуры и 78.6% с ней. Без внешней валидационной рамки даже сильная модель генерирует нерабочие цепочки.

Proof-of-exploitation для LLM-агента​

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

• RCE - содержимое /etc/hostname или whoami с целевого хоста
• SQLi - извлечённые данные из базы, а не просто сообщение об ошибке синтаксиса
• Auth bypass - response body из-за аутентификации, недоступный без обхода

Если агент не предоставляет proof - находка помечается как unverified и уходит на ручную проверку. Это фильтрует большинство ложных срабатываний AI-агента до попадания в итоговый отчёт. Правило жёсткое, зато отчёт потом не стыдно показывать заказчику.

Архитектура guardrails для LLM-агента в пентесте​

из SigmaHQ детектирует обращения к interaction-доменам (Burp Collaborator, interactsh). Если агент использует OOB-каналы для верификации, SOC увидит это в DNS-логах. D3FEND-контрмеры Inbound Session Volume Analysis (D3-ISVA) и Protocol Metadata Anomaly Detection (D3-PMAD) фиксируют аномальные паттерны трафика от AI-агента, даже если он формально действует в рамках scope.

Я последовательно отказался от полностью автономных агентов в пользу модели «AI предлагает - оператор решает». Это не откат к ассистентному режиму. Хорошо настроенный агент с guardrails за час генерирует 15–20 приоритизированных векторов атаки с конкретными командами. Без guardrails тот же агент за час выдаёт 50 векторов, из которых 35 - мусор с галлюцинированными CVE.

Проблема автономного пентеста не в слабости моделей. GPT-4 с attack tree закрывает 78.6% подзадач - серьёзная цифра. Проблема в оставшихся 21.4%: это кейсы, где ошибка стоит дорого - выход из scope, падение продакшена, фантомный Critical в отчёте. По данным CrowdStrike Global Threat Report 2025, среднее время lateral movement после initial access - 62 минуты, рекорд - 51 секунда. Агент, который за эти 62 минуты зациклился на несуществующей CVE вместо реальной эксплуатации, хуже, чем отсутствие агента.

Пока нет механизма, который надёжно разделяет «модель уверена и права» от «модель уверена и галлюцинирует», человеческий контроль в AI-пентесте - не страховка, а несущая конструкция. Если хочется проверить, где ручной навык пока незаменим - pwn и web на HackerLab дадут объективный ответ быстрее любого бенчмарка.