Коротка відповідь: AI-агент — не чатбот, а програма, яка виконує дії замість вас: читає пошту, створює рахунки, зберігає файли, відповідає клієнтам. Prompt injection — це ситуація, коли в даних, які обробляє агент (вхідному електронному листі, PDF-файлі, вебсторінці), приховано текст, сформульований як команда. Без належного захисту агент може її виконати, оскільки інструкції та дані надходять до нього одним каналом. OWASP ставить prompt injection на перше місце у своєму рейтингу ризиків для застосунків на основі мовних моделей, а органи кібербезпеки додають, що повністю усунути цю властивість неможливо. Тому захист ґрунтується не на тому, щоб «переконати» агента, а на чотирьох заходах поза моделлю: мінімальних правах доступу (агент не бачить більше, ніж людина, яку він представляє), підтвердженні людиною чутливих дій, журналі аудиту (хто, що, коли й за чиєю командою) та обмеженнях із можливістю негайно вимкнути агента.
Для AI-асистента, який лише відповідає у вікні чату, найбільший ризик становить те, що люди до нього копіюють. Але щойно та сама модель отримує доступ до пошти, бухгалтерської системи або спільного диска й може виконувати в них дії, характер проблеми змінюється: ідеться вже не лише про конфіденційність введених даних, а про те, що саме агент здатен зробити за чужою командою. Цей текст присвячений другій ситуації. Використання корпоративних даних у чатботах розглянуто в статті корпоративні дані в ChatGPT, а контроль створеного AI коду — у матеріалі код від AI: хто його перевірив, перш ніж він потрапив до користувачів.
Чим агент відрізняється від чатбота
Чатбот повертає текст, а відповідальність залишається на людині. Агент додатково має інструменти — підключення до API: він може прочитати поштову скриньку, створити документ або надіслати повідомлення. У цьому й полягає вся різниця між «згенерував нісенітницю» та «згенерував нісенітницю й одразу надіслав її тридцятьом клієнтам». Крім того, агент обробляє вміст, який компанія не створювала й не схвалювала: чужі електронні листи, вкладення та вебсторінки. Саме тут виникає простір для атаки.
Що таке prompt injection на конкретному прикладі
Уявіть агента, який щоранку переглядає корпоративну поштову скриньку, сортує запити й готує відповіді. Надходить лист, схожий на звичайне звернення. Проте десь у його тексті — дрібним шрифтом кольору тла або в метаданих вкладення — міститься команда для агента: переслати останні виставлені рахунки на вказану адресу.
Агент без належного захисту може її виконати. Не тому, що він «дурний», а тому, що мовна модель отримує завдання й дані як єдиний потік тексту — вона не має окремих «командного рядка» та «введення даних», як класичне програмне забезпечення. OWASP додає, що введення не обов’язково має бути видимим або зрозумілим для людини: достатньо, щоб його могла обробити модель.
Розрізняють дві форми. Пряма ін’єкція виникає, коли користувач безпосередньо в розмові змушує модель поводитися інакше. Непряма — небезпечніша для компаній — виникає, коли команда потрапляє до системи через сторонній вміст, який завантажує агент: електронний лист, документ, вебсторінку або заявку. Microsoft описує її як ситуацію, коли зловмисник вставляє інструкції у сторонній вміст, а AI сприймає їх як легітимну команду.
Висновок простий: вхідні дані не можна сприймати як команди.
Чому prompt injection неможливо просто «відфільтрувати»
Перша реакція зазвичай така: поставимо фільтр. Фільтри й моделі, навчені виявляти атаки, існують і мають сенс, але непроникною стіною вони не є. Британський NCSC у своїй позиції щодо впровадження агентів прямо зазначає, що захист має зосереджуватися на заходах поза моделлю, які обмежують те, що система взагалі здатна зробити. Наприклад, модель, яка обробляє пошту від сторонніх осіб, не повинна мати доступу до привілейованих інструментів. Microsoft рекомендує будувати систему, виходячи з припущення, що частина атак пройде захист, і створювати кілька його рівнів, щоб можлива шкода залишалася мінімальною. Отже, ми не шукаємо ідеального фільтра — ми створюємо систему, у якій навіть успішна ін’єкція не може завдати шкоди, бо агент не має необхідних прав, а чутливу дію все одно повинна схвалити людина.
Мінімальні права доступу: агент не повинен мати більше прав, ніж людина, яку він представляє
Це найдешевший ефективний захід, доступний невеликій компанії. Агенту, який готує рахунки, потрібно бачити замовлення, прайс-лист і контакти — але не зарплати, особові справи чи резервні копії. Якщо він їх не бачить, не має значення, наскільки винахідливо хтось намагатиметься його переконати: агенту просто немає звідки їх узяти.
OWASP виділяє Excessive Agency, тобто надмірну самостійність, як окремий ризик і поділяє його на зайві функції (агент має інструменти, які йому не потрібні для роботи — зазвичай через використання готової інтеграції «повним пакетом»), зайві права доступу (інструмент має в цільовій системі більше прав, ніж потребує завдання) і зайву автономність (для дій із серйозними наслідками немає контрольного кроку). На практиці для невеликої компанії це означає:
- Розділіть читання й запис. Збір даних виконує роль, яка може лише читати; для запису існує окрема, вузько визначена роль.
- Чітко перелічіть дозволені інструменти. Перелік «може створювати й редагувати документ» безпечніший за список заборон: усе, чого немає в переліку, виконати неможливо.
- Забезпечуйте дотримання прав у цільовій системі. Дозволені дії визначає не текст промпту, а бухгалтерська система, файловий або поштовий сервер — рівень, на який модель не може вплинути.
- Не використовуйте обліковий запис адміністратора. Агент із правами доступу до всієї мережі — найпоширеніший спосіб спростити пілотний проєкт і водночас найбільша можлива помилка.
Які дії завжди має підтверджувати людина
Human-in-the-loop означає, що між рішенням агента та його виконанням стоїть людське «так». Microsoft називає це останньою лінією захисту; OWASP рекомендує людське схвалення для дій із серйозними наслідками. Ідеться про п’ять категорій:
- рух коштів — платіжне доручення, зміна банківських реквізитів постачальника, кредит-нота;
- видалення й незворотні зміни — видалення документа, файлу або запису;
- масові повідомлення — одночасне надсилання електронного листа кільком адресатам;
- передавання даних назовні — експорт, пересилання вкладення за межі компанії, надання спільного доступу до папки;
- зміна прав — додавання облікового запису, розширення доступу, вимкнення контролю.
Підтвердження має відповідати одній умові: людина повинна бачити, що саме станеться — кому, скільки, який файл, — а не лише діалогове вікно «Погоджуєтеся?». Вікно без конкретного змісту вже за тиждень починають підтверджувати не дивлячись, і воно перетворюється на формальність.
Журнал аудиту: хто, що, коли й за чиєю командою
Журнал аудиту — це запис, за яким можна відновити послідовність дій агента. До того ж лише з нього ви можете дізнатися, що взагалі щось сталося.
У посібнику щодо мінімальних прав для агентів Microsoft називає типову слабкість: журнали часто фіксують лише відповідь у чаті, але не фактичні виклики інструментів, обсяги прав і рішення пов’язаних систем. Під час розслідування такий журнал марний. Придатний запис містить хто (ідентифікатор агента, власний обліковий запис замість спільного пароля), за чиєю командою (яка людина або подія ініціювала дію), що (викликана операція та її параметри, а не текст відповіді), коли, з якими правами, з яким результатом і спільний ідентифікатор усього запуску, щоб можна було відтворити ланцюжок кроків.
Частину роботи виконують оператори платформ — Microsoft реєструє в журналі аудиту окремі події для запуску агента, виклику інструмента й спрацювання захисного механізму. Залишається перевірити, чи вони ввімкнені та чи зберігаються журнали достатньо довго.
Обмеження, ізоляція середовища й аварійний вимикач
Останній рівень обмежує шкоду в часі. OWASP рекомендує обмежувати кількість дій за певний період, а NCSC — надавати агентам мінімальний доступ на якомога коротший час і відстежувати незвичну поведінку. Ліміт дій визначає, скільки документів, електронних листів або файлів агент може опрацювати за годину; перевищення має призводити до зупинки й сповіщення, а не до непомітного продовження роботи. Ізольоване середовище означає, що агент працює в окремому обліковому записі й сегменті, звідки не може потрапити до решти мережі. Тимчасові права означають, що розширені повноваження діють лише протягом виконання завдання. Аварійний вимикач — це перевірений спосіб негайно зупинити агента й анулювати його облікові дані. NCSC формулює це жорстко: те, чого ви не можете зрозуміти, відстежити й зупинити, не готове до впровадження.
В основі всього цього лежить звичайна IT-гігієна. Агент, якому дозволено записувати дані до системи, — ще одна причина мати перевірене резервне копіювання: відновлення є єдиною надійною відповіддю на масові помилкові зміни. Про те, де перебувають дані під час обробки, розповідає стаття AI без хмари: які процеси не повинні залишати мережу.
Агент має бути в реєстрі доступів нарівні зі співробітником
Корисна модель для власника компанії: агент із доступом до даних — це ще один запис у реєстрі доступів. Він має власну ідентичність, призначеного власника, відповідального за його поведінку, визначений обсяг прав і дату перегляду. Звідси випливають обов’язки, які щодо людей виконуються автоматично: змінюється процес — переглядаються права доступу; агент припиняє роботу — доступи скасовуються разом із токенами та ключами; під час щорічної перевірки переглядаються також агенти. І права накопичуються так само, як у людей: те, що під час пілотного проєкту розширили «лише тимчасово», залишиться, доки хтось це не скасує.
Запитання, які варто поставити постачальнику AI-агента
Візьміть цю таблицю на зустріч. «Це вирішує наша модель» — не відповідь.
| Запитання | Навіщо запитувати | Належна відповідь |
|---|---|---|
| Які права отримає агент і до яких систем матиме доступ? | Обсяг прав визначає максимальний розмір можливої шкоди. | Конкретний перелік систем, ролей і обсягів доступу; окремі права на читання й запис; жодного облікового запису адміністратора. |
| Що саме журналюється й де зберігається журнал? | Без запису викликаних дій інцидент неможливо розслідувати. | Ідентичність, команда, операція, час, права та результат; зберігання поза агентом протягом визначеного строку. |
| Що станеться, якщо агент помилиться або отримає підроблену команду? | Відповідь покаже, чи враховує постачальник можливість збою. | Обмеження шкоди, зупинка в разі аномалії, сповіщення людини, спосіб виправлення наслідків. |
| Які дії підтверджує людина і як це виглядає? | Без підтвердження помилка одразу потрапляє в робочий процес. | Визначені категорії (кошти, видалення, масові повідомлення, експорт, зміна прав) і підтвердження з конкретним описом дії. |
| Де обробляються дані й хто має до них доступ? | Це визначає, куди потрапляє вміст рахунків, договорів і пошти. | Місце обробки, перелік обробників, правила використання даних для навчання, договірні гарантії. |
| Як негайно вимкнути агента? | Аварійний вимикач не можна шукати лише після виникнення інциденту. | Перевірена процедура зупинки й анулювання облікових даних із зазначенням того, хто має право її запустити. |
Часті запитання
Як упровадити агента, не зупиняючи роботу компанії?
Почніть із пілотного проєкту в одному процесі з невеликими наслідками, де агент спочатку лише читає дані й готує пропозиції для схвалення. Лише коли журнали покажуть, що його дії доцільні, йому можна надати право запису — спершу для зворотних дій, а для незворотних лише в останню чергу.
Чи стосується це невеликої компанії з п’ятьма працівниками?
Так, а в деяких аспектах навіть більше, ніж великої. У невеликій компанії системи й ролі зазвичай не розділені, тому один обліковий запис бачить усе — і підключений до нього агент успадковує повний доступ. Саме тому варто починати з розмежування прав, а не з технології.
Якщо ми використаємо відому платформу, хіба вона не вирішить усе за нас?
Частково так — великі постачальники надають фільтри, журнали аудиту й окремі ідентичності для агентів. Але ніхто не налаштує замість вас обсяг прав, дозволені інструменти, правила підтвердження та межі доступу агента у вашій мережі.
Чи зможемо ми взагалі помітити спробу ін’єкції?
Лише якщо журналюються виклики інструментів і відстежується незвична поведінка — спроба вийти за межі звичайного обсягу доступу або раптове збільшення кількості дій. За відповіддю в чаті цього визначити неможливо.
ITHOPE створює у Брно та околицях AI-автоматизації, які можна експлуатувати без сліпої довіри до моделі: з чітко визначеними правами, підтвердженням чутливих дій і журналом аудиту, за яким можна відновити перебіг подій. Про те, з яких процесів варто почати, розповідає стаття AI-автоматизація для компаній; про керування IT та резервне копіювання й інші послуги можна дізнатися в розділі IT для компаній. Якщо аналіз покаже, що певний процес поки не варто передавати агенту, ми прямо про це скажемо.
Джерела
- OWASP Top 10 for LLM Applications — prompt injection на першому місці (LLM01), надмірна самостійність агентів як окрема категорія.
- OWASP: LLM01 Prompt Injection — пряма й непряма ін’єкція, введення не обов’язково має бути видимим для людини, людське схвалення привілейованих операцій.
- OWASP: Excessive Agency — зайві функції, права й автономність; мінімізація прав, схвалення дій із серйозними наслідками, журналювання, обмеження частоти.
- NCSC: Thinking carefully before adopting agentic AI — позиція британського органу від 15. 5. 2026: мінімальний доступ на найкоротший строк, тимчасові облікові дані, відстеження поведінки.
- Microsoft: Defend against indirect prompt injection attacks — багаторівневий захист із припущенням, що частина атак пройде; підтвердження ризикованих дій людиною.
- Microsoft: Least privilege for AI agents — власна ідентичність агента з призначеним власником, ролі, обмежені завданням, дозволені інструменти, вміст журналу аудиту.
- Microsoft Purview: Audit log activities — події аудиту для запуску агента, виклику інструмента й спрацювання захисного механізму.
Де нас знайти
ITHOPE — компанія з Брно, Чехія: ми робимо відновлення даних з дисків, RAID і NAS, сервіс ПК та ноутбуків та IT для бізнесу, усе у власній лабораторії за адресою Viniční 3587/216, 615 00 Brno.
Телефон +420 775 556 063 (цілодобово). Пристрій можна привезти особисто або надіслати курʼєром (Zásilkovna, PPL).