В продакшн-ядре 5G один час генерирует столько телеметрии безопасности, сколько многие корпоративные SOC видят за неделю. На этом фоне мультиагентный SOC, описанный в статье InfoQ, сократил среднее время обнаружения и реагирования примерно на 40%, а выпуск нового правила детекта ужал с трех часов до пятнадцати минут. Для русскоязычной ИТ-аудитории это важный сигнал: узкое место в безопасности все чаще не в аналитиках, а в том, насколько быстро команда успевает переписывать правила под новые угрозы.
Автор материала, инженер Willem Berroubache, разбирает архитектуру, которую в течение года обкатывали на боевых операциях крупного телеком-оператора уровня Tier-1. Платформа параллельно следит за 10-20 сетевыми функциями 5G core и, по данным InfoQ, уже автономно сгенерировала более 80 правил детектирования, которые раньше просто не были бы написаны. Ключевая мысль довольно неприятна для любителей красивых демо: зрелый SOC тормозит не на разборе алертов, а на detection engineering, где люди физически не успевают переводить новые паттерны атак в рабочие правила.
Из этого автор делает практичный вывод: ставить в центр один большой LLM для телеметрии, контекста и команд оператора плохая идея. Причин три. Во-первых, окно контекста все еще слишком мало для реального потока событий в телекоме. Во-вторых, недетерминированность модели плохо сочетается с действиями, которые могут изолировать кусок продакшн-инфраструктуры. В-третьих, одно неудачное редактирование промпта меняет поведение всей системы, а для change management это почти подарок в стиле "попробуйте потом объяснить аудитору". Не меньше достается и другому популярному сценарию: когда к классическому SIEM/SOAR просто прикручивают LLM-ассистента для пересказа алертов и черновиков плейбуков. Польза для аналитиков есть, но скорость покрытия новых угроз все равно упирается в ручную работу по написанию правил.
Вместо этого предлагается мультиагентный SOC из узких специализированных ролей. Один агент занимается триажем и решает, что действительно выглядит новым; второй синтезирует правила детекта; третий предлагает меры реагирования; четвертый собирает контекст из инвентаря, топологии и истории инцидентов; пятый, привилегированный reviewer, проверяет, можно ли вообще что-то делать дальше. Для координации между агентами используется протокол A2A. В статье напоминают, что Google открыл A2A в апреле 2025 года, а уже в июне 2025-го протокол передали в Linux Foundation. Для доступа к окружению применяется MCP: через него агенты ходят за инвентарем, текущей конфигурацией, топологией и историей событий. Этот протокол Anthropic передала в Linux Foundation Agentic AI Foundation в декабре 2025 года. Ставка здесь не на модный фреймворк, а на то, что открытые протоколы живут дольше любого очередного SDK.
Есть еще одна деталь, без которой вся конструкция превращается в рискованный стендап-проект. Автор настаивает: все дорогие LLM-вызовы должны быть спрятаны за классическим anomaly detection. В описанной схеме легкий Isolation Forest фильтрует сырой поток телеметрии и пропускает дальше только действительно нетипичные образцы. Это снижает стоимость инференса и делает задержки предсказуемыми. Проще говоря, языковая модель не должна тратить токены на то, что и так прекрасно отбрасывается статистикой. Для инженерных команд это, пожалуй, один из самых здравых тезисов статьи: ИИ здесь не замена базовой математике, а дорогой слой для тех случаев, где человек раньше реально тратил время на интерпретацию нового сигнала.
Самый жесткий слой архитектуры не в LLM вообще, а в policy-as-code. Reviewer-агент не принимает решение "по ощущениям" из промпта, а обращается к отдельному детерминированному policy-слою на OPA. Там формализованы предел blast radius, пороги confidence, требования к обратимости действий и список критичных элементов, которые всегда уходят на эскалацию человеку. Если действие связано с изменением конфигурации и reviewer не может однозначно подтвердить его корректность, запрос отклоняется автоматически. Поверх этого работает Kyverno, который уже на уровне Kubernetes admission может отдельно зарубить манифест, даже если reviewer сказал "да". В статье приводятся примеры простых, но полезных ограничений: запрет на деплой образов не из доверенного внутреннего реестра и блокировка слишком широких NetworkPolicy, которые лечат симптом за счет снятия сетевой границы. Для тех, кто строит agentic-системы в regulated environments, это, пожалуй, центральная мысль: безопасность должна жить не в красивом промпте, а в версионируемом коде и проверяемых порогах.
Не менее показательно устроен human-in-the-loop. У каждого значимого решения есть только три финальных состояния: выполнить автоматически, отклонить автоматически или эскалировать SOC-аналитику вместе со всей цепочкой рассуждений. Эскалация срабатывает, если confidence reviewer падает ниже порога, если актив входит в список always-escalate или если предполагаемый blast radius слишком велик. Это звучит менее эффектно, чем рассказы про полностью автономный SOC, зато больше похоже на систему, которую кто-то действительно собирается держать в продакшне, а не показывать на конференции.
Для разработчиков, архитекторов и CISO здесь есть вполне прикладной вывод. Если ваша команда уже смотрит в сторону агентных систем для безопасности, метрикой успеха будет не число сгенерированных summaries и не скорость ответа чат-бота аналитикам. Правильная метрика, как формулирует автор, это время между появлением нового класса угрозы "в дикой природе" и моментом, когда у SOC уже развернут рабочий детект. На этой дистанции и выяснится, что устойчивее: монолитный LLM, который знает все понемногу, или связка из узких агентов, аномалийного фильтра, OPA, Kyverno и обязательной человеческой эскалации. Похоже, следующая конкуренция в SOC пойдет не за самый разговорчивый интерфейс, а за самую короткую дорогу от новой атаки до нового правила.