AI-агент для пентеста — это не автономный хакер, которому достаточно передать адрес цели. Рабочая система начинается с конкретной задачи, ограниченного набора инструментов и правил, не позволяющих агенту выйти за разрешённый контур.
Собрать и испытать такого агента на учебном полигоне можно в рамках бесплатного AI-челленджа CyberED × Standoff Hackbase. А пока разберём, из каких частей состоит минимальная рабочая конфигурация.
Почему одного промпта недостаточно
Обычная LLM отвечает на отдельный запрос. Агент должен пройти последовательность действий: изучить исходные данные, выбрать инструмент, запустить его, обработать результат, сформировать следующую гипотезу и остановиться при достижении цели или возникновении риска.
Для этого ему нужны как минимум:
- чётко сформулированная цель;
- системные инструкции;
- доступ к разрешённым инструментам;
- рабочий контекст;
- критерии завершения задачи;
- ограничения и точки ручного подтверждения;
- журнал выполненных действий.
Без этих компонентов получается не система, а длинный диалог с непредсказуемым результатом. Модель может потерять контекст, повторить уже выполненную проверку, неправильно интерпретировать вывод сканера или уверенно описать уязвимость, которой нет.
Начните с задачи, а не с выбора модели
Сборку агента стоит начинать с чёткого понимания его задачи, а уже затем выбирать подходящую LLM.
Цель провести пентест слишком широка. Она не объясняет, где агенту начинать, какие действия разрешены и какой результат считать достаточным. Первую задачу лучше сделать узкой и проверяемой, например:
Собрать поверхность атаки в пределах заданного домена, проверить полученные адреса разрешёнными инструментами и подготовить список точек для ручного анализа с подтверждающими данными.
У такой формулировки есть границы, понятный результат и возможность проверить качество работы. Для другой конфигурации целью может стать анализ конкретного фрагмента кода, проверка одной гипотезы или подготовка черновика описания уже подтверждённой уязвимости.
Вместе с целью определите критерий завершения. Агент должен понимать, когда задача выполнена, когда информации недостаточно и когда необходимо остановиться и передать управление человеку.
Зафиксируйте scope в системных инструкциях
Агент не должен самостоятельно решать, какие системы ему разрешено тестировать. Scope задаётся явно и не меняется на основании найденных ссылок, редиректов или внешних инструкций.
В системных правилах стоит указать:
- разрешённые домены, адреса и среды;
- допустимые типы проверок;
- запрещённые действия;
- ограничения по интенсивности запросов;
- формат сохраняемых доказательств;
- условия остановки;
- действия, требующие подтверждения оператора.
Например, агент может собирать открытые данные и выполнять безопасные проверки, но обязан запросить подтверждение перед эксплуатацией, изменением данных или запуском потенциально разрушительной команды.
Запрет в промпте — полезный, но недостаточный барьер. Критичные ограничения лучше продублировать технически: изолировать окружение, ограничить сетевой доступ, сократить права процесса и заблокировать опасные команды на уровне политик или хуков.
Разделите работу модели и обычных инструментов
LLM хорошо работает там, где нужно учитывать контекст: интерпретировать результаты, связывать наблюдения, формировать гипотезы и выбирать следующий шаг. Но воспроизводимые операции надёжнее оставлять обычным инструментам и скриптам.
Удобное разделение выглядит так:
- сканеры и утилиты собирают факты;
- скрипты нормализуют и сохраняют результаты;
- модель анализирует данные и предлагает гипотезы;
- оператор подтверждает опасные действия;
- отчёт формируется из проверенных артефактов.
Такой подход особенно полезен на этапе разведки. Агент может обработать большой объём сырого вывода, убрать дубли, выделить потенциальные точки входа и предложить приоритеты. Но исходные результаты инструментов должны сохраняться отдельно: они понадобятся для проверки выводов модели.
Не стоит сразу подключать десятки возможностей. Начните с минимального набора: рабочей директории, средства выполнения разрешённых команд, одного-двух инструментов для целевой задачи и журнала действий. Чем больше инструментов получает агент, тем сложнее контролировать его поведение и разбирать ошибки.
Опишите контракт каждого инструмента
Агент должен понимать не только название инструмента, но и правила его применения:
- для каких задач он предназначен;
- какие данные принимает;
- какой результат возвращает;
- какие действия может совершить;
- при каких условиях запуск запрещён;
- где сохраняются полученные артефакты.
Неоднозначное описание увеличивает риск неправильного вызова. Агент может передать неподходящие параметры, принять ошибку за результат или использовать активную проверку там, где разрешён только пассивный сбор данных.
Переиспользуемые инструкции и сценарии обычно полезнее, чем новый импровизированный промпт для каждой задачи. Они делают процесс стабильнее и позволяют исправить ошибку один раз, а не ловить её в каждом следующем запуске.
После настройки базовой конфигурации её можно проверить на общем полигоне AI-челленджа, где результат агента можно сравнить с собственным прохождением и подходом эксперта.
Подготовьте безопасное окружение
Первый запуск не стоит проводить на рабочей инфраструктуре или цели, ошибка на которой может причинить ущерб. Начинать лучше с простой задачи в изолированном окружении.
Перед запуском проверьте:
- агент работает с минимальными правами;
- секреты не записаны в системные инструкции и файлы журнала;
- сетевой доступ ограничен разрешёнными адресами;
- разрушительные команды заблокированы;
- критические действия требуют подтверждения;
- установлены лимиты времени, запросов и расходов;
- всю последовательность действий можно восстановить по журналу;
- оператор может немедленно остановить выполнение.
Отдельного внимания требует внешний контент. Страница, репозиторий или файл могут содержать инструкции, адресованные модели. Агент не должен воспринимать их как новые правила или разрешение расширить scope.
Не принимайте уверенный ответ за подтверждённую находку
Результат работы агента необходимо проверять так же, как результат сканера или черновик младшего специалиста.
Для каждой находки попросите агента сохранить:
- исходное наблюдение;
- выполненные запросы и команды;
- полученные ответы;
- последовательность воспроизведения;
- объяснение предполагаемого влияния;
- признаки, по которым вывод можно опровергнуть.
После этого специалист повторяет проверку вручную. Если результат нельзя воспроизвести, доказательства не совпадают с описанием или влияние основано только на рассуждении модели, находку нельзя переносить в итоговый отчёт.
Особенно осторожно следует относиться к автоматически подготовленному тексту. LLM может сделать описание убедительным, даже если исходная гипотеза неверна. Поэтому сначала подтверждаются факты и только затем оформляется отчёт.
Когда агент готов к более сложной задаче
Минимальную конфигурацию можно считать рабочей, если агент:
- стабильно соблюдает scope;
- использует только разрешённые инструменты;
- сохраняет проверяемые артефакты;
- останавливается перед опасными действиями;
- отличает гипотезу от подтверждённой уязвимости;
- объясняет, почему выбрал следующий шаг;
- позволяет воспроизвести результат вручную.
Только после этого стоит расширять набор инструментов, добавлять новые сценарии и переходить к более сложным цепочкам действий.
Сборка и проверка ИИ-агента под руководством эксперта
С 10 по 17 сентября участники AI-челленджа CyberED × Standoff Hackbase смогут пройти весь цикл: собрать минимального агента на открывающем вебинаре, испытать его на полигоне, улучшить конфигурацию и сравнить своё решение с прохождением опытного багхантера.
Главный результат здесь не найденный флаг сам по себе, а понимание, где агент действительно ускоряет пентест и где управление всё ещё должен сохранять человек.
