Ваш ШІ-асистент виконує свої інструкції приблизно у 99% випадків, але саме ці відсутні 1% є місцем, куди б'ють зловмисники. Подаючи спеціально сформульований промпт, шкідливий користувач може змусити модель викликати функції, які вона не повинна викликати, викрадаючи дані або виконуючи привілейовані дії. Виправлення полягає не в більш ввічливих формулюваннях — а в тому, щоб розглядати цю ваду як проблему авторизації та позбавляти модель доступу до небезпечних інструментів.

Чому ін'єкція промптів — це не просто проблема формулювань

Розробники часто намагаються посилити захист агентів за допомогою попереджень великими літерами, нумерованих правил або пунктів «не викликати admin functions». Ці методи захисту припускають, що модель буде слухатися речення, яке каже «не роби 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) — модель можна змусити дотримуватися застережень «не робити». Реальність полягає в тому, що мовні моделі є ймовірнісними генераторами; вони зважують найбільш імовірне продовження, а не жорстке правило безпеки. Навіть із тонко налаштованими захисними механізмами (guardrails) нове формулювання може проскочити, особливо коли зловмисник може проводити нескінченні ітерації без жодних витрат. Захисні механізми корисні для зменшення шуму, але вони не повинні бути єдиним рубежем оборони.

На що звернути увагу далі

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

Висновок очевидний: ставтеся до ін'єкції промптів як до помилки авторизації. Видаляючи несанкціоновані інструменти з набору інструментів моделі, ви усуваєте поверхню атаки, яку намагається використати хитро сформульований промпт. Промпти можуть спрямовувати поведінку, але вони не можуть замінити належний контроль доступу.