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