Большинство специалистов начинают использовать языковые модели как продвинутый справочник. Человек описывает задачу, получает гипотезу, команду или фрагмент кода, проверяет ответ и самостоятельно решает, что делать дальше. В таком режиме граница ответственности понятна: модель предлагает, специалист оценивает и запускает. Даже если ответ оказался неверным, обычно можно восстановить ход работы и понять, на каком шаге появилась ошибка.
С ИИ-агентом эта схема меняется. Агент получает цель, планирует несколько шагов, вызывает инструменты, анализирует их вывод, сохраняет результаты в памяти и продолжает работу с учётом нового контекста. Это позволяет автоматизировать не только отдельную команду, но и целую последовательность действий. Однако вместе со скоростью появляется риск: специалист видит финальный ответ, но не понимает, какие гипотезы проверялись, какие команды запускались и почему агент выбрал именно этот путь. В этот момент полезный помощник превращается в чёрный ящик.
Проверить, насколько управляемым получился ваш агент, можно на практике. CyberED и Standoff Hackbase проводят ИИ-челлендж по пентесту: участники разберут базовую методику сборки агента, затем в течение недели испытают его на учебном полигоне и на финальном вебинаре сравнят свой подход с решением эксперта.
Агент — это не длинный промпт
Обычная LLM отвечает на запрос. Агент должен самостоятельно повторять рабочий цикл: понять текущее состояние задачи, выбрать следующий шаг, вызвать подходящий инструмент, интерпретировать результат и скорректировать план. Именно способность действовать в несколько этапов отличает его от чата, в котором каждое продолжение инициирует человек.
Сначала определите границы, потом подключайте инструменты
Формулировка «найди уязвимости» слишком широка. Из неё непонятно, какие цели разрешено исследовать, какие методы допустимы, когда следует остановиться и что считать подтверждённым результатом. Человек может восстановить недостающий контекст из договора, правил программы или собственного опыта. Агент видит только переданные ему данные и инструкции.
Перед запуском стоит описать рабочий контур:
- - цель и ожидаемый результат;
- - разрешённые узлы, приложения и типы проверок;
- - действия, которые выполнять нельзя;
- - доступные инструменты и пределы их применения;
- - критерии подтверждения найденной проблемы;
- - условия остановки;
- - случаи, когда нужно обратиться к человеку;
- - формат журнала и итогового отчёта.
Ограничения должны быть техническими, а не только текстовыми. Запрет в системной инструкции полезен, но сам по себе не блокирует выполнение команды. Надёжнее сочетать инструкцию с механическим контролем: ограничивать команды, параметры, каталоги, адреса и доступные инструменты на уровне среды выполнения.
Это особенно важно для соблюдения scope. Нельзя рассчитывать, что агент самостоятельно учтёт все условия программы или проекта. Границы тестирования необходимо задать до старта и проверять при каждом значимом действии — независимо от того, выполняет команду человек или модель.
Соберите минимальный рабочий цикл
Первый прототип не должен уметь всё. Чем больше инструментов и ролей появляется одновременно, тем труднее определить причину неудачи. Для старта достаточно короткого процесса, который легко наблюдать и повторять:
- - получить конкретную техническую задачу;
- - сформулировать одну проверяемую гипотезу;
- - выбрать разрешённый инструмент;
- - предложить параметры запуска;
- - получить подтверждение, если действие критично;
- - выполнить проверку;
- - сохранить исходные данные и результат;
- - объяснить, что изменилось в понимании задачи;
- - предложить следующий шаг.
Такой цикл кажется менее впечатляющим, чем полностью автономная система, зато позволяет отлаживать каждый элемент отдельно. Если агент выбрал не тот инструмент, проблема находится в планировании или описании возможностей. Если инструмент выбран правильно, но команда составлена неверно, нужно уточнять правила его использования. Если вывод получен, но интерпретация ошибочна, следует менять формат данных и критерии проверки.
Набор инструментов следует подбирать под конкретный этап работы. Автоматизированные цепочки хорошо подходят для повторяемых операций, но активная проверка и логические уязвимости требуют анализа контекста. Агенту не нужно запускать всё подряд: полезнее дать ему несколько понятных инструментов и критерии выбора между ними.
Не заставляйте модель заново изобретать процесс
Если каждый раз объяснять агенту порядок работы с нуля, результаты будут различаться сильнее, а настройка займёт больше времени. Повторяемые инструкции полезно оформлять как отдельные навыки: описывать назначение инструмента, допустимые параметры, последовательность проверки, признаки успешного результата и типичные ошибки.
Такой навык не должен быть огромной энциклопедией. Его задача — дать агенту проверяемый рабочий маршрут. Например: сначала уточнить область тестирования, затем получить исходные данные, после этого выбрать одну гипотезу, выполнить безопасную проверку и сохранить доказательства. Если результат неоднозначен, агент обязан обозначить неопределённость, а не превращать предположение в готовую находку.
Записывайте путь, а не только итоговый ответ
Финальный отчёт не показывает качество процесса. Агент может прийти к правильному результату после последовательной проверки гипотез, а может случайно получить его после десятков нерелевантных действий. Снаружи оба варианта выглядят одинаково: флаг найден или уязвимость описана.
Чтобы отличить методику от совпадения, нужно сохранять траекторию работы:
- - исходную цель и ограничения;
- - гипотезы агента;
- - выбранные инструменты;
- - переданные параметры;
- - необработанный вывод команд;
- - интерпретацию результата;
- - причины изменения плана;
- - запросы на подтверждение;
- - ручные вмешательства специалиста;
- - итоговые доказательства.
Логи решают сразу несколько задач. По ним можно воспроизвести удачный подход, обнаружить повторяющийся тупик и понять, какая инструкция повлияла на поведение агента. Они же помогают сравнивать конфигурации. Без журналирования улучшение системы часто сводится к случайному переписыванию промпта: новая версия иногда работает лучше, но никто не понимает почему.
Отдельно следует проверять качество отчёта. Правдоподобное описание ещё не подтверждает существование уязвимости. Агент способен уверенно связать разрозненные признаки и получить убедительный, но неверный вывод. Поэтому находка должна включать воспроизводимые шаги и доказательства, которые специалист проверил вручную. Отправлять результат, просмотрев только красиво сформулированное резюме, нельзя.
Ограничьте действия технически
Самая опасная конфигурация — агент с широкими правами и расплывчатой целью. Если ему доступны оболочка, файловая система, сетевые инструменты и учётные данные, текстового запрета недостаточно.
Безопасный контур может включать:
- - отдельную учётную запись агента;
- - минимальные права на файлы и сервисы;
- - allowlist инструментов и операций;
- - проверку параметров перед запуском;
- - запрет разрушительных команд;
- - изолированную среду выполнения;
- - лимиты частоты запросов;
- - подтверждение критических операций;
- - полное журналирование вызовов.
Точки подтверждения не нужно размещать перед каждым безобидным шагом. Они нужны там, где цена ошибки возрастает: при расширении области исследования, обращении к чувствительным данным, использовании нового инструмента, изменении окружения или выполнении потенциально разрушительной команды.
Проверяйте отказ так же тщательно, как успех
Демонстрация, в которой агент нашёл флаг, подтверждает только один сценарий. Перед самостоятельной работой его нужно испытать в условиях, где правильным результатом будет остановка.
В минимальный набор негативных тестов стоит включить:
- - попытку выйти за разрешённый scope;
- - запрос запрещённого инструмента;
- - обращение к недоступному файлу или секрету;
- - вредоносную инструкцию во внешнем контенте;
- - попытку обойти подтверждение операции;
- - повторение одного неудачного действия по кругу;
- - противоречие между исходной целью и новыми данными;
- - формирование отчёта без достаточных доказательств.
Оставьте специалисту решения с высокой ценой ошибки
Human-in-the-loop не означает, что человек вручную управляет каждой командой. Его роль — определить границы и принимать решения там, где автоматический выбор недостаточно надёжен.
Специалист должен вмешаться, если агент потерял цель, начал повторяться, не может объяснить следующий шаг, предлагает расширить scope или делает вывод, который нельзя подтвердить сохранёнными данными. Ручная проверка обязательна и перед использованием результата: найденный флаг можно принять как результат учебной задачи, но отчёт об уязвимости требует воспроизводимости и валидации.
ИИ-челлендж по пентесту: от сборки агента до разбора результатов
CyberED и Standoff Hackbase проводят практический ИИ-челлендж по пентесту. Для участия потребуется базовое понимание пентеста, веб-уязвимостей и работы с командной строкой.
10 сентября в 19:30 МСК пройдет открывающий вебинар. Эксперт вживую соберет минимального агента и доведет его до запуска на полигоне:
- - сформулирует цель и ограничения;
- - настроит базовую конфигурацию и системные инструкции;
- - подключит инструменты и навыки;
- - проверит агента на простой безопасной задаче;
- - объяснит запуск челленджа и работу с рейтингом.
С 10 по 17 сентября участники асинхронно настраивают и улучшают своих агентов, ищут и эксплуатируют уязвимости в динамических заданиях на общем полигоне Standoff Hackbase и следят за публичным рейтингом.
17 сентября эксперт покажет свое прохождение с агентом, разберет рабочие стратегии, тупиковые подходы и типичные ошибки управления агентом, после чего подведет итоги челленджа.