Red teaming LLM: тестуй асистента атакою перед продакшеном

За три тижні до запуску B2B-клієнта один з наших асистентів відповів на хитро сформульований запит, процитувавши фрагмент системного promptу. Це була не помилка моделі, а прогалина в архітектурі guardrails, яку ми виявили самі, бо перед запуском у продакшен провели сесію red teaming. Виправлення зайняло два дні. Якби ми знайшли її після запуску, це коштувало б значно дорожче.

Традиційний pentest інфраструктури шукає вразливості в програмному забезпеченні: відкриті порти, незакриті CVE, помилки авторизації. Red teaming LLM шукає інший тип слабкостей: як модель реагує на вхідні дані, які не були передбачені під час проєктування системи.

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

Чому безперервність важлива? Базова модель може змінитися. База знань RAG зростає і може містити нові документи. Системний prompt модифікується. Кожна з цих змін може відкрити нову поверхню атаки, якої не існувало під час попереднього огляду.

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

Детальну таксономію 10 класів вразливостей описує стандарт OWASP LLM Top 10. Ми в Cashcrown використовуємо цю таксономію як чек-лист під час кожної сесії red teaming.

Не кожна знайдена вразливість однаково критична. Scoring допомагає пріоритизувати виправлення та комунікувати ризики команді.

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

Практичний результат — три пріоритети:

• Критичний: атака може бути виконана непідготовленим користувачем, призводить до витоку даних або виконання незворотної дії. Блокує запуск.
• Високий: атака вимагає підготовки, але є відтворюваною. Виправлення до запуску, а не після.
• Низький/спостережуваний: атака складна або має малий вплив. Потрапляє до реєстру, моніториться, не блокує запуск.

Разовий огляд перед впровадженням необхідний, але недостатній. Цикл безперервного red teaming виглядає так:

1. Кожне нове знайдення (незалежно від джерела: внутрішній тест, звернення користувача, література) потрапляє до каталогу як тестовий випадок.
2. Тестовий випадок має формат: вхідна атака + очікувана захисна відповідь (відмова, маскування, ескалація до людини).
3. Каталог запускається автоматично при кожній зміні системного promptу, оновленні бази знань RAG або зміні базової моделі.
4. Кожен новий результат порівнюється з попереднім: відсутність регресії — умова merge.
5. Щомісяця додаємо нові тестові випадки з актуальної літератури та звернень.

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

Це важливе застереження, яке ми робимо прямо: жодна програма red teaming не доведе, що система є «повністю безпечною». LLM — це ймовірнісні системи: той самий вхід при іншій температурі або іншій версії моделі може дати інший результат.

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

Результати сесії red teaming є частиною технічної документації системи AI, того самого документу, який для систем високого ризику підтримує вимоги AI Act щодо управління ризиками.

Ми в Cashcrown кожну систему асистента проходимо через аудит перед впровадженням (чек-лист із 6 областей, описаний у статті про аудит безпеки асистента AI) та сесію red teaming з каталогом класів атак.

Стартовий каталог включає щонайменше: 5 варіантів прямого prompt injection, 3 варіанти injection через RAG, 4 варіанти jailbreak персонажа, 2 варіанти витоку конфігурації та тести на всіх підтримуваних мовах (шаблони injection польською, англійською, українською, німецькою). Разом 15–25 тестових випадків для типової RAG-системи з інструментами.

Після запуску каталог зростає: кожне звернення або новий шаблон з літератури стає новим випадком. Через 6 місяців роботи система зазвичай має 40–80 тестових випадків. Поточний моніторинг (описаний у статті про моніторинг [hallucination] та поведінки асистента) доповнює red teaming між сесіями.

Архітектура захисного шару, яку тестує red teaming, детально описана в статті про захист від prompt injection та про OWASP LLM Top 10.

Класичний pentest шукає вразливості в інфраструктурі: відкриті порти, незакриті CVE, помилки авторизації. Red teaming LLM тестує поведінку моделі при зловмисних вхідних даних: injection, jailbreak, вимушування витоку конфігурації. Обидва потрібні в повній програмі безпеки, але тестують різні поверхні атак і вимагають різних методів та інструментів.

Для типової RAG-системи з 3–5 інструментами перша сесія включає підготовку стартового каталогу (0,5 дня), проведення тестів (1 день), оцінку та документування знайдених вразливостей (0,5 дня). Разом 2 робочі дні. Результати на старті зазвичай містять 2–6 знайдених вразливостей, з яких 0–2 критичні. Наступні сесії проходять швидше, бо каталог вже готовий.

AI Act не згадує red teaming напряму, але для систем високого ризику вимагає документованого управління ризиками та тестування перед впровадженням. Результати сесії red teaming з каталогом атак, severity scoring та списком мітігацій природно заповнюють цю документаційну прогалину. Для систем загального призначення (типовий інформаційний чатбот) вимоги слабші, але відсутність документації ускладнює захист у разі інциденту.

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

Observability у безперервному моніторингу відіграє допоміжну роль: логування аномалій (спроби injection, розпізнані guardrails), алерти на сплески заблокованих запитів, перегляд зразків відповідей при кожному оновленні бази знань. Не замінює сесії red teaming, але сигналізує про появу нових шаблонів, що вимагають розширення каталогу.