Безопасность AI агентов в Kubernetes требует пересмотра базовых допущений. Динамическое поведение ломает привычные модели RBAC, network policy и лимитов ресурсов.
Проблема проявляется не сразу — до момента, когда автономный агент начинает вести себя как система без фиксированных границ. В классической модели Kubernetes предполагается предсказуемый набор зависимостей, стабильный профиль нагрузки и ограниченный доступ к внешним API. У AI агента этого нет. Он сам определяет, какие источники данных опрашивать, какие гипотезы проверять и какие шаги выполнять. Это приводит к размытым trust boundaries, невозможности задать корректные network policy и отсутствию базовой линии для anomaly detection. Дополнительно растёт риск: один контейнер может держать доступ к логам, метрикам, сетевому мониторингу и внешним API одновременно.
Решение оказалось прагматичным: сместить единицу изоляции с сервиса на уровень отдельного расследования. Вместо long-running Deployment — один Kubernetes Job на одну задачу агента. Это компромисс между скоростью старта и контролем. Да, появляется накладной overhead на запуск (несколько секунд), но он незначителен на фоне выполнения, которое может занимать минуты. Зато появляется жёсткая изоляция по ресурсам, отказам и состоянию. Параллельно используется Vault для управления секретами с коротким временем жизни, чтобы ограничить blast radius при компрометации.
Реализация упирается в детали оркестрации и управления доступами. Каждый Job получает собственные CPU и memory лимиты, что устраняет конкуренцию между «тяжёлыми» и «лёгкими» расследованиями. Failure isolation работает на уровне Kubernetes: падение одного Job не влияет на остальные. Чистое состояние контейнера исключает утечки контекста и накопление артефактов. Логи и метрики привязаны к конкретному Job, что упрощает трассировку и аудит.
Секреты становятся отдельной архитектурной задачей. Агенту нужны ключи к нескольким доменам: логирование, метрики, сеть, LLM API. Хранить это статически — рискованно. Используется Vault: аутентификация через service account, выдача временных credentials на время выполнения Job, автоматическая ревокация после завершения. Это снижает окно атаки и убирает необходимость в ротации через деплой. При этом выбран компромисс: единая identity для агента с доменными политиками, вместо уникальной identity на каждый Job. Это упрощает операции, но снижает точность атрибуции.
Отдельный слой — модель доверия. Переход к автономии разбит на фазы: от read-only анализа до полного автоматического remediation. Ключевой момент — решения принимаются не по roadmap, а по операционным сигналам. Метрика доверия — это не accuracy, а поведение операторов: насколько часто они меняют вывод агента. Такой подход снижает риск преждевременной автоматизации и даёт контролируемую эволюцию.
Результаты носят качественный характер. Система становится предсказуемее в условиях непредсказуемого workload. Изоляция через Jobs устраняет класс проблем с конкуренцией ресурсов и зависшими процессами. Vault снижает blast radius и упрощает ротацию секретов. Однако остаются trade-offs: усложнение оркестрации, рост числа объектов в кластере и необходимость более зрелого observability. Метрики эффективности не приведены, но архитектурные эффекты соответствуют ожидаемым для таких паттернов.
Главный вывод: AI агенты — это новый класс workload. Они требуют пересмотра базовых принципов Kubernetes безопасности и управления. Попытка вписать их в модель микросервисов приводит к скрытым отказам, которые проявляются уже в продакшене.