AI-агенты в CI/CD получают ключи от продакшена: безопасность требует реестра и изоляции

Откуда берётся теневой ИИ в пайплайне?

Термин Shadow AI, теневой ИИ, описывает любые ИИ-инструменты, модели, агентов и расширения, которые используются в жизненном цикле разработки без формального согласования, без ответственного владельца, без оценки рисков и мониторинга. Материал Маттео Бизи разбирает эту проблему на примере типичного cloud-native пути доставки, от ноутбука разработчика до пода в Kubernetes. Ниже я собрал из этого разбора практический гайд: что именно проверять, чем закрывать и в каком порядке действовать.

Ключевой сдвиг, который выделяет Бизи: риск резко возрастает, когда ИИ-агент (agent, программа, способная самостоятельно вызывать инструменты и выполнять действия) перестаёт советовать и начинает действовать. Ассистент, предлагающий фрагмент кода, создаёт один класс рисков. Агент с токеном Git, облачными учётными данными или ServiceAccount в Kubernetes создаёт совсем другой: он может создавать, изменять и удалять ресурсы быстрее, чем человек успеет заметить.

Что понадобится

• Доступ к репозиториям и CI/CD-пайплайну вашей команды (GitHub Actions, GitLab CI или аналог)
• Опенсорс-инструменты (все бесплатны): gitleaks, Gitsign (часть проекта Sigstore), OPA (Open Policy Agent), Trivy, Falco, SLSA-верификатор
• Реестр одобренных ИИ-инструментов (если его нет, первый шаг именно создание)
• Время: базовый аудит одного пайплайна занимает от двух до четырёх часов, внедрение контрмер по всем этапам от одного до трёх спринтов

Пошаговая инструкция: контроль ИИ-агентов на каждом этапе пайплайна

1. Составьте реестр ИИ-инструментов и агентов. Пройдитесь по командам и зафиксируйте: какие ИИ-расширения установлены на ноутбуках, какие интеграции подключены к CI/CD, у каких агентов есть токены или сервисные аккаунты. Без реестра вы не знаете, что защищать.

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

3. Закройте этап «ноутбук разработчика». Предоставьте одобренные ИИ-инструменты, чтобы использование стало видимым. Полный запрет загоняет практику глубже в тень. Подключите pre-commit сканирование секретов через gitleaks как git-хук:

# Установка gitleaks и подключение как pre-commit хука
brew install gitleaks
# или скачайте бинарник с github.com/gitleaks/gitleaks
gitleaks protect --staged

1. Внедрите подписанные коммиты через Gitsign. Это отвечает на вопрос «кто создал изменение», в том числе когда автор, агент. Gitsign использует короткоживущие сертификаты на основе идентичности вместо долгоживущих GPG-ключей:

# Настройка Gitsign для репозитория
git config --local commit.gpgsign true
git config --local gpg.x509.program gitsign
git config --local gpg.format x509

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

2. На этапе CI/CD ограничьте права через политики. OPA (Open Policy Agent, движок политик, который проверяет запросы по вашим правилам) позволяет задать, какие действия разрешены агенту в пайплайне. Trivy сканирует образы контейнеров на уязвимости перед деплоем.

3. В продакшене включите runtime-мониторинг через Falco. Falco (инструмент, который отслеживает системные вызовы в контейнерах и поднимает тревогу при аномалиях) покажет, если агент начнёт делать то, чего не должен: читать секреты, открывать сетевые соединения, изменять конфигурацию.

4. Проверьте целостность цепочки поставок. SLSA-верификатор (Supply-chain Levels for Software Artifacts, фреймворк проверки, что артефакт собран именно из того кода, который заявлен) подтвердит, что образ контейнера не был подменён на пути от сборки до деплоя.

Что делать с этим прямо сейчас, по ролям?

DevOps-инженеру: начните с аудита, пройдите по пайплайну и составьте список всех ИИ-интеграций. Подключите gitleaks как pre-commit хук, это закроет самый частый вектор утечки и займёт полчаса.

Security-инженеру: постройте модель угроз по этапам пайплайна. Бизи выделяет ресурсы для защиты: исходный код, API-ключи и токены, данные клиентов, конфигурации CI/CD, облачные идентификаторы, образы контейнеров, доступность продакшена. Для каждого ресурса зафиксируйте, какие агенты имеют к нему доступ. Руководство OWASP по ИИ-агентам и LLM-приложениям, хорошая базовая линия для сценариев отказа.

Тимлиду и руководителю: выпустите политику: ни один ИИ-агент не работает без владельца-человека, без регистрации в реестре и без возможности немедленного отзыва доступа. Это не бюрократия, а условие, без которого безопасность ИИ-агентов (ai агенты безопасность) не обеспечить.

Автору на Дзене, пишущему про DevOps и безопасность: тема теневого ИИ в CI/CD ещё почти не раскрыта на русском языке. Гайд с конкретными инструментами соберёт аудиторию, которая устала от общих рассуждений про угрозы ИИ.

Самый конкретный первый шаг: откройте терминал, установите gitleaks, запустите gitleaks detect на вашем репозитории и посмотрите, сколько секретов уже лежит в истории коммитов. Результат, скорее всего, убедит команду быстрее любой презентации про безопасность ИИ-агентов.