Ваш ИИ-ассистент соблюдает инструкции примерно в 99% случаев, но именно этот недостающий 1% становится мишенью для злоумышленников. С помощью специально подготовленного промпта вредоносный пользователь может заставить модель вызывать функции, которые ей не предназначены, тем самым крадя данные или выполняя привилегированные действия. Решение заключается не в более вежливых формулировках, а в том, чтобы рассматривать эту уязвимость как проблему авторизации и лишать модель доступа к опасным инструментам.

Почему промпт-инъекция — это не просто проблема формулировок

Разработчики часто пытаются усилить защиту агентов с помощью предупреждений заглавными буквами, нумерованных правил или пунктов вроде «не вызывайте функции администратора». Такие меры защиты исходят из предположения, что модель будет подчиняться предложению «не делайте X». На практике же модель можно склонить к игнорированию инструкции, перефразировав запрос, приняв на себя другую роль или просто добавив дополнительный контекст. Лингвистические границы гибки; промпт злоумышленника безграничен и не требует затрат на тестирование.

Настоящая уязвимость кроется в списке инструментов, который получает агент. Если схема промпта содержит функцию, предоставляющую права администратора, у модели появляется «карта» к этой власти. Даже если в промпте сказано «не используй это для клиентов», модель все равно можно убедить вызвать функцию, потому что она существует в ее среде выполнения. Таким образом, проблема заключается в пробеле в авторизации: система предоставляет привилегированные возможности вызывающему лицу, которое не имеет на них права.

Защита агентов путем ограничения области доступа

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

Неправильный способ

Prompt: “You are an assistant. Do not use the adminDeleteUser function for regular customers.”

Модель по-прежнему видит adminDeleteUser в своем наборе инструментов и ее можно обманом заставить вызвать эту функцию.

Правильный способ

Prompt schema for a regular customer: { “functions”: [ “searchCatalog”, “placeOrder” ] }

adminDeleteUser никогда не появляется в списке, поэтому у модели нет пути для ее вызова.

Три практических правила для разработчиков

  1. Формируйте списки инструментов для каждого запроса — генерируйте каталог функций динамически, основываясь на правах аутентифицированного пользователя. Клиент видит только необходимые ему функции; администратор видит полный набор.
  2. Используйте принцип «закрытого отказа» (fail closed) — если личность пользователя не может быть подтверждена, возвращайте пустой список вместо стандартного варианта «доступны все инструменты». Это гарантирует, что неавторизованный запрос никогда не получит неожиданных полномочий.
  3. Избегайте использования общего состояния — при кэшировании определений инструментов никогда не записывайте данные конкретного пользователя в общий объект. Используйте механизм copy-on-write или создавайте копии для каждой сессии, чтобы права одного пользователя не могли «просочиться» в запрос другого.

Если схема, представленная обычному пользователю, выглядит идентично схеме администратора, границей безопасности по-прежнему остается текст промпта, а промпты не являются надежным механизмом защиты.

Как мы к этому пришли

Промпт-инъекции стали актуальной проблемой, когда разработчики начали внедрять большие языковые модели (LLM) в рабочие процессы, требующие вызова внешних API, выполнения кода или изменения баз данных. «Рассуждения» модели направляются промптом, который также включает список доступных инструментов. В первых прототипах предполагалось, что модель будет соблюдать правила на естественном языке, например: «не удаляйте записи, если пользователь не является администратором». Злоумышленники быстро доказали, что несколько дополнительных предложений могут обойти эти правила, заставив модель все равно вызвать функцию удаления.

Первой реакцией сообщества было ужесточение языка промптов, добавление условий «никогда не делайте X» или внедрение regex-фильтров для удаления подозрительных токенов. Эти меры снизили риск случайного использования, но не остановили решительного противника, который мог просто перефразировать запрос. Первопричина — предоставление привилегированных функций недоверенному вызывающему лицу — осталась нерешенной.

Кто выигрывает, а кто проигрывает

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

Разработчики, полагающиеся только на защиту через промпты, продолжают бороться с постоянно меняющейся угрозой. Их агенты могут казаться функциональными при тестировании, но в реальных условиях они могут быть скомпрометированы, что приведет к утечкам данных, несанкционированным транзакциям или нарушениям нормативных требований. Стоимость взлома намного превышает усилия по созданию динамического списка инструментов.

Контраргумент: «Хороших промптов достаточно»

Некоторые утверждают, что при достаточно тщательном промпт-инжиниринге — использовании многослойных промптов, системных сообщений и обучения с подкреплением на основе отзывов людей (RLHF) — модель можно заставить соблюдать запрещающие инструкции («do not» clauses). Реальность же такова, что языковые модели — это вероятностные генераторы; они взвешивают наиболее вероятное продолжение, а не следуют жестким правилам безопасности. Даже при наличии тонко настроенных защитных механизмов (guardrails) новая формулировка может проскочить, особенно если злоумышленник может бесконечно перебирать варианты без каких-либо затрат. Guardrails полезны для снижения уровня шума, но они не должны быть единственной линией обороны.

На что обратить внимание в дальнейшем

  • Фреймворки, представляющие ограничение области применения инструментов (tool scoping) как полноценный API – ожидайте появления новых библиотек, которые позволят объявлять возможности для каждого пользователя и автоматически сокращать список функций перед формированием промпта.
  • Стандартизированные «манифесты функций» – отраслевые группы могут определить JSON-схему, которая разделяет публичные и привилегированные функции, что упростит генерацию манифестов под конкретный запрос.
  • Контроль во время выполнения (Runtime enforcement) – некоторые платформы экспериментируют с выполнением в изолированной среде (sandboxed execution), которая проверяет токен вызывающей стороны на соответствие вызываемой функции, добавляя второй уровень защиты помимо ограничения области промпта.

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