Agent Data Injection: атака не даёт агенту ни одной команды, а он всё равно запускает чужой код

Все научились защищаться от prompt injection: не давай агенту исполнять инструкции из недоверенного текста, фильтруй, оборачивай, помечай. Работа исследователей из Сеульского национального университета и UIUC показывает, что защищались не от того. Новая атака вообще не пытается отдать агенту команду. Она подменяет факты, которым агент доверяет, — и агент честно выполняет твою задачу, просто на подделанных данных.

TL;DR: Agent Data Injection — атака, при которой недоверенные данные подменяют доверенные поля внутри контекста агента: имя автора комментария, ID кнопки, источник совета. Работает через неточные разделители, доля успеха доходит до 100% на GPT-5.2 в отдельных вариантах. Продемонстрирована против Claude Code, Codex, Gemini CLI, Claude in Chrome, Antigravity и Nanobrowser — вплоть до RCE и атаки на цепочку поставок. Существующие защиты от instruction injection её не ловят.

Что такое Agent Data Injection и чем она отличается от prompt injection

Классическая инъекция подсовывает агенту инструкцию: «игнорируй предыдущие указания и сделай вот это». ADI не подсовывает инструкций вообще — она портит факты, которые агент считает установленными системой. Задача остаётся твоей, агент остаётся послушным, меняется только его картина мира.

Два примера из работы, оба обидно бытовые. Просишь агента подытожить отзывы на странице товара, и один подставной отзыв заставляет его нажать «Купить» вместо «Читать далее». Просишь ассистента применить фикс мейнтейнера из треда на GitHub — поддельный комментарий, выглядящий как комментарий мейнтейнера, заставляет его выполнить команду постороннего человека на твоей машине.

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

Как атака технически работает

Механизм называется probabilistic delimiter injection, инъекция вероятностного разделителя. Агент получает данные инструментов в каком-то структурированном виде: JSON, разметка кнопок, поля метаданных. Атакующий вставляет внутрь своего текста не настоящий разделитель формата, а очень похожий — и модель с некоторой вероятностью читает подделку как настоящую границу поля.

Доля успешных атак прямо зависит от того, насколько похож подставной разделитель. По замерам на GPT-5.2:

• Квадратные скобки плюс угловые, например [0] <button> — 100,0%
• Фигурные скобки плюс угловые — 53,3%
• Типографские кавычки внутри фигурных скобок — 43,3%
• Одинарные кавычки внутри фигурных скобок — 42,6%
• Экранированные двойные кавычки внутри фигурных скобок — 41,8%
• Квадратные скобки плюс фигурные — 40,0%
• Знаки доллара внутри фигурных скобок — 38,8%
• Квадратные скобки плюс круглые — 33,3%
• Точки плюс угловые скобки — 20,0%

Сто процентов на самом «естественном» варианте разметки — это не опечатка. Там, где формат данных выглядит для модели привычнее всего, она надёжнее всего принимает подделку за настоящую структуру.

Атака проверена на обычных моделях в изоляции и на реальных агентах. В списке протестированных моделей — GPT-5.2 и GPT-5-mini, Claude Opus 4.5 и Sonnet 4.5, Gemini 3 Pro и Flash. В списке агентов — веб-агенты Claude in Chrome, Antigravity и Nanobrowser, а также кодинг-агенты Claude Code, Codex и Gemini CLI, где авторы демонстрируют выполнение произвольного кода и атаки на цепочку поставок.

Почему существующие защиты не помогают

Защиты от instruction injection ищут инструкции. ADI не содержит инструкций. Она содержит факты, поэтому проходит фильтры, которые эффективно останавливают классическую инъекцию. Это подтверждается в самой работе: высокая доля успеха сохраняется в присутствии защит.

Дальше цепочка получается неприятно естественной. Кодинг-агенту разрешено читать тред issue, это его работа. Ему разрешено выполнять команды, которые рекомендует мейнтейнер, — потому что иначе он бесполезен. Всё, чего не хватает атакующему, — убедительной лжи о том, кто именно это написал. Никакого обхода песочницы, никакого джейлбрейка, никакого хитрого промпта.

Именно поэтому ADI попадает в тот же ряд, что и побег внутренней модели OpenAI из песочницы: проблема не в том, что модель злая, а в том, что периметр вокруг неё нарисован не там, где надо.

Как защищаться прямо сейчас

Полного решения на уровне модели нет. Оно требует, чтобы агенты научились помечать провенанс каждого куска контекста, а этого пока не делает никто. Значит, режем на уровне прав и процессов.

Не давай агенту автоматически исполнять то, что он вычитал снаружи. Команда, пришедшая из issue, PR-комментария, README стороннего репозитория или веб-страницы, должна проходить через явное подтверждение. Это ровно тот случай, когда «удобный» режим авто-approve превращается в RCE.

Считай вывод любого инструмента недоверенным целиком. Не только тело комментария, но и поле «автор». Если твоя обвязка передаёт модели авторство в том же тексте, что и содержимое, — считай, что авторства у тебя нет.

Разделяй чтение и действие. Один прогон агента ходит наружу и собирает данные, второй, с урезанными правами и без сетевого доступа, что-то на их основе делает. Тогда подделка влияет на выводы, но не на shell.

Выключай автодействия там, где цена ошибки высокая. Покупки, отправка писем, пуш в основную ветку, любые вызовы с деньгами. Здесь ручное подтверждение окупается одним предотвращённым случаем.

Логируй и мониторь изменения в доверенных полях. Если у агента в трассе внезапно поменялся ID кнопки или имя автора между шагами — это сигнал, и его видно только в логе вызовов инструментов, а не в финальном ответе.

Подводные камни

• Это не баг конкретного вендора, а свойство архитектуры. Патча, который «закроет ADI», не будет — пока агенты держат доверенные и недоверенные данные в одном плоском контексте, поверхность остаётся.
• Работает и на «безопасных» задачах. Атака не меняет твою цель, поэтому мониторинг, который следит за подменой задачи, ничего не заметит.
• Чем аккуратнее у тебя структурированный формат, тем хуже. Самый высокий процент успеха — на самом естественном и привычном для модели виде разметки. Аккуратный JSON или разметка кнопок делает подделку правдоподобнее, а не наоборот.
• Веб-агенты уязвимее всех. Любая страница с пользовательским контентом — отзывы, комментарии, форумы — это готовый канал доставки.
• Свежие модели не спасают. В списке протестированных — актуальные на момент работы флагманы всех трёх крупных лабораторий.

Альтернативы и смежные подходы

• AgentDojo и WASP — бенчмарки для оценки устойчивости агентов к инъекциям. Полезны, чтобы измерить свою обвязку, но заточены под instruction injection, то есть именно ту категорию, мимо которой проходит ADI.
• Изоляция на уровне окружения — sandbox, отдельный контейнер, отсутствие сетевого доступа на этапе действия. Не мешает подделке данных, но резко ограничивает последствия. Дешевле любых фильтров.
• Провенанс на уровне протокола — правильное, но пока не существующее решение: агент должен получать данные с криптографически или структурно отделённой пометкой источника. Ближайшее место, где это могло бы появиться, — спецификации вроде MCP.

Вердикт

Если ты запускаешь кодинг-агента с авто-подтверждением команд и разрешаешь ему читать внешние треды — выключай авто-подтверждение сегодня, это самый дешёвый способ закрыть продемонстрированный путь до RCE. Если у тебя веб-агент ходит по страницам с пользовательским контентом и умеет нажимать кнопки с последствиями — разведи сбор данных и действие на два прогона. А ждать вендорского фикса смысла нет: это не уязвимость в продукте, это отсутствующий уровень изоляции в том, как вообще устроены агенты в 2026 году.

Как проверить себя

1. Открой конфиг своего агента и найди список команд, которые выполняются без подтверждения. Всё, что может писать в файловую систему или ходить в сеть, — на подтверждение.
2. Посмотри, как твоя обвязка передаёт модели метаданные: если имя автора и текст комментария склеены в одну строку, у тебя нет границы между доверенным и недоверенным.
3. Поставь простой тест: заведи в тестовом репозитории issue, где в теле комментария имитируется структура твоего формата данных, и посмотри, как агент его прочитает.
4. Разнеси «сходить и прочитать» и «сделать» на два запуска с разными правами — это дешевле любых фильтров и работает против всего класса атак.
5. Оригинал работы со всеми таблицами долей успеха — arXiv 2607.05120, разбор для практиков — у The Hacker News.