По прогнозу Gartner, к концу 2026 года task-specific AI-агенты будут встроены в 40% корпоративных приложений против менее чем 5% в 2025-м по оценке той же Gartner. Безопасность агента обычно сводят к guardrails, промпт-фильтрам и хорошо написанной системной инструкции. Однако в июле 2025-го случился инцидент — агент Replit удалил прод-базу SaaStr, хотя его несколько раз просили ничего не менять. А в июле 2026-го на Хабре был опубликован разбор того, как имя, работодатель и город пользователя ушли наружу через Claude без единого клика с его стороны.
Об этих случаях известно только потому, что их публично разобрали — и спасибо тем, кто это делает. Но о скольких ещё случаях мы не знаем? CNCF за восемь июльских дней выпустил три материала подряд об изоляции агентов. Посмотрим, что они предлагают и как собрать из этого рабочий контур из трёх слоёв, с манифестами.
Почему промпт не является границей
За четыре года prompt injection так и не научились надёжно устранять, и есть основания считать, что окончательного решения так не будет. В свежем отчёте OWASP State of Agentic AI Security and Governance инъекция связана с шестью из десяти категорий OWASP Top 10 для агентных приложений. Help Net Security в разборе отчёта объясняет причину одной фразой: «Не существует надёжного способа пометить одни из этих токенов как команды, а другие — как данные». Модель воспринимает системный промпт, запрос пользователя и внешний текст как единый поток. Всё, что попало в контекст, потенциально может управлять агентом.
Версия отчёта за 2025 год каталогизировала теоретические угрозы. В версии 2026-го появились реальные CVE и инциденты: в трекинге OWASP насчитывается 53 агентных проекта, из которых 28 — coding-агенты. У популярных фреймворков уже десятки advisories: 57 у n8n, 22 у Claude Code, 15 у AutoGPT. Фреймворки остались теми же, но теперь их начали ломать всерьёз.
Промпт-фильтр не защищает и от проблем в цепочке поставок. Скомпрометированный пакет LiteLLM в марте 2026 года скачали почти 47 000 раз за три часа. Граница нужна и между агентом, и тем, что он получает из пакетных реестров.
Рынок ответил на это продуктами класса LLM Firewall. Llama Firewall проверяет промпты моделью PromptGuard 2 на 22 млн параметров и статически анализирует сгенерированный код через CodeShield. Инструменты полезные, но фильтруют они текст и код. Похожую оценку даёт разбор Innostage.
LLM в роли регулятора наследует уязвимости модели, которую пытается охранять: от prompt steering до jailbreak. Ideco прямо пишет, что девять из десяти угроз OWASP для агентных систем остаются вне покрытия классического LLM-файрвола.
Полезную рамку предложил Саймон Уиллисон: lethal trifecta — доступ к приватным данным, контакт с недоверенным контентом и канал внешней коммуникации. Агент, в котором сходятся все три свойства, становится инструментом эксфильтрации после одного внедрённого промпта. Meta (признана экстремистской организацией, деятельность которой запрещена на территории Российской Федерации) развивает эту мысль в правиле Agents Rule of Two:без человека в контуре агенту разрешают иметь максимум два свойства из трёх. Оба подхода говорят об уровнях доступа и каналах связи. Промптами такие ограничения не выразить.
Для диагностического read-only-агента границу действительно можно удержать на API-сервере. Достаточно ServiceAccount с правами только на чтение, как в разборе кластер-осведомлённого агента. Но дальше речь пойдёт об агентах, которые действуют: пишут в базы, вызывают API, применяют манифесты. Для них граница опускается на три уровня ниже текста.
Манифесты ниже учебные. Они собраны по документации Kubernetes (RBAC, ServiceAccount, ResourceQuota, NetworkPolicy) и по документации проекта Agent Sandbox от Kubernetes SIG, конфигурация Claw Patrol приведена по справочнику проекта. Все три источника показывают общий принцип. Имена и версии нужно подставить под своё окружение, а перед выходом в прод добавить таймауты, ретраи и мониторинг.
Три слоя изоляции
Runtime: песочница исполнения
К похожей архитектуре независимо пришли как минимум три команды: Anthropic с bubblewrap и seccomp в sandbox-runtime, Google с пулом прогретых песочниц на GKE, Kubernetes SIG с CRD Sandbox поверх gVisor и Kata.В материалах CNCF: «AI sandboxing is having its Kubernetes moment»..
Общий принцип там сформулирован как containment first: сбой политики не должен выходить за жёстко заданные границы. Формулировку предложил вендор песочниц Edera, и в его интересе её продвигать. Но под этим подходом уже есть три независимые реализации.
Модель Mythos Preview у Anthropic в собственном исследовании безопасности нашла 27-летнюю уязвимость в TCP-стеке OpenBSD примерно за тысячу прогонов и менее чем за 20 тысяч долларов. Когда система способна на такое, перечислять в политиках всё, что ей запрещено, уже поздно. Остаётся ограничивать поверхность, до которой она может дотянуться.
Автор материала описывает текущее устройство так: «Тысячи рабочих нагрузок используют одно общее ядро без структурной изоляции». Нагрузки на общем ядре изолированы политиками и предположением, что всё написано без ошибок. Похожую проблему давно решили браузеры: вкладки развели по процессам, и сбой одной вкладки перестал затрагивать остальные. Обещание у этого подхода одно — локализовать сбой.
Kubernetes-сообщество оформило идею в отдельный примитив. Проект Agent Sandbox от Kubernetes SIG вводит CRD Sandbox: один Sandbox соответствует одному изолированному поду для агента, а под капотом работает gVisor или Kata. Для gVisor достаточно одной строки:
apiVersion: agents.x-k8s.io/v1beta1 kind: Sandbox metadata: name: report-agent namespace: agents-report spec: podTemplate: metadata: labels: app: report-agent # по этой метке зацепятся сетевые политики из слоя 3 spec: runtimeClassName: gvisor # вся изоляция ядра - здесь containers: - name: agent image: registry.example.com/agents/report:1.4.2 resources: requests: cpu: 300m memory: 700Mi limits: cpu: 700m memory: 1500Mi
Жизненный цикл, хранилище и идентичность Sandbox задаются отдельными полями. Полный список параметров приведён в документации проекта. Метка в podTemplate.metadata.labels потребуется на следующем шаге: по ней сетевые политики определяют, к каким подам применять правила. Запросы ресурсов выбраны с учётом квоты на следующем уровне — её достаточно для пяти подов.
gVisor или Kata: компромисс по производительности
gVisor ставит между контейнером и хостом userspace-ядро, которое перехватывает системные вызовы. Если container escape всё же случится, атакующий попадёт в userspace-ядро песочницы, а до хоста останется ещё один барьер. Kata Containers решает ту же задачу аппаратной виртуализацией.
У этих подходов разная цена с точки зрения производительности. В гайде gVisor показано, откуда берётся оверхед: вычисления и работа с памятью обычно выполняются почти с той же скоростью, что и в обычном контейнере, а системные вызовы, сеть и файловые операции заметно медленнее. Если агент в основном выполняет вычисления и ждёт ответа от LLM, разница может быть несущественной. Но для нагрузки с частой работой с файлами и сетевыми соединениями имеет смысл отдельно протестировать Kata.
Есть и второй фактор — время холодного старта. На KubeCon NA 2025 Google назвала изоляцию на уровне ядра обязательной для агентных сценариев и показала пул заранее запущенных песочниц. В такой схеме новая среда готова менее чем за секунду — компания заявляет до 90% выигрыша по сравнению с холодным стартом. Эти цифры получены в GKE, но сам принцип прогретого пула не зависит от конкретной платформы.
Anthropic приводит другой пример. В Claude Code песочница с egress-прокси сократила количество запросов на подтверждение действий у пользователя на 84%. Когда среда надёжно изолирована, агенту можно заранее разрешить больше операций — и пользователю реже приходится вмешиваться в процесс.
Весь слой держится на одной формулировке из того же материала: «Для надёжной песочницы нужны и изоляция файловой системы, и изоляция сети». Изоляция файловой системы без сетевой оставляет канал для эксфильтрации. Сетевая изоляция без файловой не спасает данные от порчи. В открытом sandbox-runtime это видно по примитивам Linux: используются bubblewrap и seccomp-фильтры, сетевой namespace полностью удаляется, а выход наружу идёт через мост к хостовому прокси с allow-list доменов.
gVisor измеряют на синтетических бенчмарках и классических сервисах, но публичных замеров на агентском профиле пока нет ни у одного вендора. В такой профиль плохо укладываются длинные паузы на инференс и всплески файловых операций между ними. Поэтому выбирать между gVisor и Kata лучше на собственном трафике.
Минимальная схема замера: запустить одного агента на одной задаче в трёх рантаймах — runc, gVisor и Kata — и сделать по полсотни прогонов. Сравнивать стоит p95 wall-clock времени задачи и число системных вызовов через strace -c. Если разница между runc и gVisor теряется в разбросе времени инференса, выбирать уже не из чего.
Pod и ServiceAccount: идентичность и права
Эволюцию этого паттерна хорошо видно на примере open-source-проекта kagent. Изначально все агенты работали в одном runtime. Затем команда перешла к модели: «каждый агент запускается в отдельном Pod, со своим Service и ServiceAccount».
Причина не только в изоляции сбоев. Pod задаёт агенту отдельную идентичность: ServiceAccount становится субъектом RBAC, по меткам Pod применяются NetworkPolicy, а namespace позволяет ограничить потребление ресурсов квотами. В результате агент перестаёт быть безымянным процессом внутри общего runtime и становится отдельным объектом кластера — с именем, правами и лимитами ресурсов.
Для одного агента обычно нужен такой набор:
apiVersion: v1 kind: ServiceAccount metadata: name: report-agent namespace: agents-report automountServiceAccountToken: false # по умолчанию не монтируем; поду, которому API нужен, включаем точечно --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: report-agent-role namespace: agents-report rules: - apiGroups: [""] resources: ["configmaps"] verbs: ["get", "list"] # ровно то, что нужно задаче --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: report-agent-binding namespace: agents-report subjects: - kind: ServiceAccount name: report-agent namespace: agents-report roleRef: kind: Role name: report-agent-role apiGroup: rbac.authorization.k8s.io --- apiVersion: v1 kind: ResourceQuota metadata: name: report-agent-quota namespace: agents-report spec: hard: requests.cpu: "2" requests.memory: 4Gi limits.cpu: "4" limits.memory: 8Gi pods: "5" # потолок на спавн подагентов
Синтез по официальной документации: RBAC, ServiceAccount, ResourceQuota.
В этом наборе есть две важные настройки:
automountServiceAccountToken: falseвServiceAccount. Если агент не работает с Kubernetes API, токен ему не нужен. Токен внутри Pod — лишняя цель: при успешной инъекции его можно использовать для доступа к API от имени агента.Roleвсё равно можно оставить как ограничитель на случай, если такой доступ понадобится позже. Тогда токен включают явно — черезautomountServiceAccountToken: trueв спецификации конкретного Pod. По умолчанию он не монтируется, а любое исключение видно в манифесте.namespace. Для агента или небольшого пула агентов лучше выделить отдельный namespace. В гайде Kubernetes по RBAC отмечено, что границы внутри одного namespace слабее, чем между namespace. Поэтому права стоит выдавать точечно: использовать
RoleBindingвместоClusterRoleBinding, где это возможно, и не применять wildcard-правила.
Предел здесь задаёт скорее экономика, чем безопасность. Сервис может работать днями, а агент нередко живёт всего несколько секунд или минут. Нагрузка идёт волнами, подагенты появляются прямо во время выполнения задачи. Если заранее держать отдельный Pod под каждого из них, ресурсы быстро начинают простаивать.
В статье CNCF Lin Sun описывает альтернативу — agent-substrate. Вместо Pod на каждого агента здесь используется пул worker-Pod’ов (WorkerPool CRD). Шаблон (ActorTemplate) описывает окружение агента, включая образ, закреплённый по sha256, и runtime gVisor; логические агенты (Actor) запускаются на свободных воркерах.
В примере CNCF шесть агентов поместились в один worker-Pod, поскольку не выполнялись одновременно. Смысл подхода в том, что Pod становится единицей исполнения, а не постоянной единицей развёртывания для каждого агента.
Посмотреть на agent-substrate стоит, но для production пока рано: в статье речь о версии v0.0.6 от одного вендора.
Направление подтверждают извне: InfoQ разобрал дискуссию как тренд, Google анонсировала на своей платформе Agent Sandbox и Agent Substrate. Identity агента отвязывается от пода, как когда-то identity сервисов отвязалась от машин.
Разворачивайте кластеры с Managed Kubernetes
Автоматизируйте деплой
и снижайте затраты на инфраструктуру
до 60%
Попробовать
Egress: куда и что может делать агент
Даже хорошо изолированный агент с минимальными правами остаётся риском, если ему разрешён произвольный исходящий трафик. В упомянутой во введении статье «Кража памяти» данные выводили через цепочку внешне безобидных переходов по ссылкам.
Поэтому сетевой слой начинается с базового правила: для namespace агента включают default-deny, а затем разрешают только необходимый исходящий трафик.
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all namespace: agents-report spec: podSelector: {} # все поды namespace policyTypes: ["Ingress", "Egress"] # запрещено всё в обе стороны --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: report-agent-egress namespace: agents-report spec: podSelector: matchLabels: app: report-agent policyTypes: ["Egress"] egress: - to: # DNS кластера - иначе не заработает ничего - namespaceSelector: matchLabels: kubernetes.io/metadata.name: kube-system ports: - protocol: UDP port: 53 - protocol: TCP port: 53 - to: # единственный разрешённый выход - egress-шлюз - namespaceSelector: matchLabels: kubernetes.io/metadata.name: agent-egress ports: - protocol: TCP port: 3128
Это базовая схема из документации NetworkPolicy: сначала общий запрет, затем отдельные разрешающие правила. Чтобы разрешающее правило сработало, Pod агента должен иметь метку app: report-agent. Для Sandbox её указывают в podTemplate.metadata.labels, для Deployment — в template.metadata.labels. Если метки нет, второе правило не выберет ни одного Pod, и для агента останется в силе общий default-deny.
DNS — первое исключение из default-deny
Первое правило блокирует весь исходящий трафик — в том числе запросы к kube-dns. При этом Pod обычно не сообщает о проблеме напрямую: DNS-имена просто перестают резолвиться, а в логах появляются таймауты при обращении и к LLM API, и к внутренним сервисам. Поэтому разрешение на DNS-трафик в kube-system здесь не факультативно, а обязательно.
Но NetworkPolicy умеет ограничивать трафик только по IP-адресам и портам. Для агента этого недостаточно: он ходит по HTTPS к доменам, а набор таких доменов может меняться в зависимости от задачи. Поэтому из Pod обычно разрешают только один выход — к прокси-шлюзу, который уже разбирает HTTP(S)-трафик и применяет правила на уровне доменов.
Такую схему описывает материал CNCF от F5: весь исходящий трафик агента идёт через NGINX в роли forward proxy, разрешённые домены задаются allow-list’ом, а iptables блокирует попытки обойти прокси напрямую.
Прокси решает не только задачу фильтрации. Он показывает, куда именно агент обращается наружу. Без этого контроля команды нередко не готовы пускать агентов в production: невозможно проверить, какие внешние сервисы агент вызывает и какие данные может передать за пределы кластера.
Правила для протоколов и операций
Allow-list доменов отвечает лишь на вопрос, куда агент может подключаться. Но этого недостаточно, когда агенту открыт доступ к production-базе: важно ограничить сами действия — какие запросы он вправе выполнять и с какими объектами работать.
Для этого нужен контроль ниже сетевого уровня, на уровне протокола. Open-source-проект Claw Patrol от Deno разбирает трафик PostgreSQL, ClickHouse, Kubernetes API и HTTPS, а затем применяет allow/deny-правила на CEL к полям разобранного запроса:
# читать каталог отчётов - можно rule "reporting_read" { endpoint = postgres.prod condition = "sql.verb == 'SELECT' && sql.tables.all(t, t.startsWith('reporting.'))" verdict = "allow" } # записи в прод - только через подтверждение человеком rule "prod_writes" { endpoint = postgres.prod condition = "sql.verb in ['INSERT', 'UPDATE', 'DELETE']" approve = [human_approver.oncall] reason = "запись в прод-БД - только с подтверждением" }
Правила описываются в HCL, а условия внутри них пишутся на CEL. Эндпойнты — например, postgres.prod — и пользователи или группы, которые могут подтверждать запросы, объявляются отдельными блоками в том же конфигурационном файле.
Доступные поля, такие как sql.verb, sql.tables, k8s.verb и http.path, а также точный синтаксис зависят от версии Claw Patrol. Перед внедрением конфигурацию стоит сверить с актуальным справочником.
Секреты через этот канал не передаются. Агент получает только плейсхолдер, а реальные учётные данные подставляет шлюз уже при подключении к целевой системе. В контексте агента этих данных нет — значит, их нельзя извлечь из его памяти, логов или рабочего каталога.
Политика доступа при этом хранится как код в Git. Пользователь rough-sea описывает свою установку так: «В нашей конфигурации вся политика безопасности описана одним файлом, который хранится в Git и контролирует доступ к 14 Kubernetes-кластерам, ClickHouse, PostgreSQL и ещё примерно дюжине HTTP API». Проверить это утверждение независимо нельзя, но оно показывает, на какой масштаб рассчитан подход. По словам Deno, Claw Patrol вырос из их собственной практики: инструмент нужен, чтобы пускать ops-агентов в production, не передавая им постоянные креды.
Оговорка здесь та же, что и с agent-substrate: проект молодой, за ним стоит один вендор, а публичных замеров накладных расходов на разбор протокола PostgreSQL пока нет. Перед тем как ставить такой шлюз между агентом и production-базой, стоит проверить две вещи:
Как он ведёт себя на долгих операциях
COPY.Что происходит с активными и новыми соединениями, если шлюз становится недоступен.
Где этот контур не работает
В обсуждении Claw Patrol на Hacker News пользователь oulipo2 задаёт очевидный вопрос: зачем добавлять слой, который запрещает агенту выполнять запись в SQL, если можно сразу выдать ему read-only-аккаунт? Он же указывает на слабое место любой политики, построенной как чёрный список: «Я понимаю идею с „централизованным реестром“, но в нём легко что-то упустить, а агенты хорошо умеют обходить ограничения: „ага, DROP TABLE нельзя — тогда просто удалю все строки“, и так далее.».
Если агенту запретить DROP TABLE, но разрешить DELETE, он может удалить все строки и формально не нарушить правило. Это не столько аргумент против Claw Patrol, сколько напоминание о границах deny-list’ов вообще.
Чёрные списки и обходы
Read-only-учётная запись и правила на шлюзе решают разные задачи:
Учётная запись определяет то, чего агент не сможет сделать в принципе.
Шлюз вводит операции, для которых требуется отдельное подтверждение человека.
Если выбирать только один механизм, разумнее начать с учётной записи: она проще, надёжнее как базовый барьер и не зависит от полноты списка правил. Шлюз нужен там, где агенту действительно требуется право записи, но некоторые действия всё равно должны оставаться под контролем человека.
Та же логика работает ниже по стеку. Один HTTP-прокси легко обойти, если агент может запустить дочерний процесс: например, вызвать psql напрямую и не пройти через HTTP-слой. На этот сценарий указывают и в описании проекта.
Поэтому шлюз должен видеть сам протокол, а не только HTTP. Одновременно у песочницы нужно убрать прямой сетевой доступ — например, выделить ей отдельный сетевой namespace, как это делают sandbox-runtime. Один слой закрывает обходы другого; одиночную границу, на каком бы уровне она ни стояла, почти всегда можно обойти.
Shadow AI вне Kubernetes
Три технических слоя работают только с теми агентами, которые уже попали в поле зрения платформы. Если агент запущен вне этого контура, защищать там попросту нечего.
По данным OWASP, политику поиска и учёта shadow AI внедрили лишь 37% организаций. NetworkPolicy применяется к Pod по меткам, но метка появляется только у того Pod, который кто-то намеренно задеплоил в кластер. Скрипт на ноутбуке аналитика, запускающий агента с production-кредами из переменных окружения, под такие правила не попадёт.
Эта проблема решается выше уровня Kubernetes-манифестов: через инвентаризацию агентов, контролируемую выдачу доступов и правила, которые не позволяют использовать production-секреты вне утверждённого контура.
Аудит, эксплуатация и требования
Каждый вызов агента проходит через шлюз и оставляет запись. OTel-модуль NGINX создаёт span для внешнего запроса, а трассировка уходит в SIEM или Grafana. В Claw Patrol ту же задачу решает аудит-лог на шлюзе. Получается журнал действий, который иначе пришлось бы собирать отдельным проектом.
Есть только одна важная оговорка. Как пишет CNCF, «observability must follow the logical agent, not the underlying Pod». Pod — сущность временная: он может завершиться, пересоздаться или обслуживать несколько задач. Поэтому в трассировках и аудит-логах нужен идентификатор логического агента, а не только имя Pod.
Инструменты здесь те же, что и для обычной многотенантности: сетевые политики, квоты и аудит. Для людей и команд мы разбирали их в материалах про слои изоляции в общем кластере и политики Gatekeeper. В Managed Kubernetes от VK Cloud сетевые политики, квоты и аудит доступны из коробки. RuntimeClass с gVisor и CRD Agent Sandbox в сервис не входят: их, как и в других managed-кластерах, нужно ставить самостоятельно.
Регуляторные требования постепенно сходятся с тем, что этот контур даёт сам по себе. Обязанности по high-risk-системам из Annex III, включая статью 26 EU AI Act, Digital Omnibus перенёс на 2 декабря 2027 года, а для ИИ внутри регулируемых продуктов на 2 августа 2028-го. Со 2 августа 2026 года применяется статья 50 о прозрачности. Сместился срок, не содержание. Пункт 2 статьи 26 требует, чтобы за человеческий надзор над high-risk-системами отвечали конкретные люди с «the necessary competence, training and authority, as well as the necessary support». Authority стоит здесь в одном ряду с компетенцией и подготовкой: недостаточно назначить ответственного на бумаге, у него должна быть возможность вмешаться в работу системы. Шлюз с правилом, требующим подтверждения операции, даёт такую возможность на практике. Пункт 6 отдельно требует хранить автоматически создаваемые логи не менее шести месяцев, если право ЕС или страны-члена не устанавливает иной срок. Собирать такой контур логичнее до декабря 2027-го, а не после..
Сроки уведомления об инцидентах при этом сокращаются: DORA отводит четыре часа, RAISE Act — 72. Без журнала на шлюзе за четыре часа трудно даже восстановить картину произошедшего. На логи самого приложения полагаться нельзя: скомпрометированный агент запишет туда только то, что сочтёт нужным. Запись на шлюзе он не контролирует.
В России требования к изоляции AI-агентов пока не выделены в отдельную категорию. Но такой контур попадает в уже знакомые для аттестованных систем меры: сегментацию, разграничение доступа и регистрацию событий безопасности. NetworkPolicy и egress-шлюз отвечают за сегментацию; ServiceAccount с узкой Role и песочница — за разграничение доступа; аудит-лог шлюза — за регистрацию событий. Если агент обращается к системе, отнесённой к значимым объектам КИИ, появляется и обязанность уведомлять ГосСОПКА об инциденте: для значимых объектов КИИ срок составляет три часа, для остальных 24 часа.
Проверка перед запуском
Версии API в этих манифестах имеют разный статус. networking.k8s.io/v1 и rbac.authorization.k8s.io/v1 — стабильные группы, доступные в любом поддерживаемом Kubernetes-кластере. agents.x-k8s.io/v1beta1 — бета-API проекта Agent Sandbox. Его CRD не появляется в кластере сам: в managed-среде его тоже нужно установить и поддерживать самостоятельно.
Перед полноценным стендом достаточно сделать три короткие проверки.
Проверить реальные права ServiceAccount
kubectl auth can-i --list \ --as=system:serviceaccount:agents-report:report-agent
Команда покажет эффективные права ServiceAccount после применения Role и всех существующих привязок. Иногда выясняется, что агенту доступны лишние действия из-за унаследованных ClusterRole или слишком широких RoleBinding.
Проверить, что egress действительно закрыт Зайдите в Pod агента через kubectl exec и выполните curl к домену, которого нет в allow-list. Если запрос проходит, политика не работает или не выбрала этот Pod. Проверять причину удобно в таком порядке: поддерживает ли CNI NetworkPolicy, есть ли нужная метка на Pod, корректен ли namespaceSelector для kube-system. Например, Flannel сам по себе не применяет NetworkPolicy: объект Kubernetes создаст, но трафик продолжит ходить без ограничений.
Проверить наличие runtime. kubectl get runtimeclass. Команда сразу покажет, установлен ли в кластере runtime для gVisor. Это лучше выяснить до того, как указывать runtimeClassName в манифесте: иначе Pod может остаться в Pending или не запуститься из-за отсутствующего RuntimeClass.
Минимальный контур для production
Если из трёх слоёв получается внедрить только один, начинайте с сети. Песочница защищает хост, RBAC — кластер, но за пределы компании данные уходят по сети. «Кража памяти» прошла бы через первые два слоя, как и удаление базы в истории с Replit. default-deny и egress-шлюз можно собрать за день: для этого не нужны ни CRD, ни другой runtime. Достаточно кластера, где CNI действительно применяет NetworkPolicy.
Полный контур выглядит так:
Runtime:
RuntimeClassс gVisor или Kata.Единица развёртывания: отдельный Pod на агента, свой
ServiceAccountбез автомонтирования токена, узкаяRole, namespace сResourceQuota.Сеть:
default-denyдля ingress и egress, выход только через шлюз с allow-list, правила на уровне протокола для доступа к базам и Kubernetes API.
В ситуации с Replit операция DELETE упёрлась бы в правило шлюза, требующее подтверждения записи. Сама попытка осталась бы в аудит-логе ещё до начала расследования.
Агенты становятся ещё одним классом тенантов кластера. В июльской колонке CNCF их называют «non-human platform consumers with their own access, scope, and governance needs» — потребителями платформы без человека за консолью, но со своими правами, областью ответственности и требованиями к управлению. Их будут тысячи, а жить они будут минуты.
Агенты всё равно окажутся в production — в той или иной форме. Поэтому важнее другое: что именно не даст агенту добраться до системы, если он ошибётся, получит вредную инструкцию или попытается обойти ограничение.
Если у вас уже есть такой контур, поделитесь в комментариях, какие обходы или слабые места вы нашли на практике.