Що входить до AI Penetration Testing: розбір 12 критичних перевірок безпеки

AI Penetration Testing – це перевірка безпеки системи, у якій сам AI є об’єктом атаки: тестувальники з’ясовують, чи можна змінити поведінку моделі, отримати доступ до чужих даних або змусити агента виконати небажану дію. Дві компанії можуть замовити послугу з однаковою назвою – AI Penetration Testing – але отримати принципово різний обсяг перевірок і, відповідно, різні результати: одна команда перевірить лише, чи вдасться обійти інструкції чатбота, інша – протестує модель, RAG, пам’ять, інструменти, права агента та повні ланцюжки атак, що ведуть до реальних наслідків для бізнесу.

Два тести AI-систем можуть дати абсолютно різні результати

У цьому матеріалі йдеться насамперед про LLM-застосунки: чатботи, RAG-системи, copilot-рішення та AI-агентів. Тестування класичних ML-моделей має інші сценарії – наприклад, перевірки на model evasion, extraction або inference – і не входить до цього розбору.

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

1. AI Penetration Testing – тестування, у якому AI-система є ціллю атаки. 
2. AI-powered Penetration Testing – використання AI як інструмента для пошуку класичних вразливостей у звичайних застосунках.

AI red teaming – суміжна методика тестування в умовах протидії, яка може бути частиною повноцінного AI Penetration Testing, але не є його синонімом. 

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

У 2026 році обсяг AI Penetration Testing суттєво розширився. AI-системи більше не лише генерують текст: 

• агенти отримують доступ до CRM, пошти, баз даних і внутрішніх API; 
• MCP-сервери та інструменти дають моделі змогу взаємодіяти із зовнішніми системами; 
• довготривала пам’ять впливає на поведінку в майбутніх сесіях; 
• AI самостійно планує та виконує бізнес-дії; 
• багатоагентні робочі процеси передають завдання між кількома компонентами.

 Що більше автономності, даних та інтеграцій має AI-система, то ширшим має бути обсяг тестування.

Повноцінний тест починається з реальної поверхні атаки

Універсального набору промптів недостатньо. Перед тестуванням команда визначає:

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

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

Розберемо 12 ключових тестувань безпеки за чотирма напрямами: модель, дані й контекст, дії агента та безпосередньо середовище системи.

Захист поведінки моделі

Перевірка безпеки 1. Пряма prompt injection та стійкість до jailbreak-атак

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

Ризик: успішна ін’єкція в промпт змушує модель виконувати команди, які суперечать правилам продукту.

Вплив на бізнес: небезпечні відповіді, порушення внутрішніх політик, регуляторні претензії, репутаційні втрати або перехід до атак на підключені системи.

Приклад: користувач поступово змінює контекст розмови, після чого асистент надає інформацію, яку мав приховувати.

Очікувані докази: відтворюваний сценарій jailbreak, порушене правило, умови успішного обходу та реальний вплив на продукт.

Перевірка безпеки 2. Непряма prompt injection

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

Ризик: непряма ін’єкція перетворює дані, які модель повинна лише проаналізувати, на команду.

Вплив на бізнес: атакувальник впливає на AI без прямого доступу до нього, змінює результати роботи, запускає інтеграції або отримує корпоративні дані.

Приклад: AI отримує документ із прихованою prompt injection і замість аналізу запускає дію в CRM.

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

Перевірка безпеки 3. Стійкість guardrails і дотримання політик

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

Ризик: система блокує очевидні небезпечні запити, але пропускає ті самі наміри в іншій формі.

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

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

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

Jailbreak, prompt injection і слабкі guardrails стають критичними не самі по собі, а тоді, коли відкривають шлях до даних, інструментів або бізнес-операцій.

Захист даних і контексту

Перевірка безпеки 4. Розкриття конфіденційних даних і внутрішніх інструкцій

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

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

Вплив на бізнес: порушення конфіденційності, штрафи, витік комерційної інформації, компрометація облікових даних і втрата довіри клієнтів.

Приклад: внутрішній асистент повертає фрагменти договору іншого клієнта через серію уточнювальних запитів.

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

Перевірка безпеки 5. Авторизація в RAG та ізоляція клієнтських середовищ

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

Ризик: Retrieval- та authorization-логіка повертає релевантні документи або фрагменти, але не застосовує права конкретного користувача, його роль чи межі клієнтського середовища.

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

Приклад: працівник просить асистента порівняти проєкти, а у відповіді з’являються дані закритого клієнтського акаунта.

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

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

Перевірка безпеки 6. Отруєння бази знань, контексту та пам’яті

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

Ризик: шкідливий або неправдивий контент зберігається в пам’яті та впливає на наступні сесії.

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

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

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

Безпека дій AI-агентів

Перевірка безпеки 7. Зловживання викликами інструментів і функцій

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

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

Вплив на бізнес: зміна або видалення даних, небажані повідомлення, помилкові транзакції та порушення внутрішніх процесів.

Приклад: агент повинен лише прочитати лист, але натомість створює запис у CRM або надсилає відповідь від імені працівника.

Очікувані докази: фактичний виклик інструмента, виконана дія, використані права та причина, через яку система дозволила операцію.

Перевірка безпеки 8. Ідентифікація, авторизація та принцип найменших привілеїв

Що перевіряється: чи виконує AI дії з реальними правами користувача після перевірки його ролі, чи використовує надмірно привілейований системний акаунт.

Ризик: користувач отримує через агента більше можливостей, ніж має у звичайному інтерфейсі.

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

Приклад: співробітник без права редагування просить AI оновити запис, і агент виконує операцію через власний привілейований акаунт.

Очікувані докази: дія, роль користувача, використані дозволи та різниця між прямим доступом і доступом через AI. Системний промпт не є механізмом авторизації.

Перевірка безпеки 9. Перехоплення мети та людський контроль

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

Ризик: AI формально використовує дозволені функції, але виконує іншу бізнес-мету.

Вплив на бізнес: несанкціоновані рішення, обхід внутрішніх погоджень, помилкові платежі або дії від імені компанії.

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

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

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

Захист операційного середовища AI-системи

Перевірка безпеки 10. Небезпечне опрацювання результатів моделі

Що перевіряється: чи сприймають зовнішні компоненти результат моделі як довірені дані або команди. Це можуть бути вебінтерфейси, API, системи автоматичного виконання коду або інші агенти.

Ризик: наступний компонент у ланцюжку сприймає шкідливий результат моделі як команду та виконує її.

Вплив на бізнес: зміна даних, компрометація застосунку, запуск небезпечної операції або поширення атаки на інші компоненти.

Приклад: AI генерує структуровану відповідь, яку внутрішня система без додаткової перевірки використовує як команду.

Очікувані докази: шлях від вхідних даних до подальшої дії та компонент, який не перевірив результат моделі.

Перевірка безпеки 11. Виснаження ресурсів і цикли агентів

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

Ризик: легітимні функції перетворюються на спосіб виснаження ресурсів.

Вплив на бізнес: різке зростання витрат на AI, недоступність сервісу, затримки в критичних процесах і перевантаження зовнішніх систем.

Приклад: агент не може завершити завдання та без обмежень повторює виклики моделі й інструментів.

Очікувані докази: кількість операцій, тривалість, витрачені ресурси та контроль, який мав зупинити процес.

Перевірка безпеки 12. Виявлення, журналювання та стримування

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

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

Ризик: атака відбувається без достатніх журналів, сповіщень або способів обмеження наслідків.

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

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

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

Як проходить AI Penetration Testing на практиці

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

1. Огляд обсягу та архітектури – команда визначає компоненти, дані, ролі, інструменти й критичні бізнес-функції.
2. Моделювання загроз і проєктування ланцюжків атак – формуються реалістичні сценарії відповідно до можливостей системи.
3. Ручне та автоматизоване тестування в умовах протидії – автоматизація допомагає розширити охоплення, але ручне тестування потрібне для перевірки бізнес-логіки та складних ланцюжків атак.
4. Перевірка впливу – команда безпечно перевіряє, чи веде вразливість до реального витоку, операції, зміни робочого процесу або фінансових втрат.
5. Звітність і рекомендації щодо виправлення – для кожної виявленої проблеми надаються докази, опис впливу, причина та рекомендації.
6. Повторне тестування – після виправлень перевіряються основний сценарій і альтернативні шляхи обходу guardrails.

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

Чим AI Penetration Testing не є

Повноцінний AI Penetration Testing не зводиться до:

• запуску сотень або тисяч jailbreak-промптів;
• автоматизованого сканування без ручної перевірки;
• тестування лише інтерфейсу чатбота;
• механічного проходження OWASP Top 10 for LLM Applications 2025 без адаптації сценаріїв до конкретної архітектури;
• пошуку небажаних відповідей без перевірки впливу на бізнес;
• AI-powered сканування класичних вебвразливостей;
• AI red teaming без оцінювання логіки застосунку, авторизації та інтеграцій.

Red teaming може бути частиною методології, але повноцінний AI Penetration Testing також має надавати відтворювані результати, підтверджений вплив на бізнес і практичні рекомендації щодо виправлення.

Як оцінити якість послуги та звіту

Перед вибором підрядника варто поставити такі запитання про обсяг тестування:

1. Чи тестується вся AI-система, а не лише чатбот?
2. Чи враховуються RAG, пам’ять, інструменти та дії агента?
3. Чи перевіряються різні ролі й рівні доступу?
4. Чи тестуються прямі й непрямі prompt injection та jailbreak-сценарії?
5. Чи перевіряються реальні дії в підключених системах?
6. Чи будує команда повні ланцюжки атак?
7. Чи пояснюється вплив на бізнес кожної виявленої проблеми?
8. Чи надаються відтворювані докази?
9. Чи адаптується обсяг тестування до конкретної архітектури?
10. Чи входить повторне тестування у вартість послуги?

Ознаки якісної послуги: 

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

Тривожні ознаки: 

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

Висновки

Повнота AI Penetration Testing визначається не кількістю промптів і не довжиною списку вразливостей, а тим, наскільки глибоко перевірено реальну архітектуру системи. Якісний тест має відповісти на три запитання:

1. Як атакувальник може змінити поведінку AI-системи?
2. До яких даних, інструментів або бізнес-операцій це може надати доступ?
3. Чи здатна компанія запобігти реальним наслідкам атаки, виявити їх та обмежити?

До пентесту AI важливо розібратися з базою: архітектурою рішення, доступами, інтеграціями та рівнями автономності. Тільки так ви отримаєте тестування, націлене на реальні загрози конкретно вашої системи, а не формальну перевірку «за шаблоном».