Как измерить успешность выполнения различных агентами повседневных задач в сфере кибербезопасности?
Многие компании уже используют агентов в своей экосистеме разработки и развертывания, а злоумышленники иногда применяют целые рои атакующих агентов для одновременного нападения на тысячи компаний. Чтобы помочь специалистам по защите подготовиться к этой новой эре, нам нужна оценка, позволяющая сравнивать возможности таких агентов. Учитывая важность этого вопроса, академические лаборатории и представители индустрии начинают работать над методами измерения и установлением стандартов правильного выполнения таких оценок, поэтому данная тема является своевременной и все более актуальной.
В этой статье я поделюсь ключевыми принципами, которыми руководствовалась компания Wiz при решении этой задачи по созданию бенчмарка в рамках перезапуска нашей платформы Cyber Model Arena. Полная методология, а также информация о том, как мы проводили оценку и собирали задачи, доступны для скачивания. На момент написания этого блога Wiz Cyber Model Arena v3.9 включает 26 моделей, четыре универсальных инструментария, 59 агентов, 327 испытаний, три попытки на каждое испытание и по 1000 секунд на выполнение (эти цифры постоянно растут).
Чтобы создать бенчмарк, сначала определите его цель. Затем выстраивайте вокруг нее задачи, среду и систему измерений. Я подробно остановлюсь на этом и объясню принципы, которыми следует руководствоваться в процессе, далее в этой статье.
Основные выводы
- Выбирайте правильные задачи. Определите «зачем» (цель), «что» (данные, эталонные значения и настройка агента) и «как» (метрики, функция оценки) до того, как приступите к написанию первой задачи. Формируйте данные на основе реального распределения, где это возможно, а не на основе задач, сгенерированных или размеченных ИИ.
Выбирайте правильные задачи. Определите «зачем» (цель), «что» (данные, эталонные значения и настройка агента) и «как» (метрики, функция оценки) до того, как приступите к написанию первой задачи. Формируйте данные на основе реального распределения, где это возможно, а не на основе задач, сгенерированных или размеченных ИИ.
- Оценивайте с помощью кода, а не LLM. Измеряйте успех напрямую и детерминированно, а также применяйте меры по борьбе с мошенничеством: изолируйте агента от сервера и интернета, не давая ему возможности искать ответы. Не полагайтесь на LLM в качестве судьи, если только она не спроектирована должным образом, откалибрована и свободна от предвзятости.
Оценивайте с помощью кода, а не LLM. Измеряйте успех напрямую и детерминированно, а также применяйте меры по борьбе с мошенничеством: изолируйте агента от сервера и интернета, не давая ему возможности искать ответы. Не полагайтесь на LLM в качестве судьи, если только она не спроектирована должным образом, откалибрована и свободна от предвзятости.
- Оптимизируйте оценку для реалистичности. Оценивайте инструментарий и модель вместе, давайте агенту более одной попытки и соизмеряйте успех со стоимостью решения.
Оптимизируйте оценку для реалистичности. Оценивайте инструментарий и модель вместе, давайте агенту более одной попытки и соизмеряйте успех со стоимостью решения.
- Избегайте распространенных ошибок. Использование LLM в качестве судей, малые выборки, несбалансированность задач, оценка только модели и утечка ответов делают бенчмарк ненадежным. Начинайте с малого: один инструментарий, быстрая и дешевая модель, несколько задач и простой оценщик. Масштабируйте только после того, как все заработает.
Избегайте распространенных ошибок. Использование LLM в качестве судей, малые выборки, несбалансированность задач, оценка только модели и утечка ответов делают бенчмарк ненадежным. Начинайте с малого: один инструментарий, быстрая и дешевая модель, несколько задач и простой оценщик. Масштабируйте только после того, как все заработает.
Начните с постановки проблемы
Большинство публичных бенчмарков для киберагентов отвечают на вопросы, отличные от тех, что задает специалист по защите. Тестовый бенчмарк с множественным выбором измеряет знания модели, а не производительность в реальных условиях, а вывод LLM, оцениваемый другой моделью, измеряет согласие между ними, а не успех. Мы стремимся ответить на вопрос, может ли агент выполнить реальную атаку.
Запишите один вопрос, на который должен отвечать ваш бенчмарк, и проверяйте каждое последующее решение на соответствие ему. Наш вопрос:
Имея только инструкцию к задаче, универсальный каркас агента, бюджет в 1000 секунд и отсутствие внешних источников знаний, производит ли агент проверяемый эффект на реальной цели?
Имея только инструкцию к задаче, универсальный каркас агента, бюджет в 1000 секунд и отсутствие внешних источников знаний, производит ли агент проверяемый эффект на реальной цели?
Отчет Wiz Research «Состояние ИИ в облаке 2026» показал, что не менее 57% организаций развернули технологию самохостируемых ИИ-агентов, а серверы MCP присутствуют как минимум в 80% наблюдаемых облачных сред. Люди уже покупают эти системы и защищаются от них. Вот в чем причина. Остальная часть этой статьи посвящена тому, как создать числовой показатель, который будет служить этой цели.
Спроектируйте свой бенчмарк
Определите три вещи, прежде чем создавать свое первое испытание.
Зачем. Специалист по защите или покупатель должен иметь возможность принять решение на основе полученного числа. «Более высокий показатель pass@1» — это не причина. «Может ли этот агент в текущем виде эксплуатировать реальную цель, основываясь только на инструкции?» — вот это причина.
Что. Назовите объект оценки. В данном случае это агент (модель + инструментарий + инструменты + системный промпт), управляемый злоумышленником, поэтому мы используем реалистичные ограничения: 1000 секунд, три попытки, простой системный промпт и доступ к клиентскому коду, но не к серверному.
Как. Важно, чтобы бенчмарк выдавал единую итоговую метрику для каждого примера. Чтобы свести множество конкурирующих метрик к одному числу, выберите одну оптимизирующую метрику, а все остальное рассматривайте как ограничивающие условия. Если у вас пять конкурирующих метрик и нет способа их сократить, вопрос о том, какой агент лучше, превращается в спор о самих метриках.
Сделайте задачи соответствующими работе
Бенчмарк может говорить только о тех задачах, которые он содержит. Если вы выбираете только сложные задачи, вы больше не измеряете успех в работе, вы измеряете успех в решении сложных задач. А бенчмарк, который претендует на измерение «наступательного потенциала» на основе одной категории задач, переоценивает свои возможности.
Поэтому мы создали четыре категории равного веса на основе источников, которые уже существуют в реальности. Мы не генерировали и не размечали задачи с помощью LLM.
Поведение агентов сильно различается от категории к категории. В среднем по 59 агентам показатель pass@1 составляет 78,0% для безопасности API, 64,6% для веб-безопасности, 56,5% для облачной безопасности и 38,2% для уязвимостей в коде. Лучший агент в целом набирает 74,7% в веб-безопасности и 65,8% в коде (при этом максимум в веб-безопасности достигает 90,8%). Другой агент набирает 9,7% в коде и при этом 71,6% в API.
Размер тоже имеет значение. Многие недавние бенчмарки по кибербезопасности содержат менее 30 задач. При уровне успеха в 50% 30 задач дают 95% доверительный интервал примерно ±18 пунктов, поэтому агент, набравший на 15 пунктов больше другого, не обязательно является лучшим.
Оценивайте эффект, а не с помощью LLM
Эталонные значения — основа оценки. Стандартной практикой стало оценивание с помощью LLM-судьи, но судьи не измеряют успех напрямую. Они предвзяты (часто предпочитают первый вариант), случайны (дают разные результаты при каждом запуске), дороги, медленны, и их необходимо калибровать и избавлять от предвзятости, прежде чем использовать в долгосрочном бенчмарке. Когда вы используете судью, вы измеряете, считает ли LLM, что агент преуспел. Эта разница — долг, заложенный в систему.
Вместо этого мы используем код. Каждое задание разработано так, чтобы оставлять проверяемый результат или предоставлять точные структурированные выходные данные, которые затем анализируются детерминированным оценщиком после завершения работы агента. Программные оценщики недороги, их можно запускать повторно, и они не являются моделью, которую нужно калибровать.
Защита от мошенничества через изоляцию
Агенты будут искать способы обойти задачу, когда это возможно. Они ищут ответ в интернете, читают решение с диска или манипулируют оценщиком. Оценка, полученная с помощью веб-поиска, базы данных CVE или названия задачи в папке, измеряет нечто иное: успех в выполнении задачи или успех в её взломе. CTFusion повысили свой показатель успешности на целых 12 пунктов, просто расширив доступ к веб-поиску.
Что касается загрязнения данных, мы не можем доказать, что наши агенты никогда не видели задачу во время предварительного обучения. Но мы можем доказать, что они не могут получить к ней доступ во время испытания. Защита от мошенничества должна быть реализована в среде, а не в промпте.
Начинайте с малого
Создание бенчмарка — это нетривиальная и развивающаяся задача, и возникает соблазн написать 300 заданий, прежде чем что-либо заработает от начала до конца. Вместо этого мы применяем правила бережливого стартапа: создайте небольшую базовую систему, которую можно проверить вручную, а затем итерируйте.
Вам нужны десять задач, которые можно перезапускать, одна система (harness), которую можно развернуть, и метрика оценки, которую может проверить оценщик. Убедившись, что всё работает, вы сможете масштабировать систему.
Что мы обнаружили
Сочетайте систему с моделью
Модель сама по себе — это лишь предсказатель текста. Она становится атакующим внутри системы, которая выполняет команды и применяет инструменты, при этом модели показывают разные результаты в разных системах. Среди 22 моделей, которые мы протестировали как в Claude Code, так и в ADK React, средний абсолютный разрыв составил 5,1 балла pass@1. Модели Claude предпочитают Claude Code, а Gemini 3.8 Flash Cyber — более легкий цикл ADK.
Вывод: тестируйте систему в целом. Либо подбирайте систему под модель (и, как мы убедились, лучше всего сочетать систему с создателем модели), либо зафиксируйте одну общую систему и сравнивайте модели внутри неё.
У атакующих есть больше одной попытки
Настоящий атакующий не останавливается после одной неудачи. Мы дали каждому агенту по три попытки на каждое задание, и дополнительные попытки не просто повысили баллы. Для некоторых агентов они даже изменили лидера.
У точности есть цена
Дайте агенту больше времени и денег, и обычно он решит больше задач. Поэтому полезный график отображает успех в зависимости от стоимости решения. Любой агент, находящийся вне границы Парето, объективно хуже того, что находится на ней. Например, Claude Code с GPT-5.6 Sol в среднем показывает 64,2% pass@1 при стоимости $8,29 и 27,2 минутах на решение, однако граница Парето Codex + GPT-6 Luna объективно лучше: в среднем 64,5% pass@1 при стоимости всего $0,05 и 6,3 минутах на решение.
Держите короткий список агентов на границе Парето и игнорируйте остальных. Это позволит вам задать вопросы: «как максимизировать успех при данном бюджете?» или «как минимизировать затраты при данном уровне успеха?»
Ограничения
- Четыре простые системы. Кибер-специализированная система, вероятно, показала бы более высокие результаты, но мы решили измерить простого атакующего.
Четыре простые системы. Кибер-специализированная система, вероятно, показала бы более высокие результаты, но мы решили измерить простого атакующего.
- Строковое сравнение уязвимостей кода. Семантически верная первопричина, в которой отсутствует ожидаемый символ, получает 0 баллов. Мы выбрали точность в ущерб полноте.
Строковое сравнение уязвимостей кода. Семантически верная первопричина, в которой отсутствует ожидаемый символ, получает 0 баллов. Мы выбрали точность в ущерб полноте.
- Публичные веб-задачи. websec.fr — известный корпус задач. Изоляция мешает агенту искать ответ, но не мешает помнить его из обучения (что потенциально приводит к загрязнению бенчмарка).
Публичные веб-задачи. websec.fr — известный корпус задач. Изоляция мешает агенту искать ответ, но не мешает помнить его из обучения (что потенциально приводит к загрязнению бенчмарка).
- Ограничение по времени. 1000 секунд достаточно для большинства успешных атак, которые мы наблюдали. В будущем мы считаем, что лучше ограничивать стоимость, а не время.
Ограничение по времени. 1000 секунд достаточно для большинства успешных атак, которые мы наблюдали. В будущем мы считаем, что лучше ограничивать стоимость, а не время.
- Доверительные интервалы. Мы еще не опубликовали их на сайте, но работаем над этим.
Доверительные интервалы. Мы еще не опубликовали их на сайте, но работаем над этим.
Заключение
Наша Cyber Model Arena показывает, как разные агенты справляются с типичными задачами кибербезопасности на примере 327 изолированных заданий в четырех категориях. Чтобы создать агентный бенчмарк по кибербезопасности, сначала определите «почему», «что» и «как», а также задайте агента, набор задач, оценщика, изоляцию, бюджет и количество попыток. Ошибитесь в чем-то одном, и бенчмарк превратится в «мусор на входе — мусор на выходе».
Приложение: результаты для всех 59 агентов
Каждый агент, отсортированный по pass@1. Баллы указаны в процентах.
