Сучасний LLM-пентест виходить далеко за межі Prompt Injection

LLM-пентест – це контрольована перевірка безпеки AI-рішень на основі великих мовних моделей, яка виходить за межі Prompt Injection. Фахівці перевіряють, чи може зловмисник отримати доступ до конфіденційних даних, вплинути на джерела інформації для моделі, використати не за призначенням інструменти та API, обійти авторизацію або спричинити реальну бізнес-дію. Успішна маніпуляція відповіддю моделі сама собою ще не є підтвердженим ризиком – ризик визначається тим, до яких даних, функцій і дій ця маніпуляція відкриває доступ. 

LLM-система може працювати з корпоративними даними, RAG, API та зовнішніми інструментами, тому потенційна атака здатна вийти далеко за межі маніпуляції її відповіддю. У нашій практиці ми часто бачимо, що бізнес обмежує перевірку безпеки AI-рішення тестуванням Prompt Injection і вважає це достатнім доказом захищеності. Розберемося, що ще перевіряють під час LLM-пентесту та які ризики це допомагає виявити.

Чому змінилася поверхня атаки

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

Сучасні LLM-рішення не обмежуються моделлю, яка просто отримує запит і генерує відповідь. Вони можуть використовувати RAG для роботи з корпоративними базами знань, зберігати контекст у пам'яті, звертатися до API та зовнішніх інструментів, а AI-агенти – ще й виконувати певні дії в інших системах.

Через це потенційними цілями атаки стають не лише сама модель та її промпти, а й дані, джерела контексту, механізми доступу, інтеграції та функції, доступні LLM. Наприклад, слабке розмежування доступу в RAG може створити ризик витоку закритих документів, а надмірні права AI-агента – дозволити виконати дію, недоступну самому користувачу.

У нашій практиці найнебезпечніші знахідки часто виникали саме на «стиках» між компонентами системи, а не всередині самої моделі.

Саме тому змінився і підхід до перевірки безпеки: чим більше можливостей отримує LLM-рішення та чим глибше воно інтегроване в бізнес-системи, тим більше потенційних шляхів атаки потрібно враховувати під час пентесту.

Що таке LLM-пентест і навіщо його проводять

LLM-пентест (тестування на проникнення в LLM) – це контрольована перевірка безпеки систем і застосунків, що використовують великі мовні моделі (LLM). Під час тесту фахівці з кібербезпеки моделюють реальні сценарії атак і шукають вразливості. Перевірка може охоплювати не лише саму модель, а й пов'язані з нею дані, RAG, API, зовнішні інструменти, механізми авторизації та інші компоненти – залежно від архітектури конкретного продукту.

Головна мета такого тестування на проникнення – зрозуміти, чи може зловмисник використати слабкі місця в LLM-рішеннях для реального впливу на систему або бізнес. Наприклад, отримати конфіденційні дані, до яких він не має доступу, або маніпулювати інформацією, яку використовує модель, обійти встановлені обмеження або через AI-агента ініціювати несанкціоновану дію.

Важливо: під час LLM-пентесту ми перевіряємо не лише те, що «каже» модель у відповіді, а те, що система здатна реально зробити – чи вдасться отримати дані, викликати функцію чи завершити операцію.

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

Одним із найвідоміших способів вплинути на поведінку LLM, на нашу думку, є Prompt Injection. Розберемося, у чому полягає ця техніка і яку роль вона відіграє в межах LLM-пентесту.

Prompt Injection у LLM-пентесті

Prompt Injection як реальна атака

Prompt Injection – це техніка атаки, коли зловмисник намагається за допомогою спеціально сформованих інструкцій змінити поведінку LLM або змусити її проігнорувати встановлені обмеження. Шкідливі інструкції можуть надходити напряму в запиті користувача або непомітно потрапляти до моделі через документи, сайти та інші файли, які вона читає.

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

Prompt Injection у межах LLM-пентесту

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

Водночас стійкість до Prompt Injection – лише один із напрямів перевірки LLM-рішення. Повноцінний пентест має враховувати й інші ризики, пов'язані з архітектурою та можливостями конкретного продукту.

Що охоплює LLM-пентест за межами Prompt Injection

Під час перевірки на Prompt Injection пентестери перевіряють, чи можна за допомогою спеціально сформованих або прихованих інструкцій змінити поведінку LLM. Але для бізнесу важливо знати не тільки те, чи можна «обманути» модель. Потрібно перевірити всю LLM-систему: чи може атакувальник отримати закриті дані, вплинути на джерела інформації для моделі, скористатися її інструментами та API, обійти обмеження доступу або домогтися виконання небезпечної дії. 

Залежно від архітектури конкретного LLM-рішення, така перевірка може охоплювати напрями:

1. Витік конфіденційної інформації

LLM-рішення може працювати з персональними даними, внутрішніми документами, фінансовою інформацією, комерційними даними та іншою інформацією, яка не повинна бути доступна всім користувачам.

OWASP окремо виділяє Sensitive Information Disclosure серед ключових ризиків LLM-застосунків: до нього належать, зокрема, витоки PII, proprietary information і sensitive business data. Prompt Injection може бути одним зі способів спровокувати такий витік, але OWASP прямо зазначає, що обмеження можуть обходитися і Prompt Injection, і іншими методами.

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

2. Безпека RAG і бази знань

Актуально для рішень, які використовують RAG / vector stores.

RAG дозволяє LLM перед відповіддю отримувати релевантну інформацію із зовнішніх джерел – наприклад, корпоративної бази знань або документів. Це розширює можливості системи, але водночас створює додаткову поверхню атаки.

OWASP виділяє Vector and Embedding Weaknesses як окрему категорію ризиків. Серед можливих наслідків – unauthorized access, data leakage, cross-context information leaks і data poisoning. Це особливо важливо для multi-tenant середовищ, де одна vector database може містити інформацію різних груп користувачів.

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

Що перевіряють: 

• Чи може користувач через LLM отримати документи або фрагменти даних, до яких не має доступу.
• Чи належно розділяються дані різних користувачів і тенантів.
• Чи можна вплинути на відповіді системи через шкідливий або маніпулятивний контент у базі знань.

3. Маніпуляції з даними та контекстом

Атакувальник не обов'язково має безпосередньо взаємодіяти з LLM: у певних архітектурах він може спробувати вплинути на інформацію, яку модель пізніше отримає як контекст.

Для RAG-систем OWASP прямо описує data poisoning: шкідливі або скомпрометовані дані можуть потрапити до бази знань і надалі впливати на відповіді моделі. Джерелом можуть бути, зокрема, неперевірений або навмисно внесений контент.

Що перевіряють: 

• Чи можна впровадити, підмінити або змінити інформацію, яку система вважає довіреною.
• Чи перевіряються джерела контексту.
• Чи здатен такий контент змінити подальшу поведінку LLM.

4. Зловживання tools, functions та API

Актуально, якщо LLM або агент може виконувати дії, а не лише генерувати текст.

LLM або AI-агент може мати доступ до зовнішніх функцій та систем: шукати інформацію, змінювати записи, надсилати повідомлення, створювати заявки, працювати з файлами, CRM, платіжними або іншими сервісами.

У термінології OWASP із цим тісно пов'язаний ризик Excessive Agency: він виникає, коли LLM-система має надмірну функціональність, дозволи або автономність, через що скомпрометовані вихідні дані можуть призвести до небезпечної дії. OWASP окремо наголошує, що сучасні agentic-системи додають ризики на кшталт tool misuse та agent privilege escalation.

У звичайного чат-бота небезпечним результатом може бути неправильна або конфіденційна відповідь. У AI-агента наслідком може стати вже реальна дія в іншій системі.

Перевіряють, чи можна змусити систему:

• викликати функцію, якою користувач не повинен керувати; 
• передати небезпечні параметри; 
• виконати дію без необхідного підтвердження; 
• використати зайві можливості, надані агенту.

5. Авторизація та зловживання привілеями

Користувач і LLM або AI-агент можуть мати різні рівні доступу. Небезпека виникає, якщо користувач із низькими привілеями може через AI скористатися ширшими правами самого агента або пов'язаного service account.

Наприклад: користувач → AI-агент → API → корпоративна система. Користувач сам не має права змінити певний запис. Але якщо агент звертається до API з ширшими правами, а бекенд не перевіряє права кінцевого користувача, AI може стати шляхом обходу встановлених обмежень.

Для сучасних agentic-систем OWASP окремо виділяє ризики Identity & Privilege Abuse, а Excessive Agency також прямо пов'язує небезпечні наслідки з надмірними permissions.

Що перевіряють: 

• Чи зберігаються права користувача під час переходу від LLM до інших систем.
• Чи не має агент зайвих привілеїв.
• Чи можна через AI отримати доступ до чужих ресурсів або виконати заборонену операцію.

Повноцінний LLM-пентест – це не вузька перевірка Prompt Injection. Він має враховувати реальну архітектуру LLM-продукту і перевіряти, які можливості для атак створює взаємодія моделі з даними, RAG, інструментами, API, системою авторизації та іншими компонентами.

Що дають ці напрями LLM-пентесту бізнесу

Успішна Prompt Injection – це не фінал перевірки, а привід її поглибити. І особлива цінність LLM-пентесту в тому, наскільки далеко вдається простежити шлях атаки в конкретній системі.

Ці п’ять напрямів, описаних вище, не варто сприймати як обов’язковий набір перевірок – обсяг визначається архітектурою конкретного продукту. Наприклад, перевірка RAG не потрібна системі без нього, а тестування tools/function calling – якщо модель не може викликати такі функції:

• є RAG – перевіряються retrieval, vector stores, доступ до даних і можливий poisoning;
• є tools/API – тестується можливість небезпечного використання функцій;
• є AI-агент – особливо важливими стають permissions, autonomy та authorization;
• система працює з конфіденційними даними – перевіряються сценарії їх несанкціонованого розкриття.

Експертність і контрольованість LLM-пентесту

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

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

У межах тестування на проникнення наша команда:

• визначає scope перевірки з урахуванням архітектури та можливостей конкретного LLM-рішення;
• моделює релевантні сценарії атак на модель і пов'язані з нею компоненти;
• перевіряє ризики несанкціонованого доступу до даних, функцій та інтегрованих систем;
• оцінює, до яких реальних наслідків можуть призвести знайдені вразливості;
• надає звіт із пріоритезацією ризиків і рекомендаціями щодо їх усунення.

Висновок

Prompt Injection – важливий, але далеко не єдиний напрям перевірки безпеки LLM-рішень. Сучасний LLM-пентест враховує архітектуру конкретного продукту та може охоплювати захист конфіденційних даних, безпеку RAG, стійкість до маніпуляцій із контекстом, використання tools і API, авторизацію та інші релевантні ризики.

А ви знаєте, наскільки захищене ваше LLM-рішення за межами Prompt Injection?  Команда Datami готова змоделювати актуальні для вашого продукту сценарії атак, визначити реальний вплив виявлених вразливостей і надати рекомендації щодо їх усунення.