[Перевод] Shadow AI в CI/CD: почему ИИ-агенты становятся угрозой

Привет, сегодня решила поделиться переводом от Маттео Бизи на вечнозеленую (как оказалось) тему — Shadow AI. В материале про то, почему ИИ-агентов нужно моделировать как угрозу, а не просто как инструмент продуктивности.

Искусственный интеллект все чаще встраивается в процесс доставки ПО, причем происходит это быстрее, чем мы успеваем сформулировать соответствующие меры безопасности. 

Этот разрыв и называется Shadow AI («теневой ИИ»). Это любые ИИ-инструменты, модели, агенты, расширения или интеграции, которые используют в жизненном цикле разработки без формального согласования, ответственного владельца, оценки рисков и мониторинга.

Для платформенных и security-команд проблема Shadow AI — это вопрос доступа. Неподконтрольный ИИ может получить доступ к исходному коду, секретам, данным клиентов, облачным средам и пайплайнам деплоя. Как только ИИ-системе разрешают вызывать инструменты и совершать действия самостоятельно, она перестает быть просто инструментом для повышения продуктивности и становится новой нечеловеческой идентичностью с правами, зоной поражения и местом в вашей модели угроз.

В этой статье я смоделирую типичный путь доставки в cloud-native среде — от ноутбука разработчика до рабочей нагрузки в поде Kubernetes — и для каждого этапа покажу, какие контрмеры можно внедрить уже сегодня с помощью опенсорс проектов.

От рекомендаций к действиям

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

Ассистент, который предлагает фрагмент кода, создает один класс рисков: утечка данных за пределы одобренного периметра или незаметно ошибочное принятие предложения без какой-либо проверки. 

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

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

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

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

• К каким системам они имеют доступ и с какими правами?

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

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

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

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

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

Shadow AI может появиться на любом этапе, и изначально небольшое и удобное решение рискует в итоге превратиться в производственную уязвимость.

Модель угроз

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

Ресурсы для защиты

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

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

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

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

• Идентификаторы в облаке и Kubernetes

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

• Доступность продакшена

Субъекты угроз

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

Кто эти злоумышленники:

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

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

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

• Атакующие, которые используют промпт-инъекцию для манипуляции агентом.

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

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

Руководство OWASP по ИИ-агентам и LLM-приложениям — хорошая базовая линия для таких сценариев отказа.

Пути атак по этапам и контрмеры

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

Разработчик устанавливает ИИ-расширение для кода или вставляет лог ошибки в публичный сервис. 

Первый риск: в логе может оказаться API-токен, внутренний hostname или идентификатор клиента. Организация теряет видимость того, куда ушли проприетарные данные и как они могут храниться. 

Второй риск: ассистент предлагает зависимость или команду, которую разработчик принимает без проверки.

Контрмера

1. Предоставьте одобренные ИИ-инструменты, чтобы использование было видимым, а не скрытым. Полный запрет обычно лишь загоняет практику глубже в тень.

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

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

Реализаций много: от разработческих инструментов, сводящих все к одной команде, до microVM и runtime’ов с перехватом системных вызовов, на которых они построены (в таблице инструментов ниже названы опенсорс-проекты). 

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

2. Контроль версий

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

Угроза не только в утечке: если токен интеграции украден или ботом сманипулировали через злонамеренное описание задачи или PR, он может внести небезопасные изменения или раскрыть содержимое репозитория.

Контрмера

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

2. Требуйте контрольных точек и подтвержденного происхождения для всего, что попадает в основную ветку, и относитесь к PR от агентов как к любому другому недоверенному контрибьютору: обязательный человеческий ревью, без самоаппрува.

3. CI-пайплайн

CI-системы хранят одни из самых мощных учетных данных: токены контроля версий, учетные данные реестров, облачные ключи, ключи подписи. Shadow AI-возможность, которая просматривает логи сборки, генерирует скрипты или автономно «чинит» падающую сборку — это неуправляемый привилегированный оператор. Промпт-инъекция, спрятанная в исходниках, README или логе сборки, может изменить его поведение.

Контрмера

1. Держите долгоживущие секреты вне промптов, логов и сред сборки. 

2. Запускайте задачи, связанные с ИИ, в изолированных средах с жестко ограниченными временным учетными данными и требуйте проверок политик перед тем, как пайплайн сможет изменить инфраструктуру или выпустить ПО. 

В Kubernetes-нативном CI admission-политика — это жесткий барьер, через который агент не может пробиться: правило Kyverno или OPA/Gatekeeper, отклоняющее неподписанные образы, сработает независимо от того, что пытается запушить скомпрометированная задача пайплайна.

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

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

Если вы не понимаете, что вошло в образ, кто его одобрил и прошел ли он контрольную точку, быстрая доставка — это просто неуправляемый риск.

Контрмера

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

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

• Syft для генерации SBOM на каждый артефакт.

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

• in-toto для захвата подписанных аттестаций на каждый шаг пайплайна, основа provenance в стиле SLSA.

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

5. Continuous delivery

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

Контрмера

Проведите четкую границу между агентом, который рекомендует действие по релизу, и тем, который его выполняет. Действия с высоким уровнем влияния должны стоять за явными гейтами аппрува с сильным аудитом: 

• развертывание в продакшен;

• повышение привилегий; 

• экспорт данных, удаление;

• изменения сетевых политик. 

В GitOps-модели pull request и есть гейт аппрува: агент предлагает изменение манифеста, человек аппрувит мерж, а GitOps-контроллер (Argo CD или Flux) приводит кластер в соответствие. Ни один контроллер не принимает инструкции от агента. Он лишь применяет то, что уже замержено. Сделайте так, чтобы в продакшен нельзя было попасть, обойдя этот гейт.

6. Рантайм Kubernetes

Этот этап часто самый судьбоносный. Агент устранения инцидентов получает права администратора на время, чтобы разобраться с алертом, и в итоге удобный инструмент становится удобной мишенью. 

Скомпрометированный агент с широкими правами может перечислить секреты, развернуть вредоносную рабочую нагрузку, изменить сетевые политики или извлечь данные.

Контрмера

Границы неймспейсов, идентичность рабочих нагрузок, минимальный RBAC, admission-контроль, детекция на уровне рантайма и сегментация сети. 

А именно:

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

• Наименьшие привилегии RBAC, ограниченные неймспейсом и набором глаголов, без прав администратора.

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

• Сетевые политики для сегментации межсерверного трафика и ограничения горизонтального перемещения.

Например, если агент должен только перезапускать Deployment, ему достаточно роли в одном неймспейсе, а не прав на весь кластер. Такую роль привязывают к конкретному неймспейсу, дают доступ только к API-группе apps и ресурсу deployments, и разрешают лишь get, list и patch (перезапуск через rollout restart — это patch, поэтому права на create и delete вообще не нужны). 

Масштабируемые контрмеры

Все это не про то, чтобы замедлить внедрение ИИ. Цель — сделать использование ИИ видимым, подотчетным и пропорциональным его риску.

Создайте инвентарь ИИ

Ведите живой реестр одобренных и обнаруженных ИИ-инструментов, моделей, расширений, ассистентов для кода, агентов, API-интеграций и MCP-серверов. Для каждой записи нужны:

• бизнес- и технический владелец;

• назначение и пользователи;

• классификация данных, к которым разрешен доступ;

• подключаемые системы и их права;

• модель или провайдер;

• статус (продакшен или нет);

• дата последнего ревью и способ отзыва доступа. 

Нельзя управлять тем, чего нет или не видно. Все остальные контрмеры в этом списке предполагают, что этот инвентарь существует.

Рассматривайте ИИ-агентов как идентичности

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

Наименьшие привилегии по умолчанию — это:

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

• Короткоживущие токены, а не постоянные секреты.

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

• Права в Kubernetes, ограниченные неймспейсом.

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

• Немедленный отзыв.

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

Регулируйте контрмеру в соответствии с зоной поражения

Не каждой ИИ-функция нужен одинаковый уровень контроля:

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

Если фильтрация промптов — лишь один слой, остальные должны нести реальную нагрузку. Зрелая архитектура — это:

• управление и IAM;

• защита контроля версий;

• управление секретами;

• безопасный CI/CD;

• сканирование зависимостей и контейнеров;

• admission и runtime-политики Kubernetes;

• сетевые контроли и централизованное логирование. 

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

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

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

Уровни зрелости ниже отражают состояние CNCF Landscape на момент написания статьи.

Два замечания по правой колонке. 

Во-первых, опенсорс — не то же самое, что проект под управлением фонда. Некоторые из перечисленных — single-vendor проекты с опенсорс-ядром и платной версией. Например, 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, который накладывает обязательства по раскрытию исходников, если вы предлагаете модифицированную версию как сетевой сервис.

Пробелы тоже стоит назвать прямо. Уровень пайплайнов и рантайма уже хорошо закрыт зрелыми проектами CNCF. А вот управление самим ИИ пока слабее: инспекция промптов, обнаружение агентов, политики вызовов инструментов. Ни один проект со статусом Graduated не закрывает это пространство целиком, а те, что целенаправленно решают именно эти задачи, еще молоды, хотя слой гейтвеев за 2026 год заметно вырос.

Вот четыре проекта, которые стоит проверить, прежде чем писать свой прокси:

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

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

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

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

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

Один слой пока остается без «фондового» решения: сканирование MCP-серверов на отравление инструментов и промпт-инъекции. Инструменты есть, но зрелые, поддерживаемые варианты делают вендоры, так что это пока зона для оценки, а не готовый выбор. 

Пока этот слой не созреет, прагматичная стратегия прежняя: сочетайте рекомендации OWASP с политическим гейтом перед эндпоинтами моделей и инструментов, а дальше полагайтесь на идентичность и admission controls, чтобы ограничить то, что агент может делать, даже если вы не можете полностью заглянуть в его «мысли».

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

Заключение

Shadow AI — это следующая ступень эволюции Shadow IT, но с важным отличием: современные ИИ-агенты не просто хранят данные, а умеют их интерпретировать, вызывать инструменты и действовать сразу в нескольких инженерных системах. Это делает их одновременно мощными ускорителями работы и потенциально быстрыми каналами для утечки кода, компрометации учетных данных, атак на цепочку поставок и сбоев в продакшене.

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

Путь вперед конкретен, и большую его часть уже закрывает cloud-native опенсорс: 

• обнаружение использования ИИ;

• назначение владельца;

• ограничение прав через настоящую идентичность рабочей нагрузки;

• защита цепочки поставок через подпись и provenance;

• контроль границ Kubernetes через admission и runtime-политики; 

• сегментация сети;

• мониторинг поведения и обязательное участие человека в значимых действиях. 

Пусть агенты помогают командам работать быстрее, но никогда не позволяйте им действовать там, где вы не можете их увидеть, проконтролировать и остановить.