22 июля Google Cloud выпустила blueprint по теме безопасности ИИ-нагрузок в Google Kubernetes Engine. Для команд, которые уже вытащили генеративные сервисы из песочницы в прод, это не очередной PDF про best practices, а довольно прямой сигнал: старой контейнерной безопасности для ИИ уже не хватает, и закрывать дыры придется на уровне инфраструктуры, моделей и самого приложения.
Документ адресован CISO и platform engineering-командам, сообщает InfoQ. Его авторами названы Glen Messenger, group product manager в команде безопасности GKE, и Shannon Kularathna. Главная мысль у Google простая: в продакшене нужно одновременно защищать проприетарные веса моделей, ловить новые прикладные атаки вроде prompt injection и удерживать требования комплаенса, не превращая жизнь AI-разработчиков в бюрократический квест.
В основе blueprint лежит трехслойная схема. Первый слой — инфраструктура. Здесь Google делает ставку на Confidential GKE Nodes: это режим, который расширяет аппаратное шифрование памяти на ускорители, включая Nvidia H100 GPU и TPU. Логика понятна: если компания гоняет чувствительные ИИ-нагрузки в Kubernetes, ей мало просто изолировать контейнеры. Нужна защита на уровне узлов, памяти и доступа к данным. В ту же корзину Google кладет Workload Identity Federation, чтобы inference-поды забирали веса моделей из Cloud Storage без долгоживущих ключей, и VPC Service Controls, чтобы строить периметр вокруг регулируемых данных. Формулировка у команды GKE жесткая: безопасной ИИ-нагрузки не бывает на небезопасном кластере.
Второй слой — целостность модели. Здесь Google указывает на проблему, которую многие пока предпочитают не замечать: классический software bill of materials плохо описывает ИИ-стек. Обычный SBOM может перечислить библиотеки и пакеты, но не отвечает на вопрос, откуда взялись датасеты, какие артефакты использовались в пайплайне и чем именно собрана модель. Для этого в blueprint появляется k8s-aibom — open source controller для Kubernetes, который автоматически генерирует AI bill of materials. Идея не выглядит декоративной. Если у компании несколько моделей, разные команды и жесткие требования аудита, без нормального учета датасетов, фреймворков и зависимостей любая проверка быстро превращается в археологию по CI-логам и внутренним wiki.
Третий слой — безопасность приложения, и здесь начинается самое интересное для тех, кто строит агентные системы и LLM-сервисы поверх существующей платформы. Google предлагает использовать Model Armor для проверки промптов и ответов на попытки инъекций, утечки чувствительных данных и вредоносный контент. А для ИИ-агентов, которые исполняют сгенерированный код или ходят во внешние инструменты, рекомендует GKE Sandbox на базе gVisor. Это уже важная поправка к старому тезису «Kubernetes все изолирует сам». Оркестратор умеет разруливать контейнеры, политики и сеть, но сам по себе не понимает, должен ли агент выполнять конкретный prompt и не утекает ли в ответе лишнее. Именно на этом уровне и появляется разрыв между привычной cloud security и реальными рисками генеративных приложений.
Google отдельно описывает и путь внедрения: три стадии Deploy, Operate и Govern. На первой речь идет о базовом наборе — включить Workload Identity и вынести чувствительные нагрузки на Confidential Nodes. На второй — уже про продакшен-харднинг: политики для подписанных образов и агрегацию логов. На третьей — про организационные guardrails и автоматизированное реагирование на инциденты. В этом месте хорошо видно, как рынок перестает продавать ИИ-безопасность как набор точечных фич. Облака начинают упаковывать существующие сервисы идентификации, мониторинга и изоляции в отдельные operating models именно для AI-workloads. SecurityBrief, на которое ссылается InfoQ, прямо так и трактует этот релиз: провайдеры переоформляют знакомую инфраструктуру в ИИ-специфичные схемы эксплуатации.
И Google здесь явно не первая. AWS продвигает похожую многослойную рамку через AWS AI Security Framework и дополняет ее open source-инициативой AI on EKS с Terraform-blueprints для развертывания ИИ-нагрузок в своем managed Kubernetes. Еще раньше Amazon расширила GuardDuty на EKS-кластеры, добавив обнаружение угроз вроде кражи учетных данных и reverse shell на уровне data plane через managed eBPF agent. Но одновременно звучит и критика такого подхода. Вендор ARMO в гайде по защите AI-агентов на EKS пишет, что нативные AWS-инструменты хорошо закрывают идентификацию, шифрование и логи control plane, но слабо видят то, что происходит внутри контейнера во время работы агента. И это, пожалуй, главный спор нового рынка: достаточно ли облачным платформам доупаковать старые средства безопасности, или для агентных сценариев нужны новые runtime-механизмы наблюдения и контроля поведения.
На этом фоне подход Microsoft выглядит немного с другого угла. В серии Agent Factory компания делает акцент не столько на контейнерной подложке, сколько на идентичности и поведении самих агентов. Через Microsoft Entra Agent ID агентам выдают собственные ограниченные и короткоживущие credentials, а инструмент PyRIT используют для автоматизированного red teaming до релиза. В сочетании с выводом CNCF, о котором InfoQ писала весной 2026 года, картина складывается довольно трезвая: RBAC, network policies и шифрование никуда не деваются, но для безопасности ИИ-нагрузок их уже недостаточно. Платформенным командам придется думать не только о том, кто куда может сходить, но и о том, нормально ли конкретный агент ведет себя в рантайме.
Для русскоязычной IT-аудитории это важнее, чем может показаться по заголовку про очередной blueprint. Когда hyperscalers начинают собирать отдельные схемы защиты под ИИ, это обычно означает, что рынок перестал считать AI-workloads экзотикой и готовится к массовой промышленной эксплуатации. Следующий логичный вопрос уже не в том, появятся ли у всех крупных облаков свои security framework для ИИ, а в том, кто первым предложит внятный стандарт, который одинаково хорошо переживет и GPU-кластеры, и агентные приложения, и неизбежные разбирательства с аудиторами.