Более 50 организаций весной получили доступ к Project Glasswing от Anthropic, а вскоре OpenAI запустила для компаний программу Daybreak с GPT-5.5. На этом фоне желтые команды из редкого термина для Black Hat-слайдов превращаются в вполне прикладную функцию: это инженеры, которые одновременно собирают инструменты для атак и защиты, чтобы проверить, как ИИ меняет кибербезопасность. Для русскоязычной IT-аудитории сигнал простой: если в компании уже экспериментируют с ИИ в разработке и ИБ, без такой прослойки между разработчиками, red team и blue team скоро станет тесно.
Об этом сообщает Dark Reading, разбирая, как крупные игроки тестируют новые модели в боевых, но контролируемых сценариях. В апреле Anthropic пригласила более 50 организаций в Project Glasswing, где участникам дали ранний доступ к Claude Mythos, который компания на тот момент называла самым продвинутым ИИ для задач кибербезопасности. Следом OpenAI открыла программу Daybreak для работы с GPT-5.5. Схема быстро стала понятной: red team пытается с помощью моделей искать уязвимости и собирать эксплойты, blue team проверяет, как это детектировать и закрывать, а между ними появляется новая роль. Желтые команды не просто наблюдают за этим матчем, а пишут сам инвентарь для обеих сторон: обвязки, политики доступа, ограничения, цепочки агентов и процессы, которые позволяют ИИ работать не как дорогая игрушка, а как инструмент.
Термин yellow team, как напоминает издание, впервые громко прозвучал еще на Black Hat 2017 как попытка втянуть разработчиков в процесс security-тестирования. Теперь идея получила вторую жизнь из-за ИИ. По словам CISO Zscaler Сэма Карри, такие команды по сути выступают как «инженерный отдел» сразу для двух направлений: спрашивают у red team, какие инструменты нужны для более сильных атак, и у blue team, каких защитных возможностей не хватает вендорскому стеку. Это важный сдвиг. Еще недавно компании спорили, заменит ли модель отдельные ручные задачи пентестера. Сейчас разговор стал взрослее: без инженерной упаковки модель часто шумит, ошибается в контексте и выдает ворох ложных срабатываний.
Хороший пример привел CISO Netskope Джеймс Робинсон. Когда команда впервые получила доступ к Mythos, оказалось, что модель не так уж похожа на «нажал кнопку и нашел баг». Она видела уязвимости, но не всегда понимала контекст, который для живого пентестера очевиден. Один из примеров: система пометила внутренний endpoint как незащищенный из-за отсутствия аутентификации, но не учла, что этот endpoint вообще не виден из интернета и намеренно открыт только внутри контура. Именно на таком разрыве между формальной логикой модели и реальной архитектурой чаще всего и ломаются завышенные ожидания. В Netskope к этому подошли системно: еще во время участия в Daybreak компания собрала небольшую yellow team под названием Project Red Horizon и поручила ей создать для GPT-5.5 специальную «обвязку».
Эта обвязка, или harness, и есть главный технический сюжет всей истории. Речь не про косметические guardrails, а про программную оболочку, которая определяет, что именно модель может делать, к каким данным и системам имеет доступ, какие политики обязана соблюдать и как должен выглядеть ее рабочий цикл. По словам Робинсона, даже после создания harness команда Netskope сначала получила «тонну находок», но значительная часть оказалась ложноположительной из-за неверно заданного контекста. Иными словами, ИИ в ИБ отлично масштабирует не только полезность, но и хаос, если его плохо настроить. Именно поэтому желтые команды становятся не украшением оргструктуры, а инженерным противоядием против избыточного шума.
У крупных компаний эти harness-подходы уже довольно конкретные. Cisco, участвующая в Glasswing, открыла спецификацию Foundry Security Spec: она ограничивает модель детализированной «конституцией», использует ИИ-агентов для 13 ролей и описывает около 130 подзадач и требований. У Microsoft система MDASH опирается более чем на 100 специализированных агентов, которые ищут баги в рамках пятиэтапного цикла. У Cloudflare агенты в аналогичной схеме работают по восьмишаговой процедуре. Инженер Cisco Омар Сантос описывает три режима применения таких систем: от генерации эксплойтов по результатам статического анализа до более сложных сценариев, где в ход идут документация по продукту, старые advisories, накопленные offensive-техники и даже анализ бинарников без полноценной среды исполнения. Это уже не разговор про один чат-бот в браузере. Это конвейер.
Практический эффект тоже есть, и он выражается не только в красивых архитектурных схемах. По данным Dark Reading, компании, которые сумели грамотно «запрячь» Mythos и GPT-5.5, нашли тысячи уязвимостей, включая старые проблемы в базовых технологиях и сложные цепочки эксплуатации. Для blue team это означает неприятную, но полезную новость: если защитники не начнут использовать ИИ для разбора сигналов, событий и приоритезации, объем находок просто завалит их с головой. Корпоративный CISO Zscaler Леви Булури прямо говорит, что из-за роста объема blue и yellow придется теснее интегрироваться. В Netskope это уже видно на уровне процессов: инженеров стали втягивать в патчинг и разбор того, что именно нашла модель, почему она это нашла и как исправлять не точечно, а быстрее и системнее.
Самое интересное начинается там, где история выходит за пределы разовых проверок. Булури отмечает, что задача не в том, чтобы один раз закрыть найденную дыру, а в том, чтобы встроить модели и их выводы прямо в SDLC и поменять привычки разработки. У Cisco этот цикл во многом автоматизирован: защитный инструмент передает знания атакующему, а атакующий, найдя новую проблему, возвращает разведданные обратно в защитный контур. В Netskope такой цикл пока держится на людях и ежедневных scrum-встречах, где yellow team и red team обсуждают, как использовали модели, что узнали за ночь и что нужно зафиксировать в процессах. Похоже, именно это и будет главным признаком зрелости в ближайшие месяцы: не наличие «волшебной» модели, а способность компании быстро превращать ее находки в изменения в коде, пайплайнах и правилах разработки.
Для рынка это ставит неприятный, но полезный вопрос. Если через полгода подобные модели действительно окажутся в руках не только защитников, но и атакующих, то компаниям придется решать не «нужен ли нам ИИ в ИБ», а кто именно внутри бизнеса будет отвечать за его дисциплину, качество контекста и встраивание в инженерные процессы. Похоже, ответом все чаще будут именно желтые команды — не новая модная вывеска, а попытка успеть собрать нормальный процесс раньше, чем это сделают нападающие. Подробнее об этом кейсе пишет .