Исследователи показали новую атаку на AI-агентов, которая в тестах проходила даже через защиты, специально созданные против prompt injection, и в отдельных сценариях срабатывала до 50% случаев. Практический смысл неприятный: агент не «сходит с ума» и не бросает задачу, а продолжает делать именно то, что ему поручили, только опирается уже на подмененные факты.
О работе agent data injection, или ADI, сообщает The Hacker News. Авторы — команда из Seoul National University, University of Illinois Urbana-Champaign и Largosoft; препринт появился 6 июля 2026 года. Они описывают класс атак, где злоумышленник не внедряет в данные прямую инструкцию вроде «игнорируй правила», а портит те мелкие поля, которым агент обычно верит без лишних вопросов: имя отправителя, идентификатор элемента на странице, запись о якобы уже выполненном действии.
Не новая команда, а новые «факты»
Это важное отличие от классического prompt injection. Обычный сценарий строится вокруг скрытой команды внутри письма, страницы или комментария. Современные защитные механизмы как раз на такое и натаскивали: искать текст, который выглядит как замаскированное указание модели. ADI работает ниже уровнем. Вместо приказа атакующий подсовывает ложный контекст, и агент сам приходит к опасному действию, потому что его исходные данные уже испорчены.
Техническая основа атаки — то, что исследователи называют probabilistic delimiter injection. Агенту нужно как-то отделять доверенные поля от недоверенного содержимого, и для этого он оборачивает данные в структурные маркеры: кавычки, скобки, теги, переносы строк. Для обычной программы это жесткая грамматика. Для языковой модели — вероятностная догадка. Поэтому символы, похожие на разделители, можно внедрить в контролируемое поле так, что модель воспримет их как реальную структуру. Причем даже неидеальные подделки тоже работают: в тестах хватало экранированной кавычки, фигурной кавычки и даже знака доллара, хотя строгий парсер счел бы это просто текстом, а не новой сущностью.
На практике это выглядело не академическим упражнением, а вполне прикладным набором трюков для популярных инструментов. В веб-агентах — Claude in Chrome, Antigravity от Google и Nanobrowser — подставной отзыв на карточке товара мог переиспользовать идентификатор настоящей кнопки. В результате агент собирался нажать условное «развернуть подробнее», а нажимал кнопку покупки. Авторы отдельно отмечают, что во многих таких интерфейсах элементы нумеруются последовательно, поэтому нужный идентификатор можно подобрать заранее.
Во второй группе сценариев пострадали кодовые помощники: Claude Code, OpenAI Codex и Gemini CLI. Там поддельный комментарий в GitHub-обсуждении имитировал автора-мейнтейнера. Если разработчик просил агента применить исправление от сопровождающего проекта, тот мог выполнить уже чужую команду на локальной машине — при условии, что человек подтвердит действие, выглядящее как рутинный шаг. Еще один вариант связан с pull request: вредоносный PR подделывал запись о проверке, которую агент на самом деле не запускал. В истории действий появлялся «чистый» результат, агент делал вывод, что код безопасен, и продвигался к слиянию изменений.
Почему подтверждения не спасают
На бумаге многие из этих продуктов уже ведут себя осторожно: перед кликом спрашивают разрешение, перед запуском команды тоже. Но исследование бьет ровно по тому месту, где такой UX превращается в иллюзию контроля. Если в окне подтверждения написано лишь то, что агент сейчас нажмет некий элемент, без ясного объяснения какой именно и зачем, пользователю почти не за что зацепиться. Если агент показывает цепочку рассуждений, она тоже выглядит правдоподобно, потому что построена на подложных исходных фактах. Человек видит логичное объяснение нормального шага, а не атаку.
Уязвимыми оказались все модели, которые исследователи проверяли в этих сценариях: OpenAI GPT-5.2 и GPT-5-mini, Anthropic Claude Opus 4.5 и Sonnet 4.5, а также Google Gemini 3 Pro и Flash. На структурированных данных успешность атаки составила от 31% до 43%. На данных веб-страницы разброс оказался еще неприятнее: от примерно трети попыток до полного успеха в отдельных условиях. Против защит, созданных именно для агентных атак, контраст получился особенно показательным. Классический вариант с «контрабандой инструкций» почти обнулился, а атака на AI-агентов через подмену данных все равно доходила до 50% успешных срабатываний. Иными словами, индустрия училась закрывать одну дверь, пока проблема уже заходила через соседнюю.
Полностью без хороших новостей не обошлось. Браузер Atlas у ChatGPT оказался устойчив к сценарию с ложным кликом, потому что использует случайные, непредсказуемые идентификаторы элементов вместо простого счетчика. Та же идея помогала и в общем виде: короткие случайные теги в названиях полей снижали успешность примерно с 49% до 29% без критического ущерба для полезности агента. Самая жесткая защита, где система отслеживает происхождение каждого фрагмента данных, вообще дала ноль успешных атак, но цена оказалась высокой: агенты завершали лишь около трети обычных задач. Очистка подозрительной пунктуации тоже мешала атаке, но вместе с ней ломала обработку нормальных ссылок и путей к файлам. И это уже знакомая история для разработчиков средств безопасности: защита есть, но бизнесу потом с ней жить.
Для рынка важен и еще один вывод. Авторы не сообщают о реальных инцидентах и подчеркивают, что речь идет о proof of concept. Но условия для эксплуатации не выглядят экзотикой. Агент должен читать контент, который может редактировать посторонний, а это повседневный режим для веб-агентов, IDE-помощников, систем поддержки и GitHub-автоматизации. Второе условие — понимать, как конкретный агент упаковывает данные. С open source и локально запускаемыми инструментами это решается чтением кода или реверс-инжинирингом. С облачными сервисами сложнее, но и здесь исследователи утверждают, что смогли вытянуть серверный формат через многошаговый jailbreak у GPT, Claude и Gemini. Более того, по словам одного из авторов, меньшие и большие модели одного вендора часто используют одинаковый формат, поэтому слабое звено можно искать в младшей линейке.
Для русскоязычной IT-аудитории вывод приземленный. Если ваша команда уже встраивает AI-агентов в браузерные сценарии, ревью кода, обработку тикетов или корпоративные помощники, считать подтверждение действия достаточной защитой уже нельзя. Придется смотреть на происхождение данных, схему идентификаторов, изоляцию недоверенного контента и на то, какие именно поля агент воспринимает как «служебную правду». Иначе следующий спор о безопасности ИИ будет не про абстрактное «галлюцинирует или нет», а про очень конкретный вопрос: кто именно подсунул агенту удобную для себя реальность. Подробности исследования и ссылку на артефакты можно посмотреть в материале .