Безопасность SOTA-агентов общего назначения: защиты

Как защищать агентов в IDE и браузерах? Давайте посмотрим, что лидеры индустрии писали в последние полгода.

Понятно, что основой защиты является alignment, не зря модели типа o4-mini обучаются иерархии инструкций для отказа от выполнения внедренных в недоверенные документы промптов. Однако этого может быть недостаточно, и OpenAI для агентной модели, которая лежит в основе Atlas, применяет дополнительное обучение для устойчивости к промпт-инъекциям. В частности, они используют обучение с подкреплением для обучения атакующей модели, которая, имея привилегированный white-box-доступ к размышлениям цели учится находить новые («неизвестные в дикой природе») стратегии для многоступенчатых атак, которые могут разворачиваться на горизонте до сотен шагов. Следующие итерации агентных моделей обучаются быть устойчивыми к обнаруженным атакам. При этом OpenAI прямо заявляют, что кроме доступа к ризонингу их преимуществом перед другими атакующими является компьют: безопасность становится все более дорогой и завязанной на вычисления.

Те, кто не может гонять дорогой RL над модельками, ищет другие пути. Perplexity в Comet, как и OpenAI, кроме самой модели полагаются на внешние классификаторы (они же гардрейлы), чтобы отлавливать разные виды промпт-инъекций, включая многошаговые и мультимодальные. Другим (часто недоцениваемым) методом защиты в Comet является промптинг: среди приемов, описанных в статье, кроме мольбы не поддаваться на инъекции, есть spotlighting и self-reminder.

Если опасная инструкция попала в контекст, пройдя через классификаторы, и была воспринята LLM, последней линией защиты являются меры на уровне системы. Их можно условно поделить на две категории: human-in-the-loop (HITL, передача контроля человеку) и песочницы. В случае с HITL все понятно: как только шаг оценивается (LLM или детерминированно, исходя из инструмента) как рискованный, человек получает запрос на подтверждение. Такими шагами могут быть покупки, логины на сайты, отправки писем, а в случае с IDE – вызов любых инструментов, влекущих изменение среды – запись в файлы, доступ в интернет кроме разрешенных доменов, коммиты в репозиторий и так далее. К сожалению, большое количество таких уведомлений приводит к approval fatigue – люди жмут на «разрешить» не глядя. На помощь приходят песочницы. Тот же Atlas рекомендует logged out mode – по сути, исполнение агента в режиме инкогнито. У IDE набор средств виртуализации больше – виртуальные файловые системы, изолированные bash-сессии (на базе bubblewrap) и специальные прокси-сервера для недопущения утечек данных, как в Claude Code.

Итого: базой защиты является хорошо заэлайненная модель (соглашусь с Артемом). С такими моделями даже защиты на уровне промпта работают эффективнее благодаря пониманию иерархии инструкций. При этом внешние гардрейлы помогают быстрее адаптироваться к новым угрозам (не дожидаясь нового запуска переобучения), а системные ограничения позволяют сильно затруднить стадию условной LLM-постэксплуатации. Не все эти защиты нужны любому агенту, но они демонстрируют, насколько тяжело сейчас обеспечить хоть сколько-нибудь стоящую защиту для агента общего назначения 🔪