Що таке prompt injection і як приховані інструкції впливають на AI

AI-асистент може читати конспект, відповідь студента або знайдену сторінку, щоб допомогти з навчанням. Усередині такого матеріалу може бути текст, який намагається змінити його поведінку: підмінити критерій, розкрити зайві відомості або виконати сторонню дію. Людина сприймає файл як об'єкт аналізу, але модель може помилково поставитися до його частини як до інструкції. Цей клас ризиків називають prompt injection. Для освітнього сервісу важливо захищати не тільки відповідь у чаті, а й дані та інструменти, до яких помічник має доступ.

Корисне запитання для команди: що реально станеться, якщо модель виконає небажану вказівку з навчального ресурсу? Відповідь залежить від архітектури. Помилка пояснення й несанкціонована зміна запису мають різні наслідки. Нижче запропоновано процес захисту для онлайн-школи разом із технічними фахівцями. Він не гарантує повного усунення prompt injection й не описує виявлену вразливість конкретної LMS. Приклади є умовними та призначені для перевірки власних погоджених середовищ із тестовими матеріалами, без використання чужих даних або сторонніх систем.

Відрізняйте навчальну команду в тексті від доручення користувача

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

Для навчального помічника завантажена робота студента має залишатися роботою, а не каналом зміни правил оцінювання. Сторінка довідки може містити предметні умови, але не повинна надавати нові технічні права. Коментар у спільному документі не стає підтвердженням адміністратора тільки через відповідний напис. Попросіть технічну команду показати, як ці межі представлені в системі. Одного людського пояснення в методичному документі недостатньо, якщо фактичний процес обробки змішує всі фрагменти в один нерозрізнений текст і дозволяє моделі самій визначати їхні повноваження.

Не обмежуйте перевірку видимим текстом сторінки. До обробки можуть потрапляти результати розпізнавання зображення, вкладення, метадані або вміст знайденого фрагмента. Визначте, які шари конкретно читає ваш сервіс. Не потрібно припускати, що кожний формат однаково небезпечний або що кожний ресурс уже містить спробу впливу. Потрібно мати реальну карту входів. Якщо команда не знає, який текст потрапив у запит після перетворення файла, їй буде складно пояснити небажану відповідь і перевірити ефективність власних обмежень.

Визначте допустимі можливості помічника

Спочатку перелічіть потрібні дії. Помічник може відповідати на питання за погодженими матеріалами, готувати чернетку коментаря або шукати конкретний ресурс. Не додавайте редагування оцінок, розсилання повідомлень чи зміну доступів лише тому, що інтеграція технічно це дозволяє. OWASP про Excessive Agency пов'язує наслідки з надмірними функціями, правами й автономією. Для школи практичне рішення починається з мінімального набору можливостей, які справді потрібні визначеному навчальному сценарію, а не з максимального доступу за замовчуванням.

Розділіть отримання інформації та її зміну. Якщо задача полягає в поясненні умов курсу, помічнику не обов'язково мати можливість редагувати самі умови. Якщо він готує відповідь для працівника підтримки, це не означає автоматичного надсилання студенту. Чітко визначте, де закінчується пропозиція моделі й починається виконання. Для кожної дії назвіть допустимий об'єкт, користувача та умови. Широка команда «керувати навчанням» приховує занадто багато різних можливостей, які потребують окремого рішення про придатність і контроль.

Перевірте фактичні права підключеного облікового запису. Назва інструмента може звучати вузько, а його службовий доступ охоплювати більше даних. Для тесту використайте різні ролі й перевірте, що недоступний ресурс не повертається навіть за наполегливого запиту. Авторизація має визначатися належною системою доступу, а не рішенням моделі про те, що користувач нібито має добрі наміри. Не передавайте секрети в текст інструкції як спосіб «пояснити» асистенту межі. Межі повинні працювати в самому виконанні дії та перевірці запиту.

Обмежуйте дані до передавання моделі

Для відповіді на навчальне питання передавайте лише потрібні матеріали. Якщо користувач не має доступу до чужої роботи, ця робота не повинна випадково потрапити в пошуковий контекст, із якого модель нібито обіцяє нічого не розкривати. OWASP Sensitive Information Disclosure описує ризики витоку чутливої інформації. Для вашого процесу перевірте відбір даних за реальною роллю та задачею. Приховування фрагмента в інтерфейсі не допоможе, якщо він уже переданий компоненту, що формує відкриту відповідь іншому користувачеві.

Не змішуйте відкриті пояснення курсу й приватні відомості в одному широкому індексі без належного розмежування. Пошук має враховувати дозволений обсяг ще до формування відповіді. Для кожної категорії даних визначте, хто може її отримати й у яких ситуаціях. Це технічна й організаційна задача, а не лише редактура промпту. Якщо помічник не потребує особистих результатів студентів для пояснення терміна, не додавайте їх у контекст «про всяк випадок». Менший обсяг також полегшує перевірку підстави й розбір помилки.

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

Поєднайте інструкції для моделі з технічними обмеженнями

Ясно опишіть роль асистента й позначайте сторонній матеріал як дані для аналізу. Це корисний рівень захисту, але його не слід представляти як непорушну межу. OWASP Prompt Injection Prevention Cheat Sheet пропонує багатошаровий підхід. У конкретному освітньому сервісі потрібно перевіряти не тільки формулювання заборони, а й те, що зробить прикладний код після отримання небажаного запиту від моделі. Якщо він виконає будь-яку запропоновану дію без незалежної перевірки, текстова обіцянка ігнорувати приховані вказівки залишиться недостатньою.

Визначте допустиму структуру запитів до інструментів. Для дії мають бути перевірені параметри, користувацький контекст і належний об'єкт. Не перетворюйте довільний текст моделі на команду до системи. Якщо потрібна зміна навчального запису, прикладний процес перевіряє право й умови, а для визначених значних наслідків передбачає належне підтвердження відповідальної людини. Вона має бачити конкретну дію та її обсяг. Загальна згода «допомагати з курсом» не повинна приховувати зміну, яку користувач не доручав у цьому епізоді.

Перевіряйте й спосіб відображення відповіді. Автоматично створене посилання, зображення або інший активний елемент може мати наслідки поза простим читанням тексту. Технічна команда має визначити, які формати дозволені та як вони обробляються. Не приймайте весь вміст як довірений HTML лише тому, що його створила ваша модель. Для навчального помічника часто достатньо обмеженого зрозумілого формату з перевіреними переходами до дозволених ресурсів. Вибір має відповідати реальній задачі, а не всім можливостям довільного багатого виводу генеративної системи.

Підготуйте умовний тест із навчальним документом

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

Перевірте кілька рівнів результату. Чи змінився зміст відповіді? Чи модель попросила викликати сторонній інструмент? Чи виконала система цей виклик? Останні два питання особливо важливі: небажана пропозиція моделі й фактична несанкціонована дія мають різний статус. Збережіть достатні відомості для розбору без зайвого відкритого поширення тестових деталей. Не зараховуйте сценарій як пройдений лише тому, що фінальне речення звучить правильно, якщо перед ним уже відбулася дія, якої в навчальному дорученні не було.

Після виправлення повторіть тест і перевірте нормальну роботу. Захист, який блокує будь-яке цитування наказового речення, може завадити звичайному мовному або технічному уроку. Для кожного небажаного випадку підготуйте також доречний навчальний контекст. Мета — зберегти межу між аналізом матеріалу й виконанням його вказівок, а не заборонити всі тексти зі словом «зробіть». Перевірку конкретної конфігурації мають виконувати належні фахівці; невеликий редакційний приклад лише допомагає сформулювати очікувану поведінку й наслідки для навчального процесу.

Не вважайте RAG завершеним захистом

Пошук за погодженою базою може поліпшувати підставу відповіді, але знайдений фрагмент також залишається вхідними даними. У наведеному матеріалі OWASP про prompt injection зазначено, що RAG і додаткове навчання не усувають цей ризик повністю. Для школи важливо перевіряти, хто може змінювати базу, як матеріал потрапляє до неї та який статус отримує після пошуку. Наявність посилання на джерело не доводить, що всі його рядки є дозволеними командами для помічника або погодженою політикою навчальної організації.

Розділіть офіційні правила й користувацькі матеріали. Обидва типи можуть бути потрібні для навчальної задачі, але мають різне призначення. Робота студента не повинна непомітно ставати частиною офіційної довідки для всієї групи. Після додавання або оновлення джерела перевірте його вплив на пошук і відповіді. Якщо процес автоматично приймає будь-який новий файл у загальну базу, визначте, чи це справді відповідає задуму. Зручність поповнення архіву не має замінювати рішення про походження, права та належне використання конкретного матеріалу.

Для важливого помічника зберігайте версію матеріалів і конфігурації, потрібну для розбору. Якщо відповідь змінилася після оновлення моделі або бази, команда має можливість зіставити умови. Не потрібно зберігати без обмежень усі приватні запити. Потрібен погоджений журнал із достатнім обсягом і захистом. NIST Generative AI Profile допомагає розглядати оцінювання й керування ризиками в життєвому циклі системи. Одноразова успішна демонстрація не замінює перегляду після змін, які впливають на фактичні входи й можливості навчального сервісу.

Погодьте відповідь на виявлений інцидент

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

Якщо LMS платформа WeStudy використовується для навчання разом із зовнішнім AI-асистентом, окремо перевірте межі фактичного підключення. Не припускайте наявності або захищеності певної інтеграції за загальним описом сценарію. Визначте, які матеріали передаються, які інструменти доступні та хто відповідає за них. Для студента має бути зрозуміло, що може робити помічник і куди звернутися після суперечливої відповіді. Технічний захист не повинен спиратися на очікування, що кожний учасник сам розпізнає приховані інструкції в усіх форматах навчальних ресурсів.

Коли LMS платформа WeStudy є місцем зберігання погоджених матеріалів курсу, зберігайте ясну різницю між джерелом навчального змісту та правами зовнішнього автоматичного помічника. Перевіряйте конкретну конфігурацію після суттєвих змін і підтримуйте шлях повернення до належної людської допомоги. Практичний захист складається з обмежених даних, потрібних можливостей, незалежної авторизації та перевірюваних дій. Текстова інструкція моделі залишається корисною частиною цього процесу, але без технічних меж не може сама гарантувати, що сторонній документ ніколи не вплине на поведінку системи.

Перевірте сценарій оцінювання без реальних студентських даних

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

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

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

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

Окремо перевірте, що робить викладач із хибною чернеткою. Якщо інтерфейс показує лише готовий гладкий коментар без рубрики й джерельної роботи, людині важче помітити підміну. Дайте відповідальному достатньо контексту для перевірки. Не змушуйте підтверджувати довгий пакет різних змін одним неясним елементом керування. Для конкретної дії мають бути зрозумілі об'єкт і наслідок. Так людський перегляд залишається змістовою частиною процесу, а не формальною кнопкою після рішення, яке фактично ніхто не може оцінити за доступними відомостями.

Перевірте доступ між різними навчальними групами

Створіть у належному тестовому середовищі дві вигадані групи з різними матеріалами. Для кожної ролі визначте дозволений обсяг. Запитайте асистента про ресурс, доступний тільки іншій групі. Очікуваний результат має забезпечуватися перевіркою доступу до даних, а не тільки ввічливою відмовою в кінцевому реченні. Попросіть технічну команду встановити, чи недоступний фрагмент взагалі потрапив у контекст. Якщо він уже переданий моделі, відсутність явного цитування в одній відповіді не доводить належної ізоляції даних у всіх наступних ситуаціях.

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

Перевірте відкликання доступу на вигаданому ресурсі. Якщо матеріал більше не дозволений ролі, визначте, як це враховують пошук, похідні підсумки та подальші відповіді. Стара копія може залишатися в іншому компоненті. Не обіцяйте миттєвого очищення всіх станів без перевіреного механізму. Натомість зафіксуйте, що система робить фактично та які обмеження потрібно усунути до відповідного сценарію запуску. Керування доступом має охоплювати життєвий цикл ресурсу, а не лише його первинне додавання до навчальної бази помічника.

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

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

Джерела

1. OWASP — LLM01:2025 Prompt Injection.

2. OWASP — LLM06:2025 Excessive Agency.

3. OWASP — LLM02:2025 Sensitive Information Disclosure.

4. OWASP Cheat Sheet Series — LLM Prompt Injection Prevention.

5. NIST AI 600-1 — Generative Artificial Intelligence Profile.