15 сентября The New Stack проведет закрытый круглый стол для 20-25 security-лидеров о том, насколько далеко можно пускать ИИ-агентов в центр операций безопасности. Главная тема — автономия SOC: агент уже может расследовать подозрительный логин, но вопрос в том, стоит ли разрешать ему блокировать учетку, изолировать endpoint или менять сетевые правила. Для русскоязычных IT-команд это не абстрактная дискуссия про будущее, а вполне практичный разговор о том, кто будет отвечать за ошибочное действие машины в продакшене.
О мероприятии сообщает The New Stack. В обсуждении заявлены Jami Hughes, заместитель CISO в Zions Bancorporation, и Oren Saban, сооснователь и CPO Mate Security, ранее работавший продуктовым лидом Microsoft Defender XDR и Security Copilot. Формат тоже показателен: не вебинар на сотни молчаливых слушателей, а небольшая группа, где участники должны говорить о реальных ограничениях, провалах и зонах риска. Для откровенности организаторы применят правило Chatham House: идеи можно пересказывать, но без привязки к конкретным людям.
Повод для разговора понятен любому, кто видел очередь алертов в SIEM или EDR после шумного дня. SOC годами живут в режиме перегруза: сигналов много, времени мало, часть событий оказывается мусором, часть требует ручной корреляции по логам, endpoint-данным, IAM, сетевым событиям и тикетам. ИИ-агенты обещают взять на себя именно эту рутину: собрать контекст из разных систем, проверить подозрительную активность, предложить следующее действие и оставить человека в контуре принятия решения.
Пока это звучит как логичная автоматизация. Разница начинается там, где агенту дают не только читать и советовать, но и действовать. Проверить странный вход в аккаунт — одна степень риска. Отключить этот аккаунт — уже другая, особенно если это сервисная учетная запись, на которой держится часть бизнес-процесса. То же самое с изоляцией рабочей станции, блокировкой трафика или изменением политики доступа. Быстрая реакция хороша ровно до момента, когда она кладет нужный сервис быстрее, чем злоумышленник успел бы навредить.
Автономия SOC упирается не в магическое качество модели, а в управление полномочиями. CISO нужно понимать, что агент сделал, на каких данных, с какой уверенностью, кто подтвердил действие и можно ли все быстро откатить. В зрелой схеме у агента должны быть жесткие границы: одни операции он выполняет сам, другие — только после подтверждения аналитика, третьи ему вообще недоступны. И обязательно нужна аварийная кнопка, потому что агент, который действует на скорости машины, способен ошибаться тоже на скорости машины.
Для разработчиков и платформенных команд здесь есть отдельный слой работы. SOC-агенты не живут в вакууме: им нужны интеграции с журналами, IAM, EDR, SOAR, облачными API, CMDB и внутренними сервисами. Значит, придется проектировать права доступа, аудит, идемпотентность операций, безопасный откат и тестовые контуры для сценариев реагирования. Если агент может заблокировать сетевой маршрут или отключить пользователя, это уже не просто чат-бот с красивым интерфейсом, а участник production-процесса.
Меняется и роль аналитика SOC. Если ИИ берет на себя первичный сбор фактов и часть типовых расследований, человек меньше работает диспетчером очереди и больше занимается проверкой гипотез, threat hunting, настройкой правил и надзором за агентами. Это звучит солиднее, чем бесконечное закрытие ложных срабатываний, но есть неприятная деталь: навык расследования нельзя полностью отдать машине, иначе команда постепенно теряет способность понять, почему агент ошибся.
Вендоры уже добавляют агентские функции в security-продукты, и это несет знакомый риск: вместо единой непрерывной системы защиты компании могут получить еще один слой инструментов, которые нужно связывать, настраивать и объяснять аудиторам. Обещание красиво: непрерывное обнаружение и реагирование, где выводы из одного расследования сразу улучшают следующее. Реальность обычно прозаичнее: разные агенты, разные политики доступа, разные журналы действий и очередная панель, которую кто-то должен смотреть в три часа ночи.
Для бизнеса главный вывод простой: автономия SOC не включается флажком в консоли поставщика. Ее придется описывать как операционную модель: какие действия допустимы без человека, где требуется подтверждение, как измеряется качество решений, кто владелец риска и как быстро откатывается плохая реакция. Компании, которые ответят на эти вопросы раньше закупки, получат ускорение расследований. Остальные рискуют автоматизировать хаос — теперь с более дорогим интерфейсом.
Следующий этап в кибербезопасности, похоже, будет не спором «ИИ против аналитиков», а куда более скучным и важным спором о полномочиях. Атакующие уже используют автоматизацию, защитникам придется отвечать быстрее; вопрос только в том, станет ли автономия SOC управляемым инструментом или еще одним источником инцидентов, которые потом придется расследовать тем же людям.