Hacker-fixer цикл закрывает дыры в верификаторах Terminal Bench, KernelBench и SETA

Агентные среды стали основой для обучения и оценки LLM: программный верификатор превращает результат сложной работы в награду. Но верификатор тоже код, и его можно обмануть. Агент получает полный балл, не решив задачу, а оценка и обучение уходят в сторону. Авторы новой работы предлагают закрывать такие дыры автоматически. Метод они применили к трём средам, Terminal Bench, KernelBench и SETA, и во всех трёх заметно снизили долю успешных атак. Ранняя версия цикла уже принята в официальный репозиторий Terminal Bench как инструмент аудита эксплойтов.

Как устроен метод

Исходный вопрос сформулирован как задача weak-to-strong: может ли сегодняшняя модель, подкреплённая большим вычислительным бюджетом, заранее укрепить среду так, чтобы более сильные будущие модели не смогли её взломать? Ответ строится из двух шагов.

Сначала создаётся изолированная песочница для верификатора, которую агент не может напрямую менять. Это закрывает самый грубый класс обходов, когда агент правит проверяющий код или данные, от которых зависит оценка. Затем запускается цикл hacker-fixer. Одна роль пытается получить полную награду без выполнения задачи. Другая анализирует найденный обход и чинит верификатор. После этого цикл повторяется на обновлённой версии.

Ключевые параметры, которые указывают авторы:

• изоляция верификатора: агент не может напрямую его модифицировать;
• автоматика: поиск и исправление уязвимостей идут без ручного разбора;
• среды проверки: Terminal Bench, KernelBench, SETA;
• масштабирование: защита усиливается с ростом числа итераций цикла;
• база сравнения: статический неитеративный вариант, который итеративный цикл превосходит;
• внедрение: ранняя версия цикла используется в официальном репозитории Terminal Bench.

Почему итерации важны

Статическая проверка находит то, что очевидно в момент аудита. Но исправление одной дыры нередко открывает соседнюю или делает видимой ту, что раньше маскировалась. Цикл превращает защиту в вопрос бюджета: чем больше раундов вы готовы оплатить, тем жёстче итоговый верификатор. Авторы отдельно показывают, что качество защиты растёт с числом итераций, а не выходит на плато после первой правки.

Выбор площадок тоже содержателен. Terminal Bench проверяет работу агента в терминале, KernelBench оценивает генерацию GPU-ядер, где легко подменить измерение вместо ускорения кода. SETA относится к тому же классу сред. Это разные типы задач и разные поверхности атаки, и метод работает на всех трёх.

Ограничения тоже видны. В аннотации нет конкретных цифр: сказано лишь, что атаки снижены «существенно». Предположение weak-to-strong проверяется экстраполяцией: взломщиком выступает текущая модель, и остаётся открытым вопрос, насколько найденные ею дыры покрывают пространство атак более сильных систем. Это мой вывод из постановки задачи, а не утверждение авторов. Подробности стоит искать на странице проекта verifier-hardening.github.io.

Что делать командам, которые строят окружения

Для тех, кто собирает RL-среды или бенчмарки, главный практический вывод простой: проверку награды надо тестировать так же систематически, как и самого агента. Минимальный набор: вынести верификатор из пространства, доступного агенту, и закладывать в процесс релиза состязательный раунд, где модель целенаправленно ищет способ получить балл без решения задачи. Найденные обходы лучше сохранять как регрессионные тесты.

Если вы публикуете бенчмарк, имеет смысл заранее считать завышенные результаты признаком не успеха, а дефекта среды. Опыт Terminal Bench показывает, что такой аудит можно встроить прямо в репозиторий. Чем больше сред обучаются на одном и том же классе верификаторов, тем дороже обходится каждая незамеченная дыра, и автоматический цикл здесь дешевле ручной проверки.