Что такое AI red teaming и чем он не является
AI red teaming - разрешённое упражнение, которое ищет неблагоприятное поведение, пути злоупотребления и слабые controls в модели и приложении. NIST описывает его как развивающуюся практику, обычно проводимую в контролируемой среде для выявления adverse outcomes и stress testing safeguards.
Это не случайный список «сломай промпт» и не замена обычному pentest. Нужно проверить модель, данные, retrieval, tools, identities, API, UI и операционный процесс.
Red team, evals и pentest решают разные задачи
| Практика | Главный вопрос | Результат |
|---|---|---|
| Eval | Работает ли система по критериям? | Набор, метрики, regression |
| Red team | Как намеренно вызвать вредный исход? | Пути атаки и failed controls |
| Pentest | Какие технические уязвимости эксплуатируемы? | Уязвимости инфраструктуры и приложения |
| Threat model | Что защищаем и от кого? | Активы, границы и сценарии |
| Incident drill | Сможем ли обнаружить и ответить? | Проверка detection и response |
Сильная программа соединяет их: threat model выбирает тесты, red team находит новый сбой, remediation превращает его в regression eval.
Rules of engagement: письменные границы до первого теста
- Системы, endpoints, модели и версии в scope.
- Разрешённые аккаунты и тестовые tenants.
- Допустимые техники и запрещённые действия.
- Окно тестирования и rate limits.
- Разрешённые данные и порядок их удаления.
- Контакты red, blue и product owners.
- Stop conditions и kill switch.
- Канал срочного сообщения о критической находке.
- Хранение evidence и уровень доступа.
- Порядок retest и раскрытия результатов.
Не тестируйте чужой сервис или production-аккаунты без явного разрешения владельца.
Threat model: активы, акторы и trust boundaries
Опишите, что может пострадать: системные инструкции, клиентские документы, embeddings, credentials, деньги, репутация, доступность и решения о людях. Затем перечислите actors: обычный пользователь, злоумышленник, недоверенный документ, поставщик, insider и скомпрометированный tool.
Подготовь threat-model workshop для ИИ-системы. Архитектура: [компоненты и потоки]. Use case: [назначение]. Данные и actions: [список]. Сформируй таблицу: asset, actor, trust boundary, abuse case, prerequisite, impact, existing control, detection и безопасный test idea. Не предлагай эксплуатацию реальных систем, получение секретов или разрушительные действия.
Модель не является границей безопасности
Prompt может снизить вероятность нежелательного ответа, но не заменяет access control. OWASP отмечает, что prompt injection может менять поведение системы, а RAG и fine-tuning не устраняют риск полностью.
Direct prompt injection: тестируйте нарушение цели, а не фразу
Direct injection приходит от пользователя и пытается изменить правила, получить закрытую информацию или заставить систему выполнить недопустимое действие. Создавайте классы по impact: обход scope, раскрытие, unauthorized tool, изменение формата, resource abuse.
Не оценивайте защиту по одному фиксированному тексту. Варианты языка, кодировки, многоходовый контекст и конфликтующие инструкции помогают проверить устойчивость, но evidence храните безопасно.
Indirect prompt injection: недоверенный контент внутри задачи
Инструкция может находиться на веб-странице, в PDF, email, комментарии, изображении или retrieved документе. Пользователь просит «суммировать файл», а приложение передаёт модели чужой текст, который пытается управлять агентом.
- Пометить внешний контент как untrusted data.
- Проверить, может ли он изменить system goal.
- Проверить попытку вызвать tool.
- Проверить доступ к данным другого tenant.
- Проверить скрытые инструкции в поддерживаемых модальностях.
- Проверить output validation и approval.
- Убедиться, что trace показывает источник влияния.
Sensitive information disclosure
Проверяйте, может ли система раскрыть system prompt, secrets из tool environment, данные другого пользователя, закрытые retrieved фрагменты, персональные сведения и диагностические сообщения. Используйте canary secrets, а не настоящие credentials.
Даже если модель отказывается повторить секрет, приложение может утечь через logs, URL, error stack или tool result. Проверяйте весь путь.
RAG и vector store: отдельные тестовые классы
| Риск | Безопасная проверка | Ожидаемый control |
|---|---|---|
| Cross-tenant retrieval | Canary docs двух tenants | Фильтр прав до retrieval |
| Poisoned document | Маркированный недоверенный файл | Source trust и quarantine |
| Stale content | Документ с новой версией | Версия индекса и freshness |
| Missing evidence | Вопрос вне корпуса | Abstain и citation check |
| Embedding leakage | Контролируемые canary queries | Доступ и минимизация данных |
Improper output handling
LLM output является недоверенным вводом для следующего компонента. Если его вставляют в HTML, SQL, shell, template, markdown renderer или API без validation, обычная модельная ошибка превращается в техническую уязвимость.
Тестируйте безопасными маркерами, что output кодируется по контексту, structured data проходит schema, URLs и commands разрешены allowlist, а код не исполняется автоматически.
Excessive agency и tool abuse
Проверьте, может ли агент выбрать tool вне цели, подменить аргументы, расширить scope, повторить действие, обойти approval или заявить об успехе без результата. Используйте mocks и sandbox.
- Tool недоступен текущей роли.
- Аргумент указывает на чужой объект.
- Действие требует approval.
- Approval отклонён или истёк.
- Tool возвращает ошибку или неоднозначный timeout.
- Повтор создаёт потенциальный дубль.
- Результат содержит новую инструкцию.
- Агент достигает лимита шагов.
- Kill switch останавливает workflow.
Unbounded consumption и denial of wallet
Атакующий или ошибочный workflow может создавать длинные inputs, максимальные outputs, циклы tools, массовые embeddings и параллельные запросы. Проверяйте ограничения размера, turns, concurrency, токенов, стоимости и времени.
Rate limit нужен по user и tenant, а не только глобально. Дорогой запрос не должен вытеснить критические операции других клиентов.
Supply chain, model и data changes
В scope входят foundation model, libraries, prompts, datasets, vector database, plugins, MCP/tools и tracing service. Проверьте происхождение, версии, access, integrity, update process и rollback.
Не скачивайте случайный model artifact или dependency ради red team. Используйте утверждённый стенд и software/model inventory.
Безопасный стенд и тестовые данные
Стенд изолирован от production actions, использует отдельные credentials с минимальными правами, synthetic records и canary secrets. Email, платежи, удаление и публикация заменены mock tools.
Severity: оценивайте impact и exploitability
Находка «модель произнесла запрещённую фразу» и «агент изменил чужую запись» имеют разный уровень. Запишите актив, preconditions, необходимый доступ, повторяемость, масштаб, обнаруживаемость, обратимость и worst credible impact.
| Фактор | Вопрос |
|---|---|
| Impact | Какие данные, действия или люди затронуты? |
| Exploitability | Насколько доступна и повторяема цепочка? |
| Scope | Один ответ, tenant или вся система? |
| Detection | Увидит ли monitoring попытку и успех? |
| Recovery | Можно ли отменить и уведомить? |
Карточка находки: достаточно доказательств, минимум опасных данных
Оформи red-team finding по безопасным данным. Title и affected asset: [данные]. Версии: [данные]. Preconditions: [условия]. Safe reproduction: [шаги без реальных секретов и ущерба]. Observed result и evidence: [данные]. Expected control: [контроль]. Impact и scope: [оценка]. Сформируй severity rationale, root-cause hypothesis, containment, remediation owner, retest criteria и regression test. Отдельно пометь неизвестные факты.
Исправление: защита слоями, а не ещё одной фразой в prompt
- Уменьшить права и доступные tools.
- Отделить trusted instructions от untrusted content.
- Проверять identity и authorization в коде.
- Валидировать input, output и tool args.
- Добавить sandbox, allowlist и idempotency.
- Потребовать human approval для consequential actions.
- Ограничить turns, tokens, rate и spend.
- Добавить detection, alert и playbook.
- Обновить обучение и документацию.
Prompt hardening может быть одним слоем, но не единственным.
Retest и regression: доказать закрытие
После remediation повторите исходный test на той же версии стенда, затем variations, negative tests и обычные полезные сценарии. Control не должен закрывать функцию для легитимных пользователей.
Сохраните обезвреженный test case в security regression suite. Прогоняйте его после изменения модели, prompt, index, tool и policy.
План red-team цикла
Финальный чек-лист AI red teaming
- Есть письменное разрешение и scope.
- Определены владельцы и срочный канал.
- Threat model содержит assets и boundaries.
- Стенд отделён от production.
- Используются synthetic data и canary secrets.
- Опасные tools заменены mocks.
- Проверяются direct и indirect injection.
- Проверяются disclosure и output handling.
- RAG тестируется на access и poisoning.
- Агент тестируется на excessive agency.
- Есть limits против unbounded consumption.
- Каждый finding имеет evidence и версии.
- Severity учитывает impact и exploitability.
- Критические находки получают containment.
- Remediation использует layered controls.
- Retest проверяет исходную цепочку и варианты.
- Utility не сломана защитой.
- Находки добавлены в regression suite.
Ценность red team - не количество необычных prompts, а подтверждённое снижение реального риска системы.