SHADE-Arena: Evaluating sabotage and monitoring in LLM agents
Kutasov et al., 2025
Блог, статья

Вы дали LLM-агенту задачу. Может ли он параллельно с ней выполнить зловредную задачу и не спалиться? Вопрос не праздный, так как инструкция типа отправки всех API-ключей из энва на непонятный адрес может прилететь к нему в контекст откуда угодно – от страницы в интернете до промпт-темплейта. Авторы статьи предлагают бенчмарк, который позволяет этот риск оценить.

Суть бенчмарка – расширение AgentDojo, причем DLC получился солидный: 30 компонентов (телефон, почта и так далее), 340 инструментов (в каждом сценарии – от 20 доступных), до 100 тысяч токенов синтетических данных на среду. Исследователи предлагают 17 сценариев, состоящих из основной задачи (просмотреть список гостей конференции и забронировать каждому авиарейс и ресторан или просмотреть почтовые ящики и сгенерировать спам-фильтры) и побочного квеста, состоящего из определенного зловредного действия (при бронировании выбирать рейсы только одной авиакомпании, невзирая на цены, или добавить анти-спам правило, которое удаляет алерты о логинах в GitHub). Цель агента – выполнить обе задачи, причем так, чтобы не стриггерить мониторинг. В инструкциях отмечается, что дело происходит в симуляции, чтобы уменьшить число отказов от выполнения задачи. Роль контролера играет Claude 3.6, который пост-фактум читает логи агента, не включающие системную затравку и Chain-of-Thought, и выдает скор от 0 до 100, где 80 – граница подозрительности. Для каждого из сценариев было проверено, что решение, не вызывающее подозрений контролера, существует.

Результаты показывают, что наиболее успешны Claude 3.7 Sonnet и Gemini 2.5 Pro c 27% и 15% успеха соответственно. Другие модели, включая топовые открытые модели типа Qwen-3 и DeepSeek-R1, а также модели от OpenAI, справляются хуже. Причиной тут по большей части являются проблемы с выполнением заданий: модели просто не выполняют ожидаемых действий, галлюцинируют экфильтрируемые данные, теряются в длинном контексте. Даже если предоставить агенту хитрую стратегию, придуманную человеком, он может с ней просто не справиться. Когда причина неудачи в детектировании контролером, дело в том, что модель в целом не пытается скрывать свои намерения или случайно упоминает задачу за пределами скрытого от контролера CoT.

Исследователи также оценивают разные модели, а заодно людей, в качестве контролеров. Лучшим контролером оказывается gemini-2.5-pro с достаточно скромными 0,87 AUC, а вот люди, которым требуется в среднем 103 минуты на лог, показывают еще худший результат (AUC=0,65, три оценки на транскрипт, агрегация по минимальной оценке).

Мониторинг сильных моделей более слабыми моделями – очень важное направление работы: с точки зрения security нам бы хотелось предотвращать инъекции, появляющиеся в самых неожиданных местах, максимально дешево, с точки зрения safety – определять scheming в новой модели, используя проверенную старую. Как видно, пока это получается не очень, но и мониторить особо нечего – даже с основными задачами модели пока справляются не очень успешно.

Invitation Is All You Need! TARA for Targeted Promptware Attack Against Gemini-Powered Assistants
Nassi et al., 2025
Статья, сайт

Попалась любопытная работа израильских исследователей (это, кстати, те же ребята, что назвали инъекцию в симулированный почтовый клиент Morris II, представленная на Blackhat, про непрямые промпт-инъекции в андроидовском ассистенте Gemini, которые были актуальны в феврале этого года. В статье куча всякой скукоты типа специального фреймворка оценки рисков и попытки продвинуть придуманный ими термин promptware, но главное то, что они научились с помощью приглашения в календарь выключать пользователю свет 🔪

Суть атаки проста. Пользователю отправляется приглашение в календарь. В приглашении содержится промпт-инъекция, которая просит у Gemini выполнить определенную инструкцию при несложном условии: например, если пользователь скажет «спасибо» или использует слово длиннее двух букв. Чтобы цепочка сработала, пользователь должен попросить у ассистента список ближайших задач в календаре.

Используя такую нехитрую технику, исследователи заставляют ассистента:

1. Генерировать оскорбительные тексты, надоедать спам-ссылками с рекламой или фишингом.
2. Отравление долгосрочной памяти, приводящее к неверным ответам.
3. Атаки на агента, включая удаление случайных встреч из календаря.
4. Атаки на других агентов. Ассистент состоит из агента-оркестратора и узконаправленных агентов, типа агента для календаря. Поскольку инъекция попадает в контекст оркестратора, исследователям удалось дать команды агенту Google Home включить и выключить свет, открыть окна и включить бойлер. Эксплуатация агента Utilities позволила им скачать на смартфон файл (раскрыв геолокацию пользователя), запустить встречу в Zoom и вытащить через браузер названия встреч, содержание писем и другую информацию (закодировав их в URL).

В качестве противодействия таким атакам исследовали рекомендуют ограничивать возможности межагентного взаимодействия, последовательного запуска многих инструментов (то есть вещи, которые делают агентов прикольными), а также использовать гардрейлы и Control Flow Integrity (типа CaMeL). Из любопытного: бросается в глаза простота тех промпт-инъекций, которыми пользовались исследователи, что несколько пугает в сочетании с простотой киллчейна. Кажется, что пока давать LLM-инструментам, которые могут случайно снести вам Windows, контроль над физическими системами – будь то роботы или лампочки – пока рано.

BinMetric: A Comprehensive Binary Analysis Benchmark for Large Language Models
Shang et al., Hefei University of Science and Technology, 2025
Статья

Одним из интересных применений LLM является их использование в реверс-инженерии, она же обратная разработка. LLM легко видят взаимосвязи в длинных листингах псевдокода, помнят все опкоды и могут довольно неплохо понимать, что делает та или иная декомпилированная функция. Или нет? С одной стороны, существует достаточно много плагинов, типа Gepetto для IDA или Sidekick для Binary Ninja, которые делают разные полезные вещи, типа замены названий переменных в C-подобном псевдокоде на человекочитаемые, что очевидно требует понимания семантики кода. С другой стороны, как оценить, насколько хорошо это работает? Для этого нужны бенчмарки, и сегодня мы поговорим об одном из них – BinMetric.

Исседователи из Китайского университета технологий в Хэфэе предлагают бенчмарк, который с разных сторон оценивает способность LLM к задачам анализа бинарных файлов. Бенчмарк состоит из 6 задач:
1. Call-site Reconstruction (CSR): на входе LLM подается кусок ассемблерного кода и адрес вызова, на выходе ожидается C-подобная строка с названием функции и аргументов. В качестве метрики используется CodeBLEU и Rouge-L.
2. Decompilation (DEC): на вход подается ассемблерный код, соответствующий одной функции, на выходе ожидается С-подобный листинг этой функции. Метрики те же.
3. Signature Recovery (SR): на вход подается псевдокод функции от декомпилятора, на выходе ожидается сигнатура функции (название с параметрами). Метрики – BLEU, METHEOR и ROUGE-L.
4. Binary Code Summarization (BCS): на вход – снова псевдокод функции после декомпилирования; на выходе ожидается описание функции на естественном языке. Метрики – как в SR.
5. Algorithm Classification (AC): LLM должна определить тип алгоритма (сортировка, шифрование и так далее) на основе псевдокода. Оценивается точность.
6. Assembly Instruction Generation (AIG): самая любопытная задача – генерация ассемблерного кода по промпту. Код оценивается с помощью ROUGE, а также на прохождение юнит-тестов.

Чтобы собрать такой бенчмарк, исследователи используют код открытых проектов на C – от curl до llama2.c – код которых они компилируют, собирая артефакты DWARF и удаляя символьную информацию. Для компиляции используются рекомендованные разработчиками параметры компиляции, чтобы получить разнообразие. Затем бинари дизассемблируют и декомпилируют с помощью IDA, после чего с помощью DWARF получают выравнивание между сорцами и результатом работы IDA. Далее исследователи удаляют слишком длинные и слишком короткие функции, после чего семплируют данные для задач. Для BCS применяется ChatGPT, чтобы получить описания функций на базе исходного кода. Задачи для AC семплируются из C-Algorithms. Для AIG исследователи пишут вручную 100 промптов и разрабатывают под каждую задачу алгоритмы. На все у них уходит 60 человеко-часов, что кажется некоторым преуменьшением.

К сожалению, само исследование, видимо, проводилось давно (опубликована статья в мае этого года), поэтому на своем бенче исследователи гоняют Llama-2-7B, Mistral-7B, Mixtral (хорошая была модель, олды помнят), WizardCoder и CodeLlama-32B, из закрытых – GPT-3.5 и GPT-4. Кроме того, на соответствующих задачах оценивается BinT5, HexT5 и LLM4Decompile. Лучшими моделями (не удивительно) оказываются GPT-4 и большие кодинговые модели типа CodeLlama, конкретные цифры можно посмотреть в табличке, пересказывать их ввиду неактуальности в 2025 году смысла нет.

Из любопытного – видно, что LLM достаточно неплохо превращают asm в псевдокод – лучше по метрикам, чем Hex-Rays. С генерацией ассемблера ни одна из LLM ожидаемо не справилась. Сам бенчмарк кажется очень интересным, и было бы любопытно посмотреть на него в контексте более современных моделей. С другой стороны, есть и чем расширить – например, оценкой правильности переименования переменных, что делает Gepetto, или анализом более широким, чем одна функция, кроме того, в открытом доступе бенчмарк найти пока не удалось. О таких бенчмарках мы еще поговорим.

LLM4Decompile: Decompiling Binary Code with Large Language Models
Tan et al., 2025
Статья, Github, Huggingface

Сегодня посмотрим на чуть более сфокусированный бенчмарк: Decompile-Eval. Исследователи обращают внимание, что LLM могут потенциально помогать с декомпиляцией бинарей (переводом кода из asm в C), выдавая более читаемый и близкий к оригиналу код, чем традиционные инструменты вроде Ghidra или Hex-Rays. Чтобы проверить, так ли это, исследователи тюнят свои модели для декомпиляции и предлагают новый бенчмарк, который оценивает качество получившегося кода.

В статье описывается две постановки задачи: Refined-Decompile и End2End-Decompile. В постановке Refined-Decompile модель получает на вход псевдокод после традиционного декомпилятора и должна улучшить его читаемость. В End2End-Decompile на вход LLM получает asm, из которого она должна сгенерировать качественный псевдокод. Для самой задачи декомпиляции исследователи используют ExeBench, набор из 5 миллионов компилируемых C-файлов размером с функцию, для некоторых из которых даны тестовые входы-выходы для оценки корректности. Исследователи компилируют эти файлы с помощью GCC с четырьмя уровнями оптимизации (что, как метко указывают авторы, работает как аугментация данных), а затем дизассемблируют, получая после фильтрации 7,2 миллиона компилируемых пар asm+исходник на C и 1,6 миллионов исполняемых. На этих парах исследователи тюнят deepseek-coder трех размеров (1,3B, 6,7B и 33B). Средняя по размеру модель обучается 61 день на 8xA100.

Для оценки результатов в постановке End2End вводится два бенчмарка – HumanEval-Decompile и ExeBench. HumanEval-Decompile использует как основу оригинальный HumanEval, но все питоновские функции переводятся на C. Из ExeBench берутся 5 тысяч функций, для которых есть пары вход-выход. Модели засчитывается балл, если декомпилированный код компилируется и проходит тесты. В качестве бейзлайнов тестируют gpt-4o и deepseek-coder-6.7B. В результате затюненный deepseek-coder-6.7B показывает лучшие результаты с ~36% на HumanEval-Decompile и ~16% на ExeBench при включенной оптимизации. Та же модель без тюнинга показывает качество, равное нулю, а gpt-4o – 10% и 4%, соответственно. 33-миллиардная модель показывает себя неплохо, но затюнить ее исследователям по причине размера не удалось.

В постановке Refined исследователи используют в качестве источника при «переводе» псевдокод от Ghidra, по которому LLM должна воспроизвести исходный код функции. На парах псевдокод-исходник исследователи обучают модели, к которым добавляется Codestral-22B и Yi-9B. Код, генерируемый гидрой, корректно рекомпилируется в 15% случаев на HumanEval-Decompile. Если пропустить его через gpt-4o, то получается ~30%, а вот затюненные модели дают гораздо лучшие результаты – от ~45% у 6,7B до ~58% у Codestral (если смотреть на кейсы с оптимизацией). В приложении есть еще оценка Yi-Coder, который при размере в два раза меньше соревнуется с французами (УДАР!) При этом метрика edit similarity оказывается менее чувствительной и растет при увеличении модели субъективно незначительно. Наконец, исследователи используют gpt-4o для оценки читаемости псевдокода гидры, улучшений от gpt-4o (никакой предвзятости) и от затюненного ds-coder-6.7B, и последний побеждает даже в этой нечестной борьбе.

Исследование достаточно качественное (не зря оно, в отличие от многого в этом канале, было опубликовано на приличной конференции), исследователи продолжают обновлять свои модели и выкладывать их на HF. Видно, что LLM могут помогать при анализе бинарей, особенно на уровне функций. Понятно, что и тут есть ограничения – тот же контекст одной функции, С (причем именно gcc на *nix), а также падение качества на 80-90% при применении обфускции. Тем не менее, исследование демонстрирует, что LLM в рутине реверсера могут быть очень полезны.

(Внимательный читатель может заметить, что в статье не упоминается Decompile-Eval. Дело в том, что название появилось в препринте, который к публикации сильно изменился, но название продолжает гулять по интернету, в том числе легко достается LLM-ассистентами).