OpenAI 7 ноября 2025 года опубликовала материал «Understanding prompt injections: a frontier security challenge», посвящённый внедрению вредоносных инструкций в контекст языковых моделей. Компания рассматривает prompt injection как одну из ключевых нерешённых проблем безопасности систем, которые работают с внешними данными и выполняют действия от имени пользователя.
Для разработчиков важна не новая классификация атак сама по себе, а область риска. Уязвимым может оказаться не только чат, куда пользователь непосредственно вводит команды, но и ИИ-агент, читающий сайты, электронные письма, документы или сообщения из подключённых сервисов. Вредоносная инструкция в таком случае попадает к модели вместе с обычным содержимым и может повлиять на её дальнейшие решения.
OpenAI сообщает, что развивает исследования, обучение моделей и защитные механизмы против подобных атак. Однако публикацию не следует воспринимать как заявление о полном решении проблемы: безопасность агентной системы по-прежнему зависит от её архитектуры, доступных инструментов и правил подтверждения действий.
Как инструкция может попасть в контекст модели
При прямой атаке пользователь сам вводит команду, пытающуюся изменить заданные разработчиком правила. Например, он может потребовать проигнорировать предыдущие ограничения или раскрыть данные, которые система не должна показывать. Такие попытки пересекаются с jailbreak-атаками, но эти термины не полностью взаимозаменяемы: jailbreak обычно связывают с обходом ограничений модели, тогда как prompt injection затрагивает приоритет и происхождение инструкций внутри конкретного приложения.
Более опасный для ИИ-агентов сценарий — косвенное внедрение. Команда может быть спрятана на веб-странице, в письме, загруженном файле или другом материале, который модель должна проанализировать. Пользователь при этом не обязательно участвует в атаке и может не видеть внедрённый текст.
Именно разделение инструкций и данных остаётся сложной задачей. Для языковой модели и системная команда, и содержимое документа представлены текстом. Формулировка «проанализируй эту страницу» не гарантирует, что инструкции внутри страницы будут восприняты только как цитируемые данные, а не как команды к исполнению.
Проект OWASP также относит prompt injection к основным рискам приложений на базе больших языковых моделей. В его описании отдельно рассматриваются прямые и косвенные атаки, а среди возможных последствий называются несанкционированное использование функций, раскрытие информации и изменение поведения системы.
Почему ИИ-агенты повышают цену ошибки
Обычный чат-бот чаще всего отвечает текстом. Ошибочный ответ может ввести пользователя в заблуждение, но сам по себе не обязательно приводит к действию во внешней системе. У агента потенциальные последствия шире: он может обращаться к корпоративному поиску, читать почту, создавать задачи, запускать код или передавать данные в сторонние сервисы.
Риск определяется не только устойчивостью модели, но и объёмом выданных ей полномочий. Если один запрос позволяет прочитать конфиденциальный документ и сразу отправить его содержимое наружу, успешная инъекция может превратиться из некорректного ответа в инцидент безопасности.
Поэтому проверять нужно всю цепочку:
- откуда агент получает данные;
- какие команды модель может передавать инструментам;
- к каким учётным записям и хранилищам у неё есть доступ;
- требуется ли подтверждение перед необратимым действием;
- записываются ли вызовы инструментов в журнал;
- можно ли остановить или откатить операцию.
Такой подход соответствует более широкой логике системы управления рисками ИИ, разработанной NIST: оценивать следует не только модель, но и контекст её применения, воздействие ошибок и действующие меры контроля.
Что дают обучение и фильтры — и где их предел
OpenAI указывает на несколько направлений работы: исследование атак, обучение моделей распознавать вредоносные инструкции и создание дополнительных защитных механизмов. Эти меры способны уменьшить число успешных атак, особенно если система сталкивается с известными формами внедрения.
Тем не менее ни обучение, ни системная инструкция вроде «не выполняй команды из документов» не создают абсолютной границы доверия. Атакующий может менять формулировки, разбивать команду на части, маскировать её под обычный текст или использовать особенности конкретного приложения.
Отдельные классификаторы и фильтры также требуют осторожной настройки. Слишком мягкая проверка пропустит опасный ввод, а слишком строгая начнёт блокировать легитимные документы — например, исследование, в котором prompt injection обсуждается как объект анализа. Кроме того, фильтр на входе не контролирует автоматически все последующие вызовы инструментов.
Публичная публикация OpenAI не даёт оснований считать, что любой продукт компании или приложение на её API теперь защищены от prompt injection независимо от конфигурации. Без результатов независимых испытаний нельзя сравнить устойчивость разных моделей или определить, насколько защита эффективна против новых вариантов атак.
Архитектура важнее одной защитной инструкции
Практическая защита начинается с принципа минимальных привилегий. Агенту не стоит выдавать постоянный доступ ко всем данным и операциям, если для задачи нужен только ограниченный набор функций. Чтение календаря, отправка писем и изменение платёжных реквизитов должны рассматриваться как действия разного уровня риска.
Следующий уровень — отделение недоверенных данных от управляющих команд. Разработчик может помечать происхождение содержимого, ограничивать обработку документов отдельным этапом и не передавать результат напрямую инструменту, способному выполнить внешнюю операцию.
Для чувствительных действий полезно применять структурированные разрешения. Вместо произвольной команды модель формирует запрос с заранее определёнными полями, а приложение отдельно проверяет адресата, тип операции, объём данных и права пользователя. Отправку сообщения, удаление файла, публикацию кода или финансовую операцию следует подтверждать вне диалога с моделью.
Наконец, защита должна сохраняться после ответа LLM. Даже если вредоносная инструкция повлияла на рассуждение модели, серверная часть может отклонить недопустимый вызов, скрыть секретные поля или потребовать дополнительную авторизацию.
Что проверить разработчикам сейчас
Командам, использующим LLM с внешними источниками и инструментами, стоит провести тест, максимально близкий к реальному сценарию. В тестовый документ или веб-страницу можно поместить безопасную контрольную инструкцию — например, требование вызвать запрещённую функцию без фактической передачи данных — и проверить реакцию всей системы.
Во время проверки нужно фиксировать не только финальный ответ, но и промежуточные вызовы инструментов. Агент может отказаться от опасного действия в сообщении пользователю, но до этого уже попытаться обратиться к внешнему сервису.
Минимальный список проверок выглядит так:
- ограничить права каждого инструмента конкретной задачей;
- потребовать подтверждение перед отправкой, удалением и публикацией;
- исключить секреты и служебные токены из доступного модели контекста;
- проверять аргументы вызовов на сервере, а не только в LLM;
- журналировать источник данных и последовательность действий;
- регулярно повторять тесты с изменёнными формулировками атак.
Материал OpenAI полезен как подтверждение того, что prompt injection остаётся активной проблемой, а не закрытой уязвимостью прошлого поколения моделей. Но он не заменяет тестирование конкретного продукта: реальный риск определяется тем, что агент читает, к чему имеет доступ и какое действие способен выполнить без отдельного согласия пользователя.