AI Red Teaming as a Service
Тестирование атакующими сценариями: что система сделает, если её попросят сделать плохо, — и что из этого она не остановит.
Срок 3–8 недель · Отчёт с воспроизводимыми сценариями и планом устранения · обсудить задачу
Что это такое
Red teaming — это не сканер уязвимостей. Сканер ищет известные дефекты по списку. Здесь инженер играет роль атакующего: получает доступ туда же, куда имеет доступ ваша система, и пытается добиться того, чего она делать не должна. Результат — не список «найдено / не найдено», а проверенные сценарии: что именно сделали, на каком шаге сработало, как повторить.
Для мультиагентных систем это отдельный класс задач. Один агент передаёт другому инструкции — и то, что выглядит как безобидная реплика, для второго агента становится командой. Агент с доступом к файлам может заразить память: записать в неё текст, который через несколько запусков прочитают уже другие агенты. Цепочка вызовов может эскалировать привилегии: у каждого шага свои права, но вместе они дают больше, чем задумано.
Мы проверяем три вещи: что система обещает (описанные правила), что она делает (фактическое поведение) и где расходится. Расхождение и есть находка.
Когда это нужно
- Вы выпускаете агента с доступом к внутренним данным и инструментам. Чат-бот отвечает текстом, агент — действует: читает файлы, вызывает API, отправляет письма. Цена ошибки другая.
- У вас несколько агентов, и они общаются между собой. Чем больше каналов передачи инструкций, тем важнее проверить, что границы доверия проходят между ними, а не только по периметру.
- Есть память или общие файлы, которые агенты читают и пишут. Это канал заражения, который не виден на схемах архитектуры, но виден на прогонах.
- Нужен отчёт для внутреннего аудита, заказчика или регулятора. Проверка воспроизводима: сценарий можно повторить и предъявить.
Как проходит работа
- Разведка. Что за система: какие модели, инструменты, данные, какие режимы доступа включены. Здесь же фиксируем, что считается «плохим поведением» — до начала работы, а не после.
- Карта доступа. Где проходит граница доверия, что агент может читать и писать, куда может ходить по сети. Карта согласуется с вами: тестируем только то, что разрешено.
- Атаки. Сценарии: инъекции между агентами, эскалация привилегий через цепочки вызова, заражение через файлы памяти, попытки выноса данных.
- Наблюдение. Записываем, что система сделала и на каком шаге не остановила. Отличаем «сработало правило» от «сработало случайно»: повторяем сценарий.
- Отчёт. Сценарии с воспроизведением, оценка риска, план устранения по приоритетам. Плюс честный список того, что осталось непроверенным.
Что на выходе
- Сценарии атак с шагами воспроизведения — чтобы находку мог повторить ваш инженер, а не только мы;
- Фактическое поведение системы и ожидаемое — рядом, с расхождениями;
- Карта остаточного риска: что исправлено, что нельзя исправить конфигурацией, что остаётся на уровне архитектуры;
- План устранения по приоритетам — что делать сначала и почему;
- Приложение: конфигурация стенда, версии моделей, журналы прогонов и ограничения проверки.
Отчёт пишется так, чтобы его можно было передать технической команде и приложить к внутреннему аудиту, не пересказывая.
Сроки и от чего зависит стоимость
Срок — 3–8 недель. Разброс не из осторожности: он определяется четырьмя вещами, и все четыре вы знаете заранее.
- Число агентов и сценариев проверки. Один агент — один набор; пять агентов с обменом сообщениями — кратно больше комбинаций;
- Доступность среды. Изолированный стенд или ваш рабочий контур — это разная подготовка;
- Режим доступа. Что нам разрешено (только чтение, сеть, файлы) и как это оформлено;
- Требования к воспроизводимости отчёта. Чем строже доказательная база, тем больше журналов и повторных прогонов.
Стоимость называем до начала работ, после разведки и согласования карты доступа: до этого любая цифра была бы выдумкой.
Чего мы не делаем
- Не обещаем «нулевой уязвимости». Любая проверка ограничена сценариями, которые мы прогнали, — это прямо написано в отчёте;
- Не даём гарантий после исправлений без повторного прогона: исправление может закрыть один путь и открыть другой;
- Не атакуем чужие сервисы. Работаем только в среде, на которую у заказчика есть законное основание и письменное разрешение с описанными границами;
- Не публикуем найденные уязвимости. Срок нераскрытия — условие работы, оно фиксируется в договоре;
- Не подменяем судебную или государственную экспертизу. Наш отчёт — технический, а не правовой документ.
Об ограничении по регистрации. Институт находится в процессе государственной регистрации: ОГРН и ИНН пока нет, поэтому договоры мы не заключаем. На этом этапе обсуждаем задачу, согласуем границы и план работ; порядок заключения договоров появится после регистрации — о готовности объявим отдельно.
Частые вопросы
Чем это отличается от пентеста?
Пентест ищет технические дефекты в программах и сетях. Red teaming проверяет поведение: что система сделает с данными и инструментами, к которым у неё есть доступ. У нас находка — воспроизводимое действие агента, а не уязвимость в коде.
Нужен ли доступ к вашему коду?
Нет. Работаем с системой как с чёрным ящиком: важны модели, инструменты, данные, режимы доступа и конфигурация, а не исходный код. Если код предоставят — используем как дополнительный источник, но не требуем.
Что будет, если найдётся серьёзная проблема?
Сообщаем сразу, не дожидаясь итогового отчёта: сначала устранение, потом документ. Публикация без согласования не делается никогда — это условие работы, а не жест.
Другие услуги — в таблице услуг.