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

AI Penetration Testing – це перевірка безпеки системи, у якій AI є об’єктом атаки: тестувальники з’ясовують, чи можна змінити поведінку моделі, отримати доступ до чужих даних або змусити агента виконати небажану дію. Обсяг тестування (scope) формується індивідуально під архітектуру, інтеграції та бізнес-логіку кожного рішення. Відповідно, перевірки в межах AI пентесту можуть відрізнятися, але серед них можна виділити 12 основних напрямів.

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

У статті розберемо 12 ключових видів перевірок, які ми проводимо під час тестування на проникнення в AI-системи. Це не фіксований чи вичерпний стандарт: частина перевірок може не застосовуватися під час пентесту. 

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

AI пентест (AI Penetration Testing) – це практичне тестування безпеки AI-системи: контрольована імітація атаки, під час якої перевіряють, чи може атакувальник змінити поведінку системи, отримати недозволений доступ до даних або змусити її виконати небезпечну чи несанкціоновану дію.

Обсяг тестування визначається поверхнею атаки (attack surface) – сукупністю компонентів, взаємодій і точок доступу AI-системи, через які атакувальник може вплинути на її поведінку, дані або дії: 

• чат-інтерфейс і системний промпт;
• джерела RAG;
• підключені tools та API;
• інтерфейси керування правами агента;
• персистентна пам'ять;
• модулі обробки зовнішнього контенту.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Це напрями, які команда Datami перевіряє під час AI Penetration Testing. Але не кожному продукту потрібні всі дванадцять одразу: чат-бот без зовнішніх систем не потребує тестів на tool calling, а проста RAG-система – перевірки на goal hijacking. 

Як проходить AI Penetration Testing

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

В межах цих 7 етапів ми проводимо описані вище 12 перевірок AI-системи.

Що бізнес отримує від AI Penetration Testing

За результатами тестування на проникнення бізнес отримує не просто список вразливостей, а конкретну користь:

• Реальну картину ризиків замість гіпотез: бачення, які вразливості існують у моделі, даних, агентних діях чи операційному середовищі та до яких негативних наслідків вони можуть призвести.
• Підтверджені ланцюжки атак: розуміння, як окремі слабкості, наприклад вразливий guardrail і надмірні права агента, комбінуються в реальний сценарій атаки, а не залишаються розрізненими знахідками.
• Звіт, зрозумілий і команді, і керівництву: розробники отримують покрокові рекомендації для усунення прогалин у безпеці ШІ-систем, а бізнес – оцінку впливу на продукт і клієнтів.
• Проактивну позицію замість реакції на інцидент: перевірка AI-рішення виявляє вразливості завчасно – ще до того, як їх знайде хтось інший: зловмисник, клієнт чи регулятор.

Висновки

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

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

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

Ваша компанія використовує AI-рішення і прагне переконатися в його безпеці? Перевірте його на реальні сценарії атак разом із командою Datami.