Breaking Agent Backbones

Введение

AI-агенты, использующие LLM как «backbone» - ядро системы, быстро распространяются, однако оценка их безопасности сложна по двум главным причинам. Во-первых, агенты работают как последовательность неоднозначных вызовов моделей, по сути в режиме black-box, что мешает однозначно спрогнозировать исполнение и точки атаки. Во-вторых, LLM не могут программно отличать данные от инструкций — именно эта способность делает их полезными, но одновременно создаёт новые уязвимости в виде инъекций инструкций, которые затем переплетаются с классическими уязвимостями ПО.

Цель поставленная авторами - системно изучить, как выбор LLM влияет на безопасность агента. Для этого предлагается: первое - формальная модель агента, второе - новая абстракция threat snapshots, которая локализует уязвимость в конкретном состоянии (то есть не требует моделирования всего жизненного цикла агента). На её основе строится бенчмарк b3 и собирается большой набор адаптированных атак.

Threat Snapshots

Threat snapshot — это формальная структура, описывающая:

• одно конкретное состояние исполнения агента;
• как атакующий может изменить контекст;
• какова цель атаки;
• как измеряется успех.

Это позволяет локализовать уязвимости LLM и отделить их от проблем окружающего софта, не моделируя полностью всего агента.

Каждый threat snapshot содержит два компонента:

Agent state (состояние агента)

• описание агента (Agent description) — его функциональность и возможности;
• описание состояния агента в момент атаки (Agent state description) — время и почему агент там оказался;
• полный неповреждённый контекст (State model context) — контекст, который будет передан LLM в этот момент, включая system prompt, историю, файлы, определения инструментов и т. д.

Threat description (описание угрозы):

• классификация атаки (Attack categorization) - вектор доставки, цель и тип атакуемой функции LLM;
• функция/правила(Attack insertion) - данные, которые превратили чистый контекст в зловредный;
• оценка атаки (Attack scoring) — функция, дающая числовую оценку успешности атаки, то есть насколько выход LLM приближается к намерению атакующего.

Классификация атаки

Авторы предлагают две комплементарные категоризации:

Vector-objective (вектор — цель):

• Векторы:
• direct - атакующий рассматривается как пользователь LLM и напрямую подаёт текст
• indirect - атакующий встраивает payload во внешний источники: cайты, файлы, RAG, памяти, tool-defs и т. п.
• Цели:
• data exfiltration;
• content injection;
• decision & behavior manipulation;
• denial-of-service;
• system & tool compromise;
• content policy bypass.

Task-type (по целевой функции LLM):

• DIO — Direct Instruction Override;
• IIO — Indirect Instruction Override;
• DTI — Direct Tool Invocation;
• ITI — Indirect Tool Invocation;
• DCE — Direct Context Extraction;
• DAIS — Denial of AI Service.

Это разделение полезно для оценки того, какие аспекты вывода/инструментов уязвимы у той или иной модели.

Benchmarking Backbone LLMs - b3

Авторы используют threat snapshots как основу для бенчмарка b3 (backbone breaker benchmark). Они описывают три ключевых шага:

• выбор snapshot'ов;
• сбор атак;
• процедура оценки.

Выбор threat snapshots

Авторы выбрали 10 threat snapshots, каждый с тремя уровнями защиты:

• L1 — минимальные ограничения (слабый system prompt);
• L2 — более сильный системный prompt и, если релевантно, больше «чистых» данных в контексте,
• L3 — добавлен LLM-as-judge поверх L1, где используется тот же backbone только как судья.

Эта структуризация позволяет сравнивать модели при разных настройках prompt-защиты и смотреть, что даёт self-judge. Авторы при этом сознательно не добавляют внешние защитные механизмы чтобы сосредоточиться именно на ядре агента, хотя benchmark можно запускать и с внешними защитами.

Критериями выбора послужили:

• покрытие всех векторов атак и целей (vector-objective);
• покрытие всех целевых функции LLM (task-types);
• охват разных форм генерации;
• охват разных способов организации контекста.

Cбор атак (crowdsourcing)

Для генерации сильных, адаптированных атак авторы провели геймифицированный red-teaming челлендж(Gandalf Agent Breaker challenge). Пользователи получили интерфейсы, описания агентов, цели атак и получали баллы за эффективность атаки (0–100). Участники могли продвигаться по уровням, рейтинг велся в лидерборде.

Статистика сбора:

• 947 пользователей;
• 2400 сессий;
• 194 331 уникальная атака, из которых 10 935 были успешными (score > 75).

Чтобы отобрать бенчмарк-набор, авторы:

• повторно отправили все успешные атаки на 7 backbone-моделей, используемых в челлендже;
• усреднили результаты по моделям и повторам;
• выбрали топ-7 атак для каждой комбинации threat snapshot × уровень

Таким образом в итоговый набор вошло 210 сильных атак (7 атак × 10 snapshot × 3 уровня). Авторы также отмечают, что самые сильные атаки были удалены из публичного датасета.

Процедура оценки (evaluation)

Авторы проводили оценку опираясь на алгоритм

• брали одну модель (например, GPT-4 или Claude);
• выбирали набор ситуаций (threat snapshots);
• каждую атаку вставляли в контекст, то есть добавляли вредоносную фразу, подсказку или кусок кода;
• запускали модель несколько раз (обычно 5 повторов);
• автоматически оценивали каждый результат функцией “оценки успеха атаки”;
• собирали все оценки и вычисляли среднее, тем самым получая уязвимость модели.

Чем выше итоговый балл, тем легче обмануть модель и следовательно хуже безопасность.

Чтобы всё было честно авторы сделали несколько важных вещей:

• Запускали каждую атаку несколько раз, чтобы убрать влияние случайности.
• Вычисляли доверительный интервал — чтобы показать, насколько надёжно различие между моделями (то есть не просто “эта модель чуть лучше”, а “лучше с высокой статистической уверенностью”).
• Разделили наборы атак по категориям — можно смотреть не только общий рейтинг, но и, например:
• как модель ведёт себя при прямых атаках (direct injection),
• как реагирует на поддельные инструменты,
• как защищается от утечки данных и т.д.

Эксперименты

Авторы протестировали 31 LLM на бенчмарке b3, используя выбранные 210 атак и 5 повторов. Так как для некоторых моделей возможно включать/отключать режим reasoning, авторы прогнали модели и с reasoning, и без.

Устойчивость

Авторы проверяли, как чувствителен финальное ранжирование моделей к архитектурным решениям бенчмарка:

• выбору атак;
• процедуре агрегации по snapshot;
• набору snapshot'ов.

В результате в стате приводятся следующие выводы:

1. Ранжирование устойчиво к модификациям, наиболее важен качество атак — слабые атаки искажали результаты сильнее всего.
2. Процедура агрегации (усреднение и т. п.) не сильно влияет на ранжирование.
3. Выбор snapshot-ов представляется достаточно репрезентативным. Дополнительные эксперименты с 10 дополнительными snapshot'ами дали высокую корреляцию рандирования. Это подтверждает разумность набора snapshot'ов и подчёркивает важность качественных атак.

Общий рейтинг и ключевые наблюдения

Топ безопасные модели в тестах по выводам авторов статьи:

• grok-4
• grok-4-fast
• claude-opus-4-1

Включение reasoning у большинства моделей снижало уязвимость, то есть улучшало безопасность. Исключения — очень маленькие модели, у которых reasoning мог ухудшать поведение, вероятно потому, что reasoning требует достаточной ёмкости модели.

В отличие от многих capability-бенчмарков, в данной статье не наблюдается устойчивой корреляции «больший размер модели → безопаснее». При отключённом reasoning крупные модели часто не превосходили маленькие.

В среднем закрытые системы показывали лучшую безопасность — но это может объясняться тем, что закрытые системы включают дополнительные ограничения вне базовой модели. Лучший open-weights пример (gpt-oss-120b) всё же весьма близок к хорошим системам.

Более новые и более дорогие модели в среднем немного лучше по безопасности, но эффект не сильно большой.

Модели показывают различное поведение на разных типах задач: некоторые модели лучше на задачах content-safety, другие — на tool-invocation или context-extraction. Поэтому выбор backbone должен учитывать специфический use-case агента. Авторы демонстрируют, что лучшие/худшие модели остаются похожими при разной защите L1/L2/L3, но сильно различаются при разрезе по task-type.

Вывод

Авторы выделили и формально определили уязвимость LLM в контексте агентов, предложили threat snapshot как абстракцию и создали бенчмарк b3, опираясь на репрезентативные snapshot'ы и крупный набор атак.

Ключевые эмпирические наблюдения: reasoning часто улучшает безопасность, размер сам по себе не панацея, закрытые системы показывают преимущество в безопасности.

Также авторы подчеркивают и ограничения бенчмарка, так как не учитывали utility/latency и внешние мехнизмы защиты. Особенным ограничением в данном подходе является ограничение масштаба атак в потоке агента в виду его изоляции от внешней среды.

Однако b3 даёт практическую методологию и набор данных для сравнения. Так разработчики агентов могут выбрать модель с учётом типовых угроз (task-type), а разработчики моделей получат стимул улучшать именно безопасность самих моделей.