AI Blue Teaming: объяснение — три уровня, на которых мера контроля действительно может существовать

Спросите команду безопасности, где находятся её защитные механизмы для ИИ, и в ответ обычно назовут документ с политикой, системный промпт или функцию поставщика. Ничто из этого не является средством контроля. Средство контроля — это нечто, что в момент действия решает, произойдёт ли действие, — и для ИИ-агента есть только три места, которые могут решать: модель, шлюз перед ним и среда вокруг него. Всё, что blue team может честно пообещать, исходит из второго и третьего из них. Это вопрос об уровне, и он предшествует любому другому решению blue team, включая то, что логировать и кому звонить. Именно поэтому важны данные из реальной практики: архив инцидентов ИИ содержит 400 инцидентов с агентами за период с 2024-12 по 2026-10-17, и большинство из них — не истории о модели, которая плохо себя ведёт. Это истории о развёртывании, в котором не было слоя, способного сказать «нет».

Работа «синей команды» в контексте ИИ — это внедрение этих слоёв, настройка того, на что они обращают внимание, и наличие отрепетированного ответа на тот день, когда один из них сработает. Она лишена внешнего блеска, не даёт никакого балла и является единственной половиной пары «красная команда/синяя команда», которая меняет показатель риска.

Что наследует «синяя команда», а что — нет

Традиционная работа «синей команды» опирается на ряд допущений, которые развёртывания ИИ незаметно нарушают. Предполагалось, что журналы полны, поскольку сеть видела каждый пакет. Предполагалось, что активы можно перечислить, поскольку кто-то должен был их предоставлять. Предполагалось, что поведение детерминировано, поскольку программа делает одно и то же при одних и тех же входных данных. Ни одно из этих трёх допущений не выдерживает столкновения с агентом.

Что вместо этого наследует blue team — это система, в которой наиболее значимые решения принимаются внутри запроса, который сетевой уровень воспринимает как обычный HTTPS-трафик к одному имени хоста. Промпт, извлечённый контекст, вызовы инструментов, завершение — всё это находится внутри тела запроса, и если никто не захватывает и не анализирует это тело, развёртывание фактически остаётся без мониторинга, каким бы хорошим ни был периметр. Поэтому первая задача blue team — не обнаружение; это создание сенсора. Без видимости на уровне запросов и на уровне инструментов обнаруживать нечего, и каждый нижестоящий контроль носит декоративный характер.

Кто на самом деле может обеспечить соблюдение контроля

Когда появляется датчик, возникает вопрос, где разрешено находиться каждому элементу управления. Полезнее отображать это по принадлежности, а не по технологии, потому что именно принадлежность определяет, сохранится ли элемент управления в следующем релизе.

Уровень модели принадлежит тому, кто её обучил. Вы не настраиваете его, не можете заглянуть внутрь, и его поведение меняется, когда поставщик выпускает новую версию — а это может случиться в любой вторник. Что вы можете сделать — это зафиксировать версию и рассматривать смену версии как изменение вашего профиля риска, требующее повторного тестирования. Чего вы не можете — это заявлять о наличии контроля здесь. «Модель отклоняет вредоносные запросы» — это свойство, на которое вы полагаетесь, а не механизм, которым вы управляете.

Шлюзовый слой — это место, через которое каждый промпт и каждый ответ модели проходит через компонент, принадлежащий вам. Здесь задаются бюджеты и ограничения скорости, здесь применяются списки разрешённого и права на инструменты, здесь логирование запросов и ответов полно по самой конструкции, и здесь запрос можно переписать, заблокировать или перенаправить до того, как будут оплачены хоть какие-то токены. К тому же средства контроля на шлюзе — единственные, что остаются на месте при смене модели, а это важнее, чем кажется: команды, которые помещают свои средства контроля в промпты, теряют их полностью в тот день, когда переходят на другую модель.

Слой среды — это тот, который полностью ваш: учётные данные и их области действия, исходящий сетевой доступ, доступ к файлам, ограничения песочницы по реальному времени и расходам. Именно здесь скомпрометированный запуск и наносит ущерб. Агент, которого уговорили действовать злонамеренно, опасен ровно в той степени, в какой среда позволила этому действию добраться, — и среда — единственное место, где «минимальные привилегии» — это изменение конфигурации, а не исследовательская задача.

Практическая проверка любого предлагаемого механизма контроля ИИ сводится к одному вопросу: какой из этих трёх слоёв обеспечивает его исполнение? Если ответ — слой модели, то контроль — это лишь надежда. Если ответ — «системный промпт», то это подсказка внутри слоя модели, и она хуже надежды, потому что к ней прилагается документация, утверждающая обратное.

Обнаружение: что агент фактически выдаёт

Обнаружение агентов работает на ином наборе сигналов, чем обнаружение людей. Здесь нет аномалии входа в систему, которую можно было бы сопоставить. Вместо этого есть поток запросов с необычно богатой структурой и четыре семейства сигналов, на которые стоит выдавать оповещения.

• Объём и структура вызовов инструментов. Агент, который внезапно вызывает инструмент чтения файла сорок раз за одну задачу или у которого последовательность вызовов инструментов меняется с трёх шагов на тридцать, заслуживает внимания — не потому, что он злонамерен, а потому, что распределение сместилось.

• Происхождение контента на границе. Какой текст в промпте пришёл от пользователя, какой — из результатов поиска, какой — из результата инструмента, а какой — из памяти. Большая часть обнаружения инъекций в промпт сводится к тому, что «инструктивный текст появился в канале, который должен нести только данные», и это невозможно вычислить, если шлюз не помечает происхождение на входе.

• Границы исходящего трафика и области действия. Запросы к назначениям вне списка разрешённых, чтение путей вне области действия, попытки использовать учётные данные вне предназначенного для них сервиса. Это высокоточные сигналы, и они дешёвы, поскольку среда уже знает, что было разрешено.

• Расходы и задержка как косвенный признак. Неуправляемый цикл и компрометация выглядят одинаково — как изменение наклона кривой затрат. Оповещения о бюджете — самый неглянцевый инструмент обнаружения в стеке и один из самых быстро окупающихся.

То, чего в этом списке намеренно нет, — это классификатор, которому поручено судить, был ли ответ модели вредным. Это первая идея обнаружения, за которую хватаются команды, и та, что стареет хуже всего: она дрейфует вместе с моделью, у неё такой уровень ложных срабатываний, что ваши аналитики приучаются её игнорировать, и она не даёт вам ничего, что можно было бы вписать в runbook.

Сдерживание: три рычага, которые останавливают неудачный прогон

Ограничение агента проще, чем кажется, потому что три параметра покрывают почти всё. Бюджет задаёт потолок того, сколько может потратить запуск, а это ограничивает и финансовые потери, и масштаб последствий зацикливания. Область действия задаёт потолок того, чего может касаться запуск — инструменты, включённые для этой задачи, пути, тенанты. Песочница задаёт потолок того, как долго он может работать и до чего может дотянуться во время работы. Все три — это настройки шлюза или окружения, иными словами, они поддаются принудительному применению.

Принцип проектирования, который имеет значение, — это область действия на уровне задачи, а не на уровне агента. Агент с постоянным набором разрешений — это агент, чьи разрешения будут накапливаться, пока кто-нибудь не проведёт их аудит; агент, получающий учётные данные с областью действия на время выполнения задачи, имеет границу, которая истекает сама собой. Второй вариант сложнее в реализации и гораздо дешевле в защите.

Именно здесь шлюз оправдывает своё название. Механизмы контроля, которые стоят перед каждым вызовом модели — вызовы инструментов и MCP оцениваются до их выполнения, политика контента и маскирование персональных данных применяются до тарификации запроса, — это одни и те же механизмы контроля независимо от того, стоит ли за ними модель, которую вы использовали в прошлом квартале, или та, что вышла на прошлой неделе. Эта непрерывность и есть настоящий продукт: не более совершенный фильтр, а место, где фильтру жить и которое не перемещается вслед за моделью.

Восстановление: воспроизвести, исправить, повторить тестирование

У восстановления после инцидентов с ИИ есть одно преимущество перед восстановлением после сетевых инцидентов: весь запуск обычно записывается. Промпт, контекст, вызовы инструментов, ответы, тайминги — если шлюз занёс их в журнал, инцидент можно воспроизвести, и это более сильная отправная точка, чем та, что есть у большинства расследований.

Повторное воспроизведение выполняет три функции последовательно. Оно устанавливает, что произошло на самом деле, а не то, что, согласно стенограмме, произошло после того, как несколько человек её пересказали. Оно определяет средство контроля, которое должно было сработать, — в этом разница между исправлением симптома и исправлением границы. И оно порождает регрессионный случай: записанный вход, который теперь должен блокироваться, запускается против новой конфигурации, чтобы доказать, что он действительно блокируется.

Чаще всего синие команды промахиваются именно на этапе патча. Если находка касалась поведения модели, все доступные меры смягчения лежат вне модели — сокращение области охвата, фильтр на шлюзе, удалённое из среды разрешение. Если находка касалась поведения системы, исправление кроется в конфигурации, а регрессионный тест обходится дёшево. В любом случае повторное тестирование не является опциональным, потому что и исправление, и версия модели меняются, а контроль, проверенный на сборке прошлого месяца, — это утверждение о прошлом месяце.

Репетиция дня, когда это сработает

Регламент (runbook), который никогда не читали под давлением, — это документ, а не реальная способность. Полезна только узкая и конкретная репетиция: возьмите один правдоподобный инцидент с агентом, пройдите его от начала до конца и замерьте время каждого шага. Кто это замечает? Сколько времени пройдёт, прежде чем человек посмотрит на нужную строку лога? Кто может остановить запуск — один конкретный человек или комитет? Кто может отозвать учётные данные, и сколько времени занимает распространение отзыва? Кто решает, уведомлять ли кого-либо за пределами компании?

Два из этих вопросов неизменно застают команды врасплох. Вопрос «Кто может остановить запуск» не работает, когда для остановки нужен человек, который спит, поэтому ответом должен быть механизм, а не человек — лимит бюджета или аварийный выключатель, который дежурный инженер может задействовать в одиночку. Вопрос «Сколько времени занимает отзыв» не работает, потому что учетные данные часто кэшируются в компонентах, которых не было на схеме.

Чтение архива — самая дешёвая доступная форма репетиции, потому что она позволяет унаследовать структуру чужих инцидентов вместо того, чтобы изобретать свою. Возьмите несколько записей, похожих на ваше развёртывание, и по каждой задайте три вопроса выше. Записи, по которым вы не можете на них ответить, — это пробелы в вашем runbook; вы нашли их до инцидента, а не после.

Асимметрия, о которой стоит сказать прямо

Работа красной команды и синей команды — это не симметричные виды деятельности, и бюджетировать их так, будто они симметричны, нельзя. Запуск красной команды ограничен графиком и даёт набор находок, которые устаревают по мере изменения цели. Средства контроля синей команды сохраняются, накапливаются и являются единственным, что действительно стоит между плохим входным данным и плохим исходом. Одна деятельность может найти границу; удержать её способна только другая.

Это делает честный стандарт для blue team неброским и проверяемым. Для каждого контроля, который вы заявляете, вы должны быть способны назвать слой, который его обеспечивает, строку журнала, которая доказывает, что он сработал, оповещение, которое сообщает вам, когда он не сработал, и человека, который может отключить этот запуск. Четыре предложения. Если хотя бы одного из них нет, контроль — это документ политики, а документы политики не читают тела запросов.