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

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

Змусити модель проігнорувати інструкцію – ще не те саме, що отримати доступ до закритого документа або провести операцію. Тому якісний пентест не зупиняється на відповіді в чаті. Він простежує, що система дозволяє зробити далі.

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

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

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

Головний висновок: пентест, обмежений тільки вікном чату, просто не бачить більшості реальних ризиків.

Спрощено цей шлях можна показати так:

User or External Content → LLM → RAG / Memory → Tools / API → Business Action

Кожен перехід між компонентами варто розглядати як потенційну межу довіри – особливо коли змінюється джерело даних, контекст авторизації або зона контролю. Саме на таких переходах виникають типові проблеми:

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

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

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

1. Model evaluation вимірює можливості, якість, надійність або поведінку моделі за визначеними сценаріями та метриками.
2. AI red teaming перевіряє, як система поводиться під навмисним adversarial-впливом, і може охоплювати safety, misuse та інші категорії ризиків.
3. LLM-пентест шукає практично експлуатовані слабкі місця в конкретному розгорнутому продукті, його інтеграціях, механізмах авторизації та бізнес-операціях.

У програмі NIST ARIA (звіт NIST AI 700-2) оцінювання AI-застосунків поділено на model testing, red teaming і field testing. Це не класифікація видів пентесту, але вона добре показує, чому оцінювання моделі не замінює перевірку системи в контексті її реального використання.

Prompt Injection – вхідна точка, а не вся атака

Prompt injection описує лише один момент атаки: спробу вплинути на інструкції, контекст або поведінку моделі. Він може бути прямим – через повідомлення користувача – або непрямим, коли небезпечна інструкція потрапляє до контексту з документа, вебсторінки, електронного листа, пам'яті чи відповіді стороннього інструменту. В агентній системі такий вплив може передаватися далі між компонентами й агентами.

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

Розгляньмо однаковий вплив у трьох різних архітектурах:

1. У публічному чат-боті без доступу до внутрішніх систем наслідки частіше залишаються на рівні контенту, доступного контексту, репутаційної шкоди або зловживання ресурсами.
2. У корпоративному асистенті з RAG той самий вплив уже може призвести до витоку закритого документа.
3. В агента з доступом до API – до зміни даних або запуску операції.

Формулювання атаки в усіх трьох випадках може бути практично однаковим. Різниця – виключно в тому, що AI-система дозволяє зробити далі.

Тому головне запитання під час пентесту звучить не «Чи вдалося змінити відповідь моделі?», а «До якого підтвердженого результату це дозволяє дійти в конкретній системі?».

Що насправді повинен охоплювати сучасний LLM-пентест

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

Адже не кожен AI має RAG, довгострокову пам'ять, MCP чи складні multi-agent сценарії – тому й тестувати всі продукти «під одну гребінку» немає сенсу. Нижче – три рівні, які наочно пояснюють, чому звичайного тестування чат-вікна тут категорично замало.

Рівень даних

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

Перевірці на цьому рівні підлягають:

• розмежування доступу в RAG і векторних сховищах;
• прямі та непрямі джерела контексту;
• ізоляція користувачів і тенантів;
• запис даних у сесійну та довгострокову пам'ять;
• збереження секретів і персональних даних;
• poisoning пам'яті та retrieval-контенту.

Корисне запитання, яке варто поставити собі: якщо користувач не має права відкрити документ напряму, чи може модель усе одно знайти його, процитувати або використати для відповіді?

Основний ризик простий: недовірені дані впливають на поведінку моделі, а помилки в retrieval або пам'яті відкривають доступ до інформації, якої користувач бачити не повинен. Наслідком може стати витік конфіденційних даних, порушення tenant isolation, розкриття персональних даних або довгостроковий вплив на майбутні сесії через «отруєну» пам'ять.

Рівень виконання

Інструменти перетворюють модель із генератора тексту на компонент, здатний змінювати стан системи. Вона може створити запис у CRM, надіслати повідомлення, оформити замовлення або ініціювати платіж – залежно від функцій, які їй доступні.

Уявімо сценарій: сторонній MCP-сервер повертає не лише дані, а й інструкцію, яка впливає на наступне рішення моделі. Пентест має перевірити, чи сприйме система такий output як довірений і чи зможе він запустити інший інструмент.

Далі перевіряють:

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

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

Головний ризик: якщо function calling чи MCP-інтеграція недостатньо обмежені, а бекенд довіряє рішенню LLM замість повторної перевірки, маніпульована модель отримує ті самі можливості, що і легітимний виклик – включно з ініціюванням платежу, зміною запису чи іншою операцією, яку користувач ніколи не запитував.

Рівень авторизації

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

Обов'язково перевірити:

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

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

Логування та можливість аудиту проходять через усі три рівні: якщо дію на будь-якому з них неможливо відстежити постфактум, оцінити реальний масштаб інциденту складно, як і пояснити його значення CTO, CISO чи Product Owner AI-рішення.

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

Залежно від архітектури перевірка може також охоплювати AI supply chain, сторонні моделі та бібліотеки, системні промпти, model endpoints, керування ключами, обробку згенерованих даних, rate limits, ресурсні обмеження й інфраструктуру розгортання. 

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

Перевіряйте, що система може зробити, а не лише що каже модель

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

Є суттєва різниця між такими станами: модель погодилася виконати заборонену інструкцію; система фактично розкрила закриті дані; tool call був сформований; бекенд прийняв і виконав цей виклик; операція реально змінила стан системи; дія вплинула на користувача, платіж, замовлення, документ чи бізнес-процес.

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

Наприклад, модель погодилася «оформити повернення» – це ще не знахідка з підтвердженим бізнес-впливом. Потрібно встановити, чи сформувався tool call, чи прийняв його бекенд, чи пройшла авторизація та чи змінився статус реального замовлення. Лише тоді можна оцінити вплив і визначити, які контролі не спрацювали.

Для кожного знайденого ризику варто зафіксувати:

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

Саме такий формат перетворює технічну знахідку на аргумент, зрозумілий і security-команді, і бізнесу.

Демонстрація prompt injection проти повноцінного LLM-пентесту

Різницю між побіжною демонстрацією і повноцінною перевіркою легко побачити поруч:

Успішний prompt injection – це привід продовжити перевірку, а не момент, на якому вона має завершитися.

Питання, які варто поставити перед вибором підрядника з LLM-пентесту

1. Як ви формуєте обсяг пентесту – за фіксованим чеклістом чи під архітектуру продукту? Хороша відповідь показує, що підрядник аналізує архітектуру, джерела даних, потоки даних, доступні інструменти та інтеграції, ролі й дозволи, бізнес-критичні дії – і адаптує перевірку під конкретну систему, а не пропонує один стандартний пакет для будь-якого AI-продукту.
2. Ви тестуєте весь застосунок чи лише інтерфейс моделі – і чи розділяє звіт знахідки за рівнями? Важливо з'ясувати, чи входять до перевірки бекенд, RAG, пам'ять, інструменти, API та downstream-системи, і чи звіт розділяє знахідки на рівні моделі, застосунку та інфраструктури – це допомагає правильно розподілити усунення вразливостей між командами.
3. Чи тестуються автентифіковані ролі та межі прав? Один сценарій публічного користувача не показує ризиків різних ролей, тенантів і сервісних акаунтів.
4. Чи оцінюєте ви function calling, інструменти та MCP-інтеграції? Це критично для систем, здатних виконувати реальні дії, а не лише відповідати текстом.
5. Чи тестуються непрямі вхідні дані? Підрядник має враховувати документи, вебконтент, листи, вихідні дані інструментів та інші джерела контексту, а не лише повідомлення користувача.
6. Як ви підтверджуєте реальний вплив і водночас контролюєте ризик тестування? Підрядник має пояснити, як відрізняє небажану відповідь від експлуатованої вразливості, як безпечно підтверджує наслідок без пошкодження production-даних і як пов'язує знахідки з конкретним бізнес-ризиком.
7. Чи охоплюєте ви multi-step та multi-agent сценарії? Важливо для продуктів з оркестрацією, делегуванням завдань та автономними діями.
8. Чи тестуєте ви AI supply chain та інфраструктуру, якщо вони входять до узгодженого обсягу? Це можуть бути сторонні моделі, бібліотеки, model endpoints, ключі доступу, журнали, rate limits і середовище розгортання.

Чекліст обсягу LLM-пентесту

Дані

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

Виконання

• Чи може модель викликати функцію, до якої не повинна мати доступу?
• Чи обмежено те, що кожному інструменту дозволено робити?
• Чи перевіряються інструкції, дані та дозволи сторонніх MCP-серверів?
• Чи валідуються параметри й результати API-викликів?
• Чи можна підмінити параметри tool-виклику?
• Чи обмежені операції, які неможливо скасувати?
• Чи вимагають критичні й незворотні дії незалежного підтвердження?

Доступ і авторизація

• Чи діє агент у межах прав саме того користувача, від імені якого працює?
• Чи зберігається ідентичність користувача на кожному кроці ланцюжка?
• Чи не використовують різні користувачі спільний надмірно привілейований service account?
• Чи має агент лише ті права, які потрібні для конкретної задачі?
• Чи може один тенант вплинути на дані або дії іншого?
• Чи перевіряє кожна downstream-система права незалежно?
• Чи може агент делегувати іншому агенту операцію, недоступну йому самому?

Бізнес-логіка

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

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

Висновок

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

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

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

Хочете перевірити, чи враховує ваша поточна security-перевірка всі реальні можливості AI-продукту?