Цель red teaming — не "сломать ради интереса", а заранее найти слабые места. Если агент подключен к CRM, базе знаний, платежам, почте, документам или внутренним API, ошибка может стоить дорого: утечка данных, неверное действие, репутационный риск, юридическая проблема или потеря денег.
Red teaming обычно включает сценарии prompt injection, jailbreak-попытки, tool poisoning, запросы на sensitive data disclosure, провокации в сторону запрещенных действий, конфликтующие инструкции, многошаговые обходы и проверку fallback-to-human. Результаты фиксируют в отчет: что удалось, почему guardrail не сработал, какой риск и как исправить.
Для продакшен-агентов red teaming лучше делать не разово, а как часть release process. Новая модель, system prompt, tool policy, RAG-индекс или новый инструмент могут изменить поведение агента. Поэтому опасные сценарии стоит хранить как dataset for evals и запускать перед релизом.
Примеры
- Тестировщик просит агента игнорировать system prompt и показать внутренние инструкции. Агент должен отказать и продолжить безопасный сценарий.
- Пользователь вставляет prompt injection в документ RAG, чтобы агент отправил данные из CRM. Red teaming проверяет, сработают ли retrieval guardrails и tool policy.
- Агенту дают многошаговый запрос: сначала получить список клиентов, потом экспортировать email. Тест проверяет, заблокирует ли система опасный tool call.
- В support-боте проверяют, сможет ли пользователь добиться возврата денег без проверки личности и approval workflow.
- После смены модели команда запускает набор red team evals, чтобы убедиться, что refusal template и guardrails не стали слабее.
Где используется
- Проверять ИИ-агента перед запуском в продакшен.
- Находить слабые места в system prompt, guardrails и tool policy.
- Тестировать защиту от prompt injection, jailbreak и tool poisoning.
- Проверять, не раскрывает ли агент персональные данные, секреты и внутренние инструкции.
- Оценивать риск опасных действий через подключенные инструменты.
- Создавать dataset for evals из найденных атакующих сценариев.
- Проверять безопасность после смены модели, промпта, RAG-индекса или набора инструментов.
- Готовить отчет с рисками, воспроизведением и рекомендациями по исправлению.
- Улучшать release process, regression suite и audit log для AI-систем.
Связанные термины
Частые вопросы
Чем red teaming отличается от обычного тестирования?
Обычное тестирование проверяет, работает ли система по ожидаемым сценариям. Red teaming специально ищет обходы, злоупотребления, провокации и опасные пограничные случаи.
Что проверять в red teaming ИИ-агента?
Проверяют prompt injection, раскрытие секретов, обход system prompt, опасные tool calls, утечку PII, слабые refusal templates, RAG-атаки и корректность fallback-to-human.
Когда проводить red teaming?
Перед первым запуском, перед крупным релизом, после смены модели или промпта, после подключения новых инструментов и после инцидента безопасности.
Кто должен делать red teaming?
Лучше, если участвуют люди вне команды разработки: безопасность, QA, владелец продукта, юрист или внешние проверяющие. Они чаще находят сценарии, которые разработчики не ожидали.
Что делать с найденными атаками?
Их нужно описать, оценить риск, исправить guardrails или tool policy, добавить в regression suite или eval dataset и проверить повторно перед релизом.
