Prompt Injection: невирішена вразливість в основі кожного LLM-застосунку
Кожен інженер знає SQL injection: недовірені вхідні дані інтерпретуються як команда. Ми вирішили цю проблему десятиліття тому за допомогою параметризованих запитів — жорсткої межі між кодом і даними. Prompt injection — та сама ідея, застосована до LLM, з однією жорстокою відмінністю: для природної мови не існує параметризованого запиту. Для моделі все є токенами. Системний промпт, запитання користувача та вміст PDF-файлу, який попросили підсумувати, надходять одним і тим самим каналом — і модель не має надійного способу визначити, які частини є інструкціями, а які — даними. Це не баг конкретної моделі. Це структурна властивість архітектури, і саме тому OpenAI, Anthropic та кожен постачальник рішень з безпеки досі класифікують prompt injection як невирішену проблему на межі можливого.
Пряма проти непрямої ін'єкції
Пряма ін'єкція — це класичний трюк «ігноруй попередні інструкції», введений прямо в чатбот. Дратівливо, але обмежено — зловмисник здебільшого компрометує лише власну сесію. Непряма ін'єкція — саме там, де криється справжній ризик. Шкідливі інструкції надходять через вміст, який модель обробляє від чийогось імені: вебсторінку, яку переглядає агент, документ у вашому RAG-пайплайні, електронний лист, GitHub issue, запрошення в календарі. Жертва ніколи не вводить нічого шкідливого сама — вона просто просить свого асистента «підсумувати цей тікет», а тікет містить приховані інструкції, яким модель слухняно слідує. Між 2024 і 2026 роками це перейшло від дослідницьких демонстрацій до продакшн-інцидентів: задокументовані атаки на Slack AI, Microsoft 365 Copilot, Cursor та MCP-інтеграції GitHub мали однаковий патерн. До 2026 року звіти OWASP про експлойти показують організований інструментарій — десятки окремих родин пейлоадів і технік доставки в активному використанні — а не поодинокі експерименти.
Смертельна трійця
Саймон Вілісон запропонував найчистіший спосіб міркувати про цей ризик. Система ШІ стає небезпечно вразливою, коли поєднує три речі:
- Доступ до приватних даних — ваших документів, бази даних, кодової бази, поштової скриньки
- Вплив недовіреного контенту — усього, на що може вплинути зловмисник: вебсторінок, листів, тікетів, README пакетів
- Можливість комунікувати назовні — надсилати запити, листи, коміти чи виклики інструментів, що виходять за межі периметра
Будь-які дві з них можна пережити. Усі три разом означають, що зловмисник, який контролює хоча б один фрагмент контенту, який читає ваш агент, потенційно може ексфільтрувати все, що бачить агент. Майже кожен великий інцидент останніх двох років вписується саме в цю комбінацію. Це також причина, чому епоха агентних систем погіршила ситуацію. Чатбот 2023 року, що піддається ін'єкції, скаже щось незручне. Агент 2026 року з доступом до бази даних, оболонкою та поштовим інструментом робить щось незворотне. Ставки перемістилися зі слів на дії — саме тому у травні 2026 року агенції Five Eyes (CISA, NSA та їхні аналоги з Великої Британії, Канади, Австралії та Нової Зеландії) випустили спільні рекомендації щодо агентного ШІ, назвавши prompt injection ключовим вектором маніпуляції та прямо заявивши, що жодного окремого запобіжника недостатньо.
Чому це не можна просто відфільтрувати
Інстинктивне рішення — «виявляти й блокувати шкідливі промпти» — не витримує критики. Ін'єкції можна перефразовувати нескінченно, кодувати, розбивати між документами, приховувати в білому тексті на білому тлі чи в метаданих зображень. Навіть найсильніші опубліковані підходи до виявлення пропускають суттєву частку атак на основі оптимізації, а зловмиснику потрібен лише один успіх. Моделі-guardrail допомагають як шар захисту; вони не спрацьовують як фундамент. Чесна інженерна позиція: вважайте, що ін'єкція вдасться, і проєктуйте так, щоб успішна ін'єкція не могла завдати серйозної шкоди.
Ешелонований захист, який дійсно працює
- Розбийте трійцю. Найефективніший окремий крок. Якщо агент читає недовірений контент, обріжте йому вихід назовні або доступ до секретів. Проєктуйте кожного агента так, щоб він мав щонайбільше дві з трьох властивостей.
- Інструменти з мінімальними привілеями. Обмежте кожен інструмент найвужчим можливим набором дій. Де можливо — лише читання. Жодних продакшн-облікових даних у зоні досяжності агента.
- Ставтеся до виводу моделі як до недовірених вхідних даних. Ніколи не передавайте його напряму в оболонку, SQL чи виклик API без валідації — інакше ін'єкція перетворює модель на проксі зловмисника.
- Людське підтвердження для незворотних дій. Платежі, видалення, листи на зовнішні адреси, продакшн-деплої.
- Пісочниця та ізоляція. Виконання коду в контейнерах з обмеженим виходом назовні; ізоляція на рівні сесії, щоб один заражений документ не контамінував інших користувачів.
- Логуйте все. Повна телеметрія промптів і викликів інструментів у вашому SIEM. Спроби ін'єкції — це сигнал атаки, на який варто налаштувати сповіщення, а не виявляти через тижні.
Якщо ви запускаєте моделі на власній інфраструктурі, ці заходи накладаються на базове зміцнення, яке ми розглянули в статті Безпека самостійно розміщених LLM — ін'єкція є загрозою на рівні поведінки, яка залишається навіть тоді, коли ваша мережа та ланцюг постачання чисті.
Висновок
Prompt injection — це не вразливість, яку патчать; це властивість, навколо якої проєктують архітектуру. Команди, які роблять це правильно у 2026 році, — не ті, у кого найрозумніший фільтр, а ті, хто заздалегідь припустив компрометацію та зменшив радіус ураження: мінімальні привілеї, розбиті трійці, перевірені виводи та людина в контурі там, де це справді важливо. У NextVector ми застосовуємо до систем ШІ той самий підхід «безпека понад усе», який ми привносимо в платіжну та блокчейн-інфраструктуру. Створюєте LLM-функцію, яка торкається реальних даних? Зв'яжіться з нами.