Prompt injection — це не просто грубе прохання користувача. Це ситуація, коли недовірений контент впливає на AI-систему так, ніби він містить вказівку власника застосунку.
Розмір бізнес-ризику визначає не складність атаки, а те, що система після неї може прочитати, змінити, надіслати або підтвердити.
Розрізняйте пряму й непряму ін'єкцію
OWASP розділяє пряму ін'єкцію в запиті користувача та непряму, приховану в зовнішньому матеріалі: сайті, листі чи файлі.
Пряма атака може попросити support-бота забути правила й показати закритий запис. Непряма розміщує ту саму команду в документі, який працівник просить стисло переказати.
Другий випадок легко пропустити: запит працівника законний, а ворожа інструкція надходить через дані, які система має читати.
Оцінюйте повноваження, а не інтелект моделі
Модель, що лише готує текст, створить погану чернетку. Підключення до пошти, CRM, сховища й платежів перетворює той самий збій на зовнішню дію.
Для кожного процесу складіть таблицю повноважень: які дані AI читає, що змінює, максимальний scope, обов'язкове підтвердження й спосіб відкату.
OWASP про надмірну агентність радить прибрати зайві функції, права й автономність. Read-only безпечніший за конектор, який одночасно вміє надсилати та видаляти.
Вважайте зовнішній контент даними, а не владою
Листи, PDF, нотатки CRM, сайти, відповіді інструментів і знайдені знання залишаються недовіреним вмістом навіть усередині знайомої системи.
Позначайте їхні межі, відокремлюйте від інструкцій розробника й указуйте, що всередині можливий ворожий текст. Це посилює захист, але не робить модель security boundary.
Microsoft рекомендує defence in depth: ізоляцію контенту, prompt shields, контроль відхилення плану, аналіз ланцюга інструментів, політики й мінімальні права. Архітектура має локалізувати наслідки навіть у разі пропуску атаки.
Перевіряйте політикою кожен виклик інструмента
Модель може запропонувати дію в типізованій структурі. Код має перевірити назву операції, аргументи, користувача, tenant, власника запису, ліміти, адресу призначення і стан процесу.
Під час інтеграції AI з CRM не дозволяйте моделі будувати довільні запити або обирати tenant. Відкрийте вузькі функції: прочитати один дозволений lead чи підготувати одне оновлення.
Використовуйте короткоживучі credentials і мінімальний scope. Успішна ін'єкція має впертися в жорстку межу прав, а не отримати весь обліковий запис працівника.
Перевіряйте відповідь моделі як ворожий ввід
Відповідь AI може містити зламаний JSON, небезпечний HTML, вигаданий URL, SQL або команду для іншої системи. Не виконуйте й не показуйте її без перевірки для конкретного контексту.
OWASP про неправильну обробку відповідей вимагає ставитися до згенерованого вмісту як до користувацького вводу до передачі далі.
Використовуйте schemas, allowlists, escaping, параметризовані запити й окремі parsers. Відповідь моделі не можна напряму передавати shell, базі, браузеру чи API надсилання повідомлень.
Вимагайте осмислене підтвердження важливих дій
Рецензент має бачити, що станеться, з яким записом або одержувачем, які дані підуть і чому AI запропонував дію. Загальна кнопка після виконання не є контролем.
Надсилання, видалення, зміна прав, повернення коштів, публікація й підписання залишаються поза автономним режимом, доки окрема оцінка ризику не обґрунтує інше.
Такий самий рубіж захищає обробку документів з AI: вилучення автоматичне, а запис у бухгалтерську чи договірну систему проходить перевірку.
Тестуйте процеси, а не набір хитрих фраз
Хороший тест починається з бізнес-мети й очікуваної політики, а потім ворожий контент подається через кожен вхідний канал.
- пряма команда ігнорувати завдання;
- приховані й розділені інструкції в документах;
- команди з бази знань;
- ворожий текст з інструмента або сайта;
- незвична послідовність tool calls;
- спроби отримати секрети, дані іншого клієнта чи зовнішній ефект.
Спостерігайте за рішеннями й обмежуйте наслідки
Логуйте джерело недовіреного контенту, рішення політик, запропоновані tool calls, підтвердження, відмови й підсумкові ефекти. Не складайте секрети й повні документи в загальні логи.
Підготуйте kill switch для кожного конектора, відкликання короткоживучих прав, зупинку черги й мінімальні дані для відтворення помилки.
Ці заходи мають збігатися з архітектурою захисту даних компанії. Ін'єкція стає небезпечною, коли досягає інформації, не потрібної процесу.
Використовуйте детектори як один шар
Класифікатори атак і model guardrails знижують ризик, але пропуски й нові шаблони неминучі. Вони доповнюють права, валідацію й підтвердження, а не замінюють їх.
NIST Generative AI Profile пов'язує ризики з функціями управління, картування, вимірювання та контролю. Для injection потрібен той самий цикл: зрозуміти контекст, випробувати захист, спостерігати зміни й підтримувати план відповіді.
Як я не дозволяю вмісту статті стати інструкцією
В автоматизованому блозі сторінки джерел і HTML статті вважаються вмістом. Фраза всередині сторінки не може змінити дозволений API-метод, додати адресу призначення чи розкрити bearer token.
Код має фіксовану послідовність: завантажити іменоване зображення, створити draft, прочитати його, надіслати повне оновлення й перевірити публічні сторінки. Модель готує дані, але прочитаний контент не перевизначає кроки.
Таке розділення надійніше за прохання до моделі бути обережною. Повноваження містяться в коді та credentials, документи залишаються документами.
Запитання та відповіді
Prompt injection і jailbreak — це одне й те саме?
Поняття перетинаються, але бізнес-загроза ширша. Ін'єкція використовує ввід користувача або зовнішній контент, щоб змінити поведінку застосунку, включно з інструментами й доступом до даних.
Чи допоможе суворіший system prompt?
Він корисний, але не є контролем доступу. Потрібні мінімальні права, перевірки політик, валідація й підтвердження поза моделлю.
Чому небезпечні листи й PDF?
У них може бути текст, який модель сприйме як команду, хоча застосунок мав використати його лише як матеріал для читання.
Чи можна агенту автоматично надсилати повідомлення?
Лише після окремої оцінки ризику, вузьких правил одержувачів і вмісту, валідації, лімітів, моніторингу та випробуваного відкату. Безпечніше починати з чернеток.
Що керівнику запитати до запуску?
Що система читає й змінює, які входи недовірені, де працює жорстка політика, що потребує підтвердження і як швидко вимикається один конектор.