AI-агент нашёл уязвимость, построил цепочку атаки и добрался до цели. Выглядит убедительно — но один удачный прогон ещё не показывает, что перед нами рабочий инструмент. Он мог выбрать удачный маршрут, получить особенно полезный ответ модели или незаметно опереться на подсказку человека.
Если хотите увидеть, как AI-агенты меняют наступательную безопасность, найм и турниры, приходите на открытый эфир CyberED × Standoff 365.
А ниже разберём, как отделить воспроизводимую способность агента от красивого совпадения.
Демо показывает возможность, испытание — надёжность
Успешная демонстрация отвечает на узкий вопрос: «Может ли система решить эту задачу хотя бы один раз?» Для практического применения нужен другой ответ: «С какой регулярностью она решает задачу в одинаковых условиях, какой ценой и с какой помощью человека?»
Для AI-пентестера эта разница особенно важна. Его работа состоит из цепочки решений: что проверить, какой инструмент вызвать, как интерпретировать вывод, куда двигаться после ошибки. На каждом шаге возможен другой выбор. Поэтому два запуска с одним заданием способны разойтись уже после первых действий. Один завершится найденной уязвимостью, другой уйдёт в бесполезную ветку, третий остановится после неудачного вызова инструмента.
Такой разброс нельзя спрятать за лучшим результатом. Иначе оценивается не агент, а самый удачный эпизод из его истории.
Сначала зафиксируйте проверяемую способность
Формулировка «проверить, хорошо ли агент проводит пентест» слишком расплывчата. До запуска нужно описать конкретную способность: например, найти подтверждённый путь эксплуатации в заданном контуре, выявить уязвимости определённого класса или восстановиться после ошибки инструмента и продолжить исследование.
Одновременно задают критерий успеха. Им не должен быть красивый отчёт или уверенный вывод модели. Засчитывается проверяемый результат: воспроизводимое доказательство эксплуатации, корректно найденный артефакт, подтверждённая ручной проверкой уязвимость. Если результат невозможно независимо проверить, это наблюдение, а не успешное прохождение.
Полезно заранее определить и неуспех: ложное срабатывание, пропущенная известная уязвимость, выход за разрешённые границы, исчерпание бюджета, потеря состояния или остановка без внятной причины. Тогда неудобный результат не получится задним числом переименовать в «частичный успех».
Условия должны быть одинаковыми
Честное сравнение начинается не с выбора модели, а с фиксации среды. Для каждого прогона нужны один и тот же scope, одна версия целевого стенда, одинаковое начальное состояние, одинаковый набор инструментов и единые ограничения на действия.
Нужно заморозить и конфигурацию самого агента: системные инструкции, модель, параметры генерации, доступный контекст, механизм памяти, версии инструментов и правила обработки ошибок. Если между прогонами незаметно меняется промпт или человеку разрешают добавить контекст, сравниваются уже разные системы.
Важно начинать каждый запуск с чистого состояния. Остатки файлов, история команд, кэш и сохранённые наблюдения могут превратить повторный прогон в продолжение предыдущего. Это полезно для работы, но искажает испытание.
Бюджет — часть результата
Агент, которому дали втрое больше времени, токенов или вызовов инструментов, получил другое условие задачи. Поэтому до серии прогонов фиксируют бюджет: предельное время, число шагов или обращений к модели, допустимые вызовы инструментов и лимит вычислительных затрат.
Сам по себе факт успеха без этой информации мало что значит. Система, которая иногда добирается до цели после длинного перебора, и система, которая регулярно находит короткий путь, имеют разную практическую ценность. В итогах стоит показывать не только число успешных запусков, но и стоимость каждого подтверждённого результата.
Те же вопросы о границах автономности, инструментах и подготовке специалистов мы разберём подробнее на эфире об AI-агентах в offensive security.
Один сценарий нужно запускать несколько раз
Единичный прогон измеряет событие. Серия прогонов показывает распределение результатов. Минимально полезный отчёт должен отвечать на несколько вопросов:
- в какой доле запусков достигнут заранее заданный критерий успеха;
- насколько различаются найденные пути и затраты;
- какие ошибки повторяются, а какие возникают случайно;
- стабильно ли агент подтверждает находки или часть из них исчезает при проверке;
- способен ли он продолжить работу после сбоя инструмента или неверной гипотезы.
Число повторов выбирают до старта, а не после первого успеха. Иначе возникает соблазн остановить эксперимент в удачный момент. Если сравниваются две конфигурации, каждой дают одинаковое число попыток и тот же бюджет. Между сериями меняют одну переменную — например, модель или правила памяти, — иначе причину улучшения невозможно установить.
Помощь человека нельзя прятать
Вмешательство оператора не делает результат бесполезным. Оно просто меняет объект измерения. После подсказки тестируется уже не автономный агент, а связка «агент плюс человек».
Поэтому каждое вмешательство нужно записывать: когда оно произошло, что именно сделал оператор и без чего запуск, вероятно, не продолжился бы. Это может быть уточнение задания, исправление команды, перезапуск инструмента, добавление потерянного контекста, выбор следующей гипотезы или ручное подтверждение находки.
В итогах полезно разделять полностью автономные успехи, успехи после технического восстановления и результаты, достигнутые после содержательной подсказки. Тогда видно не только дошёл ли агент до цели, но и где проходит настоящая граница его самостоятельности.
Сохраняйте не вывод, а доказательства
Итоговый отчёт агента — уже интерпретация. Для разбирательства нужны исходные артефакты: точная конфигурация запуска, запросы и ответы модели, последовательность действий, команды и вывод инструментов, временные метки, изменения состояния, найденные файлы и доказательства эксплуатации.
Без них нельзя понять, почему два прогона разошлись, воспроизвести спорную находку или отличить ошибку модели от сбоя инструмента. Особенно опасны аккуратные отчёты, в которых исчезли неудачные ветки: они создают впечатление прямого и осмысленного пути, хотя реальный запуск мог состоять из перебора и случайных догадок.
Артефакты стоит хранить в исходном виде, а выводы аналитика — отдельно. Тогда повторная проверка не зависит от первоначальной трактовки.
Хороший итог может выглядеть скромно
Честное испытание редко заканчивается фразой «агент взломал систему». Обычно результат сложнее: агент стабилен на разведке, но теряет контекст в длинных цепочках; находит известный класс уязвимостей, но создаёт ложные срабатывания; достигает цели только после подсказки; успешно работает, пока инструменты отвечают ожидаемо.
Именно такая детализация полезна. Она показывает, где агент уже экономит время, где ему нужен контроль и какие изменения действительно улучшили систему. Лучший единичный прогон годится для демонстрации возможностей. Решение о практическом применении следует принимать по повторяемости, цене, уровню человеческой помощи и качеству доказательств.
24 сентября в 19:00 МСК CEO CyberED и директор по продуктам Standoff 365 в прямом эфире обсудят, как AI-агенты изменили наступательную безопасность и подготовку пентестеров. Приходите, если хотите разобраться в теме глубже.
Зарегистрироваться и присоединиться к эфиру
