Що передбачає тестування на проникнення для LLM-продуктів?

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

Окремої уваги потребують сценарії, у яких модель має доступ до конфіденційних даних. Йдеться про ризик Sensitive Information Disclosure з OWASP Top 10 for LLM Applications. У таких випадках модель може випадково розкрити персональні дані, фінансову інформацію, комерційні відомості або інші чутливі дані. 
Для компанії це не лише технічна проблема. Якщо цей ризик не контролювати, компанія може втратити довіру клієнтів, порушити внутрішні правила безпеки та зіткнутися з проблемами під час аудиту або регуляторної перевірки.
Пентест інтеграції LLM-рішень оцінює не лише вразливість, а і її вплив на бізнес-процеси, дані клієнтів і репутацію компанії.
Тестування також охоплює сценарії, де відповідь LLM автоматично передається іншим компонентам системи. Наприклад, модель генерує SQL-запит, команду, рішення для workflow або інструкцію для API. Якщо output не перевіряється, відповідь моделі може перетворитися на реальну небезпечну дію.

Які ризики виникають для компаній?

Невідповідність вимогам PCI DSS — пряма загроза стабільності бізнесу. У разі витоку платіжних даних через вразливість у застосунку вся відповідальність покладається на компанію.
Наслідки починаються з фінансових санкцій: міжнародні платіжні системи (Visa та Mastercard) мають право накладати щомісячні штрафи, які можуть сягати десятків тисяч доларів — і нараховуватимуться до повного усунення проблеми.
У разі підтвердженого витоку карткових даних до цього додаються витрати на розслідування інциденту та компенсації постраждалим клієнтам. У найгіршому сценарії платіжні мережі можуть призупинити або повністю позбавити компанію права приймати карткові дані.
Проте найболючіший удар — репутаційний. Публічний скандал через витік даних підриває довіру користувачів, яку вкрай важко повернути. Внаслідок цього можливий відтік клієнтів і падіння продажів — навіть після усунення технічних проблем.
У найгіршому сценарії це може завершитися повною компрометацією системи: 

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

З чого почати перевірку?

Перший крок — описати архітектуру ШІ-компонента. Необхідно визначити, де використовується LLM, які джерела даних вона бачить, інструменти, що можуть бути викликані, ролі користувачів, які взаємодіють з агентом, та дії, що виконуються системою автоматично.
Другий крок — перевірити права агента. Часто ШІ-компонент отримує надмірний доступ «для зручності розробки». На етапі запуску це здається швидким рішенням, але в продуктивному середовищі створює зайвий ризик. Агент повинен мати лише ті дозволи, які потрібні для конкретного сценарію.
Третій крок — звернутися до фахівців, які проводять пентест LLM-рішень за OWASP Top 10 for LLM Applications. Вони перевіряють не лише вебінтерфейс і API, а й специфічні ризики для систем з інтегрованим ШІ: prompt injection, витік чутливих даних, ізоляцію контексту, підключені API, обробку відповіді моделі та обмеження автономних дій агента. 
Окремо варто перевірити налаштування логування. Команда безпеки має бачити, які запити отримує агент, які інструменти викликає, які рішення ухвалює система і які дії виконуються після відповіді моделі. Без цього розслідування інциденту може стати майже неможливим.