Теневой ИИ в CI-CD: моделирование угроз на пути от ноутбука разработчика до Kubernetes

Искусственный интеллект ^[1] становится частью повседневной поставки ПО — часто ещё до того, как становится частью архитектуры безопасности. У этого разрыва есть имя: теневой ИИ^{1 [2]}. Это любой ИИ-инструмент, модель, агент, расширение или интеграция, которые используются в жизненном цикле ПО без формального одобрения, владельца, оценки риска или мониторинга.

Для платформенных команд и команд ИБ теневой ИИ на самом деле не проблема «разработчики пользуются чат-ботом». Это проблема доступа. Неконтролируемый ИИ может добраться до исходного кода, секретов, данных клиентов, облачных окружений и процессов развёртывания. Как только ИИ-системе разрешают вызывать инструменты и совершать действия, она перестаёт быть просто ПО для продуктивности. Она становится новой машинной идентичностью — с правами доступа, радиусом поражения (blast radius) и местом в вашей модели угроз.

Команда VK Cloud ^[3] перевела статью, где авторы моделируют угрозы для типичного cloud-native пути поставки — от ноутбука разработчика до рабочей нагрузки, запущенной в Pod Kubernetes. Каждому этапу они сопоставляют меры контроля, которые можно внедрить уже сегодня с помощью проектов CNCF и решений с открытым исходным кодом.

От советов к действиям

Риск резко возрастает, когда ИИ перестаёт давать советы и начинает действовать.

Ассистент, который предлагает фрагмент кода, создаёт один класс риска: утечку данных за пределы одобренной границы или малозаметно ошибочную рекомендацию, которой доверяют без проверки. Агент с Git-токеном, облачными учётными данными или ServiceAccount Kubernetes создаёт совершенно другой класс риска. Он может создавать, изменять или удалять ресурсы со скоростью машины. Kubernetes при этом не отличит вредоносное действие, совершённое атакующим, от того же действия, совершённого чрезмерно привилегированной идентичностью автоматизации.

Поэтому вопросы, на которые стоит ответить, — операционные, а не философские:

• Какие ИИ-инструменты и агенты используются?

• Какие данные они получают?

• До каких систем они могут добраться и с какими правами?

• Кто отвечает за поведение ^[4] каждого агента?

• Можно ли немедленно отозвать доступ, если агент ведёт себя неправильно?

Работоспособная модель даёт каждому агенту владельца-человека, регистрирует его как идентифицируемую рабочую нагрузку, ограничивает принципом минимальных привилегий и отслеживает, что он на самом деле делает.

Путь поставки

Рассмотрим типичный cloud-native путь поставки:

Теневой ИИ может появиться на любом этапе, а небольшое решение ради удобства, принятое в начале пути, к его концу способно обернуться угрозой для production.

Модель угроз

Модель угроз не требует предсказывать — ей нужно тлько назвать ценные активы, вероятные пути злоупотребления и меры контроля, ограничивающие ущерб.

Активы, которые нужно защищать:

• Исходный код и проприетарные алгоритмы

• API-ключи, токены, сертификаты и другие секреты

• Данные клиентов, сотрудников и коммерческие данные

• Конфигурация CI/CD и ключи подписи ПО

• Облачные и Kubernetes-идентичности

• Образы контейнеров и целостность цепочки поставок ПО

• Доступность production и репутация

Источники угроз

Теневой ИИ редко начинается со злонамеренного инсайдера. Чаще инженер с благими намерениями внедряет инструмент, чтобы работать быстрее, а атакующие эксплуатируют возникшую слепую зону. К значимым источникам угроз относятся:

• Внешние атакующие, нацеленные на открытые ИИ-интеграции или похищенные учётные данные

• Злонамеренные инсайдеры, злоупотребляющие слабо контролируемым доступом

• Скомпрометированные сторонние провайдеры или провайдеры ИИ-инструментов

• Атакующие, использующие prompt injection для манипуляции агентом

• Легитимный агент, действующий некорректно из-за неоднозначных инструкций, небезопасного контекста или избыточных прав

Prompt injection — сквозная тема. Агенты регулярно читают недоверенный контент: описания issue, README, changelog зависимостей, логи сборки. Любой из них может подтолкнуть агента к раскрытию данных или к небезопасному действию, поэтому одной только фильтрации промптов никогда не будет достаточно. Настоящий ответ — эшелонированная защита. Рекомендации OWASP по ИИ-агентам и LLM-приложениям — хорошая база для этих сценариев отказа.

Пути атаки по этапам и меры контроля, которые их блокируют

1. Ноутбук разработчика

Разработчик устанавливает ИИ-расширение для кода или вставляет лог ошибки ^[6] в публичный сервис. В этом логе — API-токен, внутреннее имя хоста или идентификатор клиента. Организация теперь не видит, куда ушли проприетарные данные и как долго они могут храниться. Следом идёт второй риск: ассистент предлагает зависимость или команду, которым разработчик доверяет без проверки.

Защитная мера. Предоставьте одобренные ИИ-инструменты, чтобы их использование было видимым, а не скрытым: полный запрет обычно только загоняет использование глубже в тень. Подкрепите это сканированием секретов на этапе pre-commit, подключённым как git-хук — например, через gitleaks, — чтобы токены вообще не попадали в общее пространство, и обязательным требованием подписанных коммитов. С Gitsign (часть проекта Sigstore) разработчики подписывают коммиты недолговечными сертификатами на основе идентичности, а не долгоживущими GPG-ключами. Это делает вопрос «кто внёс это изменение» проверяемым — в том числе если автор изменения агент.

Там, где агенту действительно нужно автономно выполнять команды, изолируйте его, а не доверяйте ему. Стоит разобраться с механизмом одноразового рабочего пространства, изолированного на уровне ВМ: агент получает собственное ядро и файловую систему, а SSH-ключи хоста, файлы облачных учётных данных и другие чекауты репозиториев внутри него просто отсутствуют. Если агента манипуляциями заставляют сделать что-то деструктивное, вы выбрасываете это окружение — и ущерб на этом заканчивается.

Таких реализаций много, есть и open source, и коммерческие — от инструментов для разработчиков, которые сводят это к одной команде, до microVM и рантаймов с перехватом системных вызовов, на которых они построены (таблица инструментов далее в статье называет open source варианты). Важнее свойство, чем конкретный продукт: агент, работающий с широкой автономией, не должен запускаться прямо на машине, которая хранит ваши учётные данные.

2. Система контроля версий

Неодобренный ИИ-бот подключён к вашему Git-хосту с широкими правами. Он может читать любой репозиторий, комментировать pull request, создавать ветки или пушить код. Угроза не только в утечке: если токен интеграции украден или бота манипуляциями заставляют читать вредоносное issue или описание PR, он может внести небезопасные изменения или раскрыть содержимое репозитория.

Защитная мера. Дайте каждой ИИ-интеграции именованного владельца, собственную идентичность, минимальную область доступа к репозиториям и недолговечные учётные данные. Агент, который ревьюит код для одной команды, не должен иметь доступ ко всем репозиториям организации. Требуйте гейты ревью и provenance для всего, что вливается в основную ветку, и относитесь к PR, написанным агентом, как к любому другому недоверенному контрибьютору: обязательное ревью человеком, без самоодобрения.

3. CI-конвейер

Системы CI хранят одни из самых мощных учётных данных, которые у вас есть: токены системы контроля версий, учётные данные реестра, облачные ключи и ключи подписи. ИИ-возможность теневого происхождения, которая анализирует логи сборки, генерирует скрипты или автономно «чинит» падающую сборку, становится неконтролируемым привилегированным оператором. Полезная нагрузка prompt injection, спрятанная в исходном коде, README или логе сборки, может изменить её поведение ^[7].

Защитная мера. Не допускайте попадания долгоживущих секретов в промпты, логи и окружения сборки. Запускайте связанные с ИИ job в изолированных окружениях с узко ограниченными временными учётными данными и требуйте проверки политик, прежде чем любой конвейер сможет изменить инфраструктуру или выпустить ПО. В Kubernetes-native CI admission-политика — жёсткий гейт, который агент не сможет обойти уговорами. Правило Kyverno или OPA/Gatekeeper, отклоняющее неподписанные образы, например, срабатывает независимо от того, что пытается протолкнуть скомпрометированный job конвейера.

4. Реестр артефактов и цепочка поставок

Код, сгенерированный ИИ, может подтягивать небезопасные пакеты, слабые конфигурации или зависимости, которые никто не проверял. Ассистент может порекомендовать базовый образ или скопировать фрагмент кода, не проверив provenance, лицензирование, уязвимости или статус поддержки. Если вы не можете установить, что вошло в образ, кто его одобрил и прошёл ли он через гейт, быстрая поставка — это просто неуправляемый риск.

Защитная мера. Требуйте сканирование образов, генерацию SBOM, подписанные артефакты и гейты продвижения, и предъявляйте к коду, сгенерированному ИИ, те же требования к ревью и релизу, что и к коду, написанному человеком. Практическая цепочка на open source выглядит так:

• Trivy или Grype — сканировать образы и IaC на известные уязвимости.

• Syft — генерировать SBOM для каждого артефакта.

• Cosign (Sigstore) — подписывать образы и прикреплять аттестации.

• in-toto — фиксировать подписанные аттестации для каждого шага конвейера, это основа provenance в стиле SLSA.

• Notation (Notary Project) — проверять подписи на границе реестра, чтобы потребитель мог проверить артефакт независимо от конвейера, который его создал.

5. Непрерывная поставка

ИИ-агент для релизов может редактировать Helm-чарты, обновлять GitOps-манифесты, менять цели развёртывания, одобрять релизы или запускать откат. Подключённый к production без границ, он может обойти именно те механизмы управления изменениями, на которые опирается зрелый процесс.

Защитная мера. Проведите чёткую границу между агентом, который рекомендует релизное действие, и агентом, который его выполняет. Действия с высоким уровнем влияния должны находиться за явными гейтами одобрения с надёжным аудиторским следом: развёртывание в production, повышение привилегий, экспорт данных, удаление, изменения сетевых политик. В модели GitOps гейтом одобрения служит pull request: агент предлагает изменение манифеста, человек одобряет merge, а контроллер GitOps (Argo CD или Flux) согласовывает состояние. Ни один из контроллеров не принимает инструкции от агента — он лишь применяет то, что уже влито. Проследите, чтобы в production не было пути, который обходит этот гейт.

6. Kubernetes runtime

Этот этап часто самый значимый по последствиям. Агент для устранения инцидентов получает cluster-admin «временно», чтобы разобраться с алертом, — и инструмент для удобства превращается в высокоценную цель. Скомпрометированный или манипулируемый агент с широкими правами может перечислить секреты, развернуть вредоносную рабочую нагрузку, изменить сетевые политики или эксфильтровать данные.

Защитная мера. Границы namespace, workload identity, минимальный RBAC, admission control, runtime-детекция и сегментация сети. Конкретно:

• SPIFFE/SPIRE — даёт каждой рабочей нагрузке (включая агентов) криптографическую идентичность вместо общего долгоживущего токена.

• RBAC по принципу минимальных привилегий, ограниченный namespace и набором глаголов — никогда cluster-admin.

• Falco или Tetragon (eBPF-компонент Cilium) — для runtime-детекции поведения, которое следует за компрометацией: shell в контейнере, неожиданные чтения секретов, исходящие соединения.

• Network Policy — для сегментации east-west трафика и сдерживания lateral movement.

Например, агенту, единственная задача которого — перезапускать Deployment, нужна Role в рамках namespace, а не кластерная. Она должна быть привязана к одному namespace, ограничена группой API apps и ресурсом deployments и давать только get, list и patch (рестарт rollout — patch, поэтому create и delete никогда не нужны). Это совершенно другой уровень по сравнению с cluster-admin: даже если агент полностью попадёт под чужой контроль, он не сможет читать секреты, трогать другие namespace или удалять рабочие нагрузки.

Меры контроля, которые масштабируются

Здесь смысл не в том, чтобы замедлить внедрение ИИ, а в том, чтобы сделать его использование видимым, подотчётным и соразмерным его риску.

Соберите инвентарь ИИ

Ведите живой инвентарь одобренных и обнаруженных ИИ-инструментов, моделей, расширений, ассистентов для кода, агентов, API-интеграций и MCP-серверов. У каждой записи должен быть бизнес-владелец и технический владелец, назначение и пользователи, классификация данных, к которым ей разрешено обращаться. Ещё — системы, к которым она подключена, и с какими правами, модель или провайдер за ней, признак использования в production, дата последнего ревью и способ отозвать доступ. Нельзя управлять тем, чего не видишь, а каждая другая мера контроля из этого списка предполагает, что инвентарь уже есть.

Относитесь к ИИ-агентам как к идентичностям

У каждого агента должна быть уникальная идентичность. Он никогда не должен использовать личные учётные данные разработчика или общую учётную запись администратора. Минимальные привилегии по умолчанию означают:

• Отдельные учётные данные для каждого окружения

• Недолговечные токены, а не постоянные секреты

• Доступ только для чтения там, где это возможно

• Права Kubernetes, ограниченные namespace

• Явные allowlist для API, инструментов, репозиториев и MCP-серверов

• Немедленный отзыв доступа

Внутри кластера с этой задачей уже справляются SPIFFE/SPIRE и cert-manager. За пределами кластера, где агент общается с Git-хостом, реестром или тикет-системой, а не с Kubernetes API, обычным якорем для таких сервисных идентичностей служит Keycloak.

Соразмеряйте меру контроля с радиусом поражения

Не каждая функция ИИ требует одинакового подхода:

Применяйте эшелонированную защиту

Если фильтрация промптов — лишь один слой, остальные должны нести реальную нагрузку. Зрелая архитектура сочетает governance, управление идентичностью и доступом, защиту системы контроля версий, управление секретами, защищённый CI/CD, сканирование зависимостей и контейнеров, admission- и runtime-политику Kubernetes, сетевой контроль и централизованное логирование. Проверка простая: если откажет любая отдельная мера контроля, агент всё равно не должен получить возможность нанести существенный ущерб.

Инструменты по областям (CNCF и open source)

Ни один отдельный проект не решает проблему теневого ИИ целиком. Выбирайте инструменты по той области риска, которую нужно улучшить, а затем встраивайте их в единую архитектуру. Уровни зрелости ниже отражают состояние CNCF Landscape на момент написания статьи.

Две оговорки насчёт правого столбца. Во-первых, open source — не то же самое, что управляется фондом. Несколько из этих пунктов проекты одного вендора с open source-ядром и платной редакцией: Calico от Tigera, Tracee от Aqua, TruffleHog от Truffle Security, ToolHive от Stacklok, Teleport от Gravitational. Это законные варианты выбора, но проверьте, что нужная вам возможность действительно входит в бесплатную редакцию.

Во-вторых, прочитайте лицензию, прежде чем встраивать или распространять компонент. gitleaks — MIT; Tracee, Polaris, Calico и ToolHive — Apache-2.0. TruffleHog, Zitadel и community-редакция Teleport — AGPL-3.0, что накладывает обязательство раскрыть исходный код, если вы предлагаете изменённую версию как сетевой сервис.

Пробелы заслуживают такой же прямоты. Слои конвейера и runtime хорошо покрыты зрелыми проектами CNCF. С governance ИИ ситуация слабее: проверка промптов, обнаружение агентов, политика вызова инструментов. Ни один проект уровня graduated не закрывает эту область целиком, а те, что нацелены прямо на неё, ещё молоды — хотя слой gateway заметно продвинулся в течение 2026 года.

Прежде чем писать собственный прокси, стоит знать четыре проекта:

• kagent (CNCF Sandbox, принят в мае 2025 года) — фреймворк для сборки и запуска агентов в Kubernetes, который как минимум помещает рабочие нагрузки агентов под ту же декларативную модель, что и всё остальное в кластере.

• Envoy AI Gateway (Apache-2.0) достиг версии v1.0 в июне 2026 года, с вкладом от Bloomberg, Nutanix, Tetrate и сообщества Envoy. Он использует двухуровневый паттерн: внешний gateway — для аутентификации и глобального rate limiting, внутренний — для тонкого контроля над self-hosted эндпойнтами моделей, плюс маршрутизация MCP-трафика. Это вариант с самой сильной cloud-native родословной, поскольку он расширяет Envoy Gateway, а не строится с нуля.

• agentgateway (Linux Foundation) — policy-прокси для трафика MCP и Agent2Agent. Он терминирует вызовы agent-to-tool и agent-to-model. Также применяет аутентификацию через JWT, API-ключ или OAuth, ролевую авторизацию через движок политик CEL, фильтрацию контента, rate limiting и трассировку OpenTelemetry. Архитектурно это та контрольная точка, на которую опираются приведённые выше советы про allowlisting и минимальные привилегии.

• agentregistry напрямую решает проблему инвентаря: каталогизирует MCP-серверы, агентов и skills, а также сканирует подключённые runtime, чтобы выявить то, что никогда не было зарегистрировано. Его подали в CNCF Sandbox в марте 2026 года, но заявка всё ещё на рассмотрении, поэтому оценивайте его как проект на ранней стадии, а не как управляемый CNCF.

Для инвентаря может вообще не понадобиться новый инструмент. Backstage уже моделирует владение, и его каталог может хранить агентов и MCP-серверы как полноценные компоненты с именованным владельцем. А GenAI semantic conventions в OpenTelemetry дают стандартную форму для трейсов, фиксирующих, какой инструмент агент реально вызвал.

У одного слоя до сих пор нет решения, управляемого фондом: сканирование MCP-серверов на tool poisoning и полезные нагрузки prompt injection. Инструменты есть, но поддерживаемые варианты разработаны вендорами, так что относитесь к этому как к оценочному эксперименту, а не как к устоявшемуся выбору. Пока эта область не созреет, прагматичная позиция не меняется. Сочетайте рекомендации OWASP с policy enforcement point перед эндпойнтами моделей и инструментов, а затем опирайтесь на описанные выше меры контроля идентичности и admission, чтобы ограничить действия агента — даже если вы не можете полностью проверить, о чём он «думает».

Как бы вы это ни собрали, у каждого из этих проектов всё равно должен быть владелец. Кто-то должен поддерживать политики, разбирать находки по приоритету, следить за работоспособностью интеграций и доказывать, что меры контроля действительно делают то, что заявлено на архитектурной диаграмме.

Заключение

Теневой ИИ — следующая эволюция ^[10] теневых ИТ, с одним критическим отличием: современные ИИ-агенты умеют интерпретировать информацию, вызывать инструменты и действовать в инженерных системах. Это делает их мощными ускорителями и потенциальными скоростными путями к утечке исходного кода, компрометации учётных данных, злоупотреблению цепочкой поставок и нарушению работы production.

Вопрос не в том, будут ли ваши разработчики пользоваться ИИ. Они уже пользуются. Вопрос в том, будете ли вы управлять ИИ как неучтённой грудой инструментов для продуктивности или как контролируемым набором идентичностей, потоков данных и рабочих нагрузок, готовых к production.

Путь вперёд конкретен, и большая часть его уже закрыта cloud-native open source. Нужно обнаружить использование ИИ, назначить владельцев, ограничить права через реальный workload identity, защитить цепочку поставок подписью и provenance, обеспечить границы Kubernetes через admission- и runtime-политику, сегментировать сеть, отслеживать поведение и держать человека в контуре для действий с серьёзными последствиями. Пусть агенты помогают командам работать быстрее, но никогда не позволяйте им действовать за пределами вашей способности видеть их, контролировать и останавливать.