Автоматизированный пентест в среднем охватывает лишь 32% поверхности атаки организации, а ИИ-агенты не отменяют это ограничение. Агентное пентестирование умеет быстрее строить сложные цепочки атак, но не может безопасно взломать всё, что найдёт сканер, — и для российских ИБ-команд это важное напоминание: отчёт об успешном тесте ещё не равен полной картине риска.
Об этом пишет BleepingComputer в спонсорском материале Picus Security. Компания разбирает слабые места агентных систем для пентеста: ограничения области работ, недоступные сетевые сегменты, риск повредить production-сервисы и отсутствие готовых эксплойтов для значительной части CVE.
ИИ-агент быстрее думает, но не получает магический доступ
Классический пентест обычно проходит знакомую последовательность: разведка, поиск уязвимостей, первичный доступ, закрепление или развитие атаки, затем отчёт. Автоматизированные средства давно повторяют этот процесс по заранее заданным сценариям. Агентный подход добавляет динамику: модель оценивает найденные артефакты, контекст инфраструктуры и выбирает следующий шаг, а не просто перебирает чек-лист.
Именно здесь проявляется сила подхода. Агент может связать несколько слабых мест в одну цепочку, быстрее человека перебрать варианты повышения привилегий или заметить неочевидную комбинацию неправильных настроек. В Picus для этого используют пять специализированных агентов под управлением Numi AI; это описание собственного продукта поставщика, а не независимое сравнение инструментов на рынке.
У такого подхода есть и инженерная цена. Полноценное рассуждение на каждом шаге требует вычислений и токенов, а результат не всегда воспроизводим. Один и тот же агент способен несколько раз не добиться эксплуатации и успешно пройти цепочку лишь в следующем запуске, хотя среда не менялась. Если повторять тесты ради уверенности, стоимость и время растут; для инфраструктуры с тысячами конечных точек один прогон может растянуться на недели.
Поэтому авторы материала не предлагают заменить привычную автоматизацию агентами. Детерминированные проверки остаются полезны для частого, дешёвого и сопоставимого тестирования: ими проще повторно проверить исправление и увидеть изменение между двумя запусками. Агентные тесты логичнее запускать реже — там, где нужен поиск новых маршрутов атаки, а не очередное подтверждение уже известного правила.
Главная проблема — то, что тестировать нельзя
Пентестер, человек или ИИ, должен выполнять реальную атаку. Это автоматически исключает часть активов. Критичные системы часто выводят из области тестирования: эксплуатация может вызвать отказ сервиса, испортить данные или переключить кластер на резервную площадку. Ограничения сети отсекают сегментированные и изолированные зоны. В материале приводятся данные Omdia: в среднем организации проверяют пентестом 32% своей поверхности атаки.
Picus иллюстрирует разрыв примером с обходом аутентификации nginx-ui, обозначенным как CVE-2026-33032. Сканеры якобы нашли 480 потенциально уязвимых экземпляров, но агентный инструмент получил разрешение и сетевую достижимость только к 120. На них он подтвердил эксплуатацию в 80 случаях, а ещё в 40 не смог провести атаку. Остальные 360 экземпляров — три четверти исходной выборки — не получили никакого вердикта. Это кейс вендора, поэтому его цифры следует воспринимать как пример методики, а не как универсальную статистику.
Есть и второй разрыв: доступный сервер не обязательно можно проверить эксплуатацией. По приведённым в статье данным VulnCheck, лишь примерно четверть CVE, опубликованных в 2025 году, имела публичный proof-of-concept или детали эксплуатации. При этом 29% уязвимостей, которые исследователи подтвердили как эксплуатируемые в 2025 году, начали использоваться не позднее даты публикации CVE. Для защитников это неприятная арифметика: ожидание публичного PoC не является признаком безопасности.
Попытка поручить языковой модели написать эксплойт тоже не решает задачу автоматически. Непроверенный код может положить сервис или повредить данные — особенно если запускать его в рабочей среде. Поэтому агентное пентестирование создаёт два класса «белых пятен»: активы, до которых тест не добрался, и уязвимости, для которых нельзя безопасно выполнить атаку.
В качестве дополнения Picus предлагает оценивать не факт успешного взлома, а предпосылки для него: нужные техники атакующего и реакцию действующих средств защиты. В описанном примере это позволило дать оценку 360 недоступным экземплярам: 260, по версии компании, блокировались контролями, а 100 оставались вероятно эксплуатируемыми. Вместе с 80 подтверждёнными случаями приоритетными стали 180 хостов вместо всех 480 срабатываний сканера.
Практический вывод для команд разработки и ИБ не в том, чтобы срочно покупать ещё один ИИ-инструмент. Полезнее разделить вопросы: какие активы видит сканер, какие доступны для безопасной имитации атаки, какие средства защиты действительно останавливают нужную технику и кто отвечает за повторную проверку исправления. Без единого списка активов, критичности сервисов и доказательств от защитных контролей даже самый убедительный отчёт агента останется дорогой выборкой.
Следующий этап зрелости здесь — не «автономный хакер» в инфраструктуре, а связка повторяемых проверок, точечных агентных исследований и симуляции атак на средства защиты. Чем короче окно между публикацией CVE и её эксплуатацией, тем важнее будет отличать подтверждённый риск от недоступного для теста актива — и не выдавать второе за первое. Подробности подхода и пример с nginx-ui приведены в материале .