Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Управляющую обвязку ИИ-агента научили автоматически перестраивать по описанию новой атаки или нескольким примерам, не меняя саму LLM. В опыте средняя доля успешных атак снизилась с 48,96% примерно до 30–31% даже при переносе защиты между базовыми моделями. Для продуктовой команды это сокращает путь от отчёта об угрозе до исполняемых ограничений; поскольку препринт не рецензирован, все приведённые числа получены его авторами.
Из описания атаки получается исполняемое правило
Обвязка агента (harness) хранит историю работы, передаёт модели наблюдения, исполняет вызовы инструментов и решает, какие действия разрешить. Поэтому она может остановить опасную операцию уже после ответа модели, но до изменения файла, отправки сообщения или вызова внешнего API.
HASTE сначала отделяет механизм атаки от деталей конкретного примера. Из отчёта или нескольких наблюдений система составляет спецификацию: какие возможности есть у атакующего, через какой канал приходит вредная инструкция и какое поведение она пытается вызвать.
Затем один агент формирует требования к защите, а другой независимо создаёт атакующие и нормальные сценарии. Третий агент правит текущую обвязку по требованиям: не переписывает её с нуля, а добавляет ограничения к уже накопленной защите.
Изменения могут включать порядок операций, управление доступом к инструментам, проверку аргументов и дополнительную оценку действий моделью. В примерах из работы обвязка требует сначала прочитать состояние, а затем разрешает запись; опасные инструменты становятся доступны только после проверки, а структурно распознаваемые риски блокируют обычные правила программы.
Новые атаки проверяют защиту, но не подсказывают ей ответ
Главная проблема редких свидетельств — переобучение на случайных деталях. Если инженер получил один вредоносный запрос, он может заблокировать его формулировку, но пропустить тот же механизм в выводе инструмента, памяти агента или внешнем документе.
HASTE разрывает эту связь. Сгенерированные атакующие сценарии не показывают ни агенту, который пишет требования, ни агенту, который меняет код. Обновлённая обвязка встречает их только во время проверки, поэтому не может напрямую подстроиться под конкретный тест.
Судья оценивает две стороны результата. Для вредоносного сценария он проверяет, остановил ли агент опасное действие. Для нормального — выполнил ли агент задачу, а не отказался от неё ради формальной безопасности. Объяснения ошибок возвращаются генераторам требований и сценариев, после чего цикл повторяется.
Работу проверяли на Agent-SafetyBench и STAC с четырьмя базовыми моделями, включая Qwen3-8B и GPT-5.4-mini. Источником угроз служили как исследовательские статьи, так и наблюдаемые примеры; стандартный опыт включал пять циклов адаптации и 16 проверочных сценариев. Полный набор бенчмарка при адаптации оставался скрыт и использовался только для итоговой оценки.
Если примеров атаки нет, HASTE опирается только на созданные сценарии и возвращает последнюю версию обвязки. Если несколько примеров доступны, они остаются постоянным контрольным набором: система выбирает версию, которая лучше совмещает безопасность и выполнение полезных задач. Именно фиксированные примеры уменьшают дрейф при последовательном появлении новых угроз.
Командам нужен новый контур обновления, а не новая модель
В опыте с переносом между базовыми моделями доля успешных атак у агента без защиты составляла 48,96%. Обвязки, созданные HASTE на другой модели, давали в среднем 30,03–31,06%. Доля безопасно и полезно выполненных задач при этом выросла как минимум на 9,66 процентного пункта.
Результат поддерживает архитектуру, в которой защиту агента обновляют отдельно от LLM. Команде не нужно ждать нового обучения модели: описание угрозы можно превратить в правила исполнения, проверить на сгенерированных атаках и перенести на другой базовый стек.
Это не означает, что HASTE можно сразу подключить к производственной системе и разрешить ему самостоятельно менять контроль доступа. Практический контур должен применять правки сначала в изолированной среде, сохранять прежнюю версию обвязки и пропускать изменения через проверку кода. Сгенерированные нормальные сценарии также не заменяют регрессионные тесты конкретного продукта.
Работа не измеряет экономию инженерного времени и не сравнивает HASTE с ручными правками по затраченным часам. Её аргумент уже: состязательный цикл лучше расширяет несколько свидетельств об атаке, чем обновление на одном фиксированном наборе примеров, а постоянные реальные примеры удерживают систему от постепенного ухода в сторону.
Поэтому планы стоит менять прежде всего командам, у которых агент выполняет внешние действия и уже имеет программную обвязку. HASTE предлагает добавить в неё отдельный процесс безопасности: разобрать новую угрозу, создать встречные сценарии, предложить изменение, проверить безопасность и полезность, а затем выпустить версию через обычный контроль изменений.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
