Google Cloud на конференции Next ’26 описал новую архитектуру корпоративной безопасности. Периметр защиты расширяется: теперь в него входят не только пользователи, облака, приложения и данные, но и ИИ-агенты, IDE-плагины, генераторы кода, MCP-серверы и вся цепочка разработки AI-решений.
Google и Wiz фактически формируют новую модель безопасности — для среды, где автономные агенты становятся частью инфраструктуры. Разберём ключевые изменения.
Главный сдвиг: от ИИ-помощников к агентам-защитникам
Ключевой термин — agentic defense, или агентная защита. Так называют модель безопасности, где ИИ-агенты не просто помогают аналитику, а сами ищут угрозы, анализируют события, предлагают гипотезы и запускают часть процессов реагирования.
Google говорит о трех новых типах агентов в Google Security Operations:
-
Threat Hunting — это проактивный поиск угроз, когда команда безопасности не ждет сигнала тревоги, а сама ищет следы возможной атаки.
-
Detection Engineering — разработка правил и логики для обнаружения атак.
-
Third-Party Context agent — добавление внешнего контекста к расследованиям.
По сути, такие системы берут на себя часть работы SOC — центра мониторинга и реагирования на киберинциденты. Они ищут скрытые паттерны атак, выявляют слабые места в покрытии, создают новые правила обнаружения и помогают быстрее принимать решения.
Для рынка это важный сигнал. SOC-инструменты постепенно движутся от формата “копилота для аналитика” к системам, которые способны самостоятельно инициировать расследование, проверять гипотезы и запускать действия реагирования. Google приводит показательный пример: Triage and Investigation agent обработал более 5 млн уведомлений о подозрительной активности за год и сократил типичный ручной анализ с 30 минут до 60 секунд.
Инсайт для рынка: конкуренция между SIEM, SOAR, XDR и MDR-провайдерами будет смещаться от простого сбора и корреляции событий к способности превращать SOC в полуавтономную систему реагирования.
Разработка детектов становится автоматизированной
Отдельный важный блок — автоматизация detection engineering. Сейчас создание правил обнаружения атак часто зависит от опыта отдельных инженеров. Один специалист анализирует угрозы, другой пишет правила для SIEM, Sigma или YARA, третий тестирует их и снижает количество ложных срабатываний.
Google описывает другой подход. Detection Engineering agent должен сам находить пробелы в покрытии защиты и создавать новые детекты под конкретные сценарии атак. Это означает переход от ручной работы к автоматизированному процессу, где система анализирует тактики, техники и процедуры атакующих, генерирует правила и проверяет, закрывают ли они реальные риски.
Роль инженера безопасности в такой модели меняется. Он становится не автором каждого правила вручную, а куратором системы, которая генерирует, валидирует и обновляет детекты на основе threat intelligence — данных о новых угрозах, инструментах и поведении атакующих.
Shadow AI становится новой корпоративной угрозой
Еще один важный акцент Google и Wiz — shadow AI, или теневой ИИ. Это несанкционированное использование AI-инструментов внутри компании. Раньше бизнес боролся с shadow IT: неутвержденными SaaS-сервисами, облаками, базами данных и приложениями. Теперь похожая проблема возникает вокруг ИИ.
Сотрудники могут использовать внешние модели, IDE-расширения, агентов для написания кода, AI-плагины и SaaS-инструменты без согласования со службой безопасности. Это создает новые риски: утечку кода, передачу чувствительных данных во внешние модели, появление непроверенных зависимостей и использование инструментов, которые компания не контролирует.
Wiz предлагает для этой задачи AI-BOM — AI Bill of Materials. Это перечень компонентов AI-системы: моделей, фреймворков, IDE-расширений, генераторов кода и других элементов, которые участвуют в создании AI-приложений. По смыслу AI-BOM похож на SBOM — Software Bill of Materials, который показывает, из каких библиотек и зависимостей состоит программный продукт.
Для индустрии это важный поворот. Компаниям придется учитывать не только то, какие библиотеки используются в коде, но и то, какой инструмент этот код создал, какой агент его изменил и какие модели участвовали в разработке.
AppSec смещается в IDE
Безопасность приложений тоже меняет место в процессе разработки. Классическая схема выглядела так: разработчик пишет код, делает коммит, затем код проходит CI/CD, SAST, DAST, SCA и ревью безопасности. В AI-native разработке такой цикл становится слишком медленным.
Код может быть сгенерирован агентом за секунды. Значит, проверка должна происходить в момент создания: в IDE, на уровне промпта и на уровне результата, который возвращает модель. Контролировать придется не только сам код, но и контекст из репозитория, секреты, зависимости и дальнейшие действия coding agent.
Инсайт: безопасность разработки будет встраиваться в CI/CD и в сам процесс общения человека или агента с моделью. Контролировать придется промпты, сгенерированный код, контекст из репозитория и секреты— пароли, токены и ключи доступа, зависимости и дальнейшие действия агента.
ИИ-агенты становятся субъектами доступа
Один из самых фундаментальных сдвигов — появление Agent Identity. Это цифровая идентичность для автономных агентов. Раньше IAM строился вокруг людей, сервисных аккаунтов, приложений и рабочих нагрузок. Теперь появляется новый класс участников — ИИ-агенты.
Агент может действовать автономно, обращаться к инструментам, вызывать API, работать с данными и принимать решения в рамках выданных полномочий. Значит, ему нужны отдельные правила доступа, ограничения, аудит и механизм отзыва прав.
Для CISO это создает новый набор вопросов. Какой агент имеет доступ к каким данным? Кто выдал ему полномочия? Какие действия он может выполнять? Как ограничить его область действия? Как логировать его решения? Как быстро отозвать доступ, если агент начинает вести себя неправильно?
Агентный трафик становится новой плоскостью контроля
Еще один элемент новой архитектуры — Agent Gateway. Это шлюз для контроля взаимодействий между агентами, инструментами, API и внешними сервисами. Он должен применять политики безопасности к коммуникациям agent-to-agent и agent-to-tool.
В этой логике MCP, или Model Context Protocol, становится важным элементом инфраструктуры. Он помогает моделям и агентам получать контекст и подключаться к инструментам. Agent2Agent описывает взаимодействие между автономными агентами.
Раньше gateway чаще защищал API, веб-трафик или сервисные взаимодействия. Теперь появляется отдельный слой для агентных коммуникаций. Он должен понимать, что агент делает, к какому инструменту обращается, какой контекст передает и не нарушает ли это политику.
В корпоративной среде трафик между агентами может стать таким же объектом контроля, как API-трафик в микросервисной архитектуре.
Runtime-защита моделей становится обязательной
Google также продвигает Model Armor — защиту моделей и агентов во время работы системы. Это важный сдвиг: безопасность AI нельзя ограничивать этапом разработки, тестирования или red teaming.
Runtime-защита должна предотвращать prompt injection, то есть атаки через специально подготовленные запросы к модели, tool poisoning — подмену или заражение инструментов, а также утечки чувствительных данных. Фактически контроль встраивается прямо в поток взаимодействия модели, агента и внешних инструментов.
Компании будут все чаще внедрять фильтрацию, очистку входных данных, применение политик и мониторинг в реальном времени.
Инсайт: LLM security становится постоянным процессом, а не разовой проверкой перед запуском.
Антифрод готовится к агентному вебу
Google Cloud Fraud Defense показывает, что изменения затрагивают не только корпоративную безопасность, но и антифрод. Платформа должна различать людей, ботов и ИИ-агентов.
Это особенно важно для финтеха, e-commerce и банков. В будущем транзакции, бронирования, покупки, заявки и обращения в поддержку смогут выполнять не только люди, но и легитимные агенты. Антифрод-системам придется понимать, кто действует в конкретный момент: человек, бот, разрешенный агент или вредоносная автоматизация.
Рынок переходит от простой логики bot detection к проверке легитимности цифрового исполнителя.
Браузер снова становится критической точкой безопасности
Google отдельно выделяет Chrome Enterprise: контроль расширений с учетом AI-рисков и отчетность по использованию теневого ИИ. Это логично: значительная часть работы с ИИ происходит через браузер. Сотрудники используют ChatGPT-подобные сервисы, SaaS-инструменты, расширения, веб-IDE и внутренние порталы.
Браузер становится точкой, где можно увидеть использование несанкционированных AI-приложений, подозрительную активность расширений и потенциальные утечки корпоративных данных. В результате browser security получает новое значение. Контроль расширений, SaaS-приложений и веб-инструментов с ИИ становится частью DLP и Zero Trust-архитектуры.
Инфраструктура остается частью AI security
Разговор о безопасности ИИ часто сводят к промпт-инъекциям, галлюцинациям и защите модели. Google показывает более широкий подход. В AI security входят защищенные вычисления, управление ключами, защита секретов, изоляция чувствительных данных и подготовка к постквантовой криптографии.
Это означает, что зрелая стратегия будет состоять из двух уровней. Первый — runtime-защита моделей и агентов. Второй — инфраструктурная защита данных, ключей и вычислений.
Что это значит для индустрии
Google Cloud и Wiz фактически описывают новую модель кибербезопасности. В ней SOC работает с ИИ-агентами, разработка детектов становится автоматизированной, AppSec начинается в IDE, AI-BOM фиксирует происхождение кода, а агентам выдаются собственные цифровые идентичности.
Главный вывод для CISO: зона ответственности резко расширяется. Защищать нужно людей, приложения, данные и автономные цифровые сущности, которые получают доступ к корпоративной инфраструктуре и начинают действовать от имени бизнеса.
