AI-агент в проде: песочница, RBAC и egress-контур вместо надежды на промпт
По прогнозу Gartner, к концу 2026 года специализированные AI-агенты будут встроены примерно в 40% корпоративных приложений. Для сравнения: в 2025 году их доля оценивалась менее чем в 5%. Рост выглядит впечатляюще, но вместе с ним увеличивается и поверхность атаки.
Безопасность агентных систем часто пытаются обеспечить системным промптом, guardrails и фильтрацией пользовательских запросов. Такой подход полезен, но не может быть единственной линией защиты. Промпт не является настоящей границей безопасности: модель воспринимает системные инструкции, запрос пользователя, содержимое веб-страницы, файл из репозитория и ответ внешнего API как элементы одного контекста. Любой из них может повлиять на дальнейшее поведение агента.
Показательный пример произошёл в июле 2025 года: агент Replit удалил рабочую базу SaaStr, несмотря на неоднократные указания ничего не менять. В другом публичном разборе выяснилось, что персональные данные пользователя - имя, место работы и город - могли быть раскрыты через Claude без отдельного клика со стороны человека. Подобные инциденты известны только потому, что их удалось обнаружить и описать. Масштаб скрытых случаев оценить гораздо сложнее.
Почему prompt injection нельзя считать решённой проблемой
За несколько лет не появилось универсального способа надёжно отделять команды от данных. Модель видит всё содержимое контекста как последовательность токенов, а не как набор объектов с непреодолимыми уровнями доверия. Поэтому инструкция, спрятанная в документации, комментарии кода, письме или результате поиска, может изменить поведение агента.
В актуальных оценках OWASP prompt injection связана с шестью из десяти категорий рисков для агентных приложений. В новых версиях исследований внимание сместилось от теоретических сценариев к реальным CVE и инцидентам. В трекинге OWASP фигурируют десятки агентных проектов, включая coding-агенты. У популярных фреймворков уже накопились многочисленные advisories: у n8n - 57, у Claude Code - 22, у AutoGPT - 15.
Отдельная проблема - цепочка поставок. В марте 2026 года скомпрометированный пакет LiteLLM загрузили почти 47 тысяч раз всего за три часа. Даже идеально составленный системный промпт не спасёт, если агент запускает вредоносный код из зависимости или получает подменённый инструмент.
LLM Firewall, PromptGuard и статический анализ кода помогают снизить риск, однако они проверяют текст и генерируемые артефакты. Они не заменяют изоляцию процесса, разграничение полномочий и контроль сетевых каналов. Если сама модель стала регулятором поведения другой модели или собственного агента, она наследует уязвимости исходной системы: prompt steering, jailbreak и ошибки интерпретации.
Lethal trifecta и правило двух
Удобная модель угроз - lethal trifecta, или "смертельная триада". Опасность возникает, когда агент одновременно:
1. имеет доступ к приватным данным;
2. обрабатывает недоверенный контент;
3. способен отправлять информацию во внешний канал.
После внедрения одной вредоносной инструкции такая система превращается в потенциальный инструмент эксфильтрации.
Практическое ограничение формулируется так: автономному агенту без человека в контуре следует разрешать максимум два из этих трёх свойств. Например, агент может читать недоверенные данные и работать с локальными ресурсами, но не иметь исходящего доступа в интернет. Или может обращаться к внешнему API, но работать только с обезличенной информацией и в режиме read-only.
Для диагностического агента, который лишь читает состояние кластера, границу можно провести на уровне API-сервера Kubernetes. Но агент, способный менять базы, вызывать внешние API или применять манифесты, требует защиты как минимум на трёх уровнях: исполнения, полномочий и сети.
Первый слой: изолированное выполнение
Агент не должен запускаться непосредственно на узле, рядом с системными процессами и секретами. Его действия следует помещать в отдельную песочницу.
В Kubernetes базовым вариантом остаётся отдельный Pod с ограниченными ресурсами и запретом на привилегированные операции. Для более строгой изоляции применяются gVisor или Kata Containers. Они создают дополнительный барьер между контейнером и ядром хоста, хотя и требуют проверки совместимости и могут снижать производительность.
Минимальные настройки должны включать:
- запрет запуска от root;
- `allowPrivilegeEscalation: false`;
- `readOnlyRootFilesystem: true`;
- отключение Linux capabilities;
- отдельный ServiceAccount;
- ограничения CPU и памяти;
- ResourceQuota на namespace;
- запрет доступа к hostPath, hostNetwork и hostPID;
- временную файловую систему для каталога `/tmp`.
Пример фрагмента security context:
```yaml
securityContext:
runAsNonRoot: true
runAsUser: 10001
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
```
Песочница не делает вредоносный код безопасным, но ограничивает последствия ошибки. Если агент попытается удалить файлы, установить пакет или запустить дочерний процесс, его возможности будут ограничены политикой контейнера.
Второй слой: RBAC и минимальные полномочия
ServiceAccount не должен автоматически получать права администратора. Для read-only-агента достаточно разрешений `get`, `list` и, при необходимости, `watch` для конкретных ресурсов и namespace.
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: agent-reader
rules:
- apiGroups: [""]
resources: ["pods", "services", "configmaps"]
verbs: ["get", "list", "watch"]
```
Если агенту требуется изменять объект, право `update`, `patch` или `delete` нужно выдавать точечно. Не следует использовать `cluster-admin` "для удобства" или давать доступ ко всем namespace.
Полномочия необходимо разделять по задачам. Диагностический агент, агент развёртывания и агент реагирования на инциденты должны использовать разные ServiceAccount. Это упрощает аудит и позволяет быстро отозвать один набор прав, не останавливая остальные процессы.
Секреты также нельзя монтировать без необходимости. Если агенту нужен токен внешнего API, лучше использовать короткоживущие учётные данные, отдельный секрет на каждую интеграцию и автоматическую ротацию. Переменные окружения удобны, но нередко попадают в дампы, логи и диагностические отчёты.
Третий слой: egress-контур
Даже ограниченный контейнер опасен, если может отправить данные куда угодно. Поэтому исходящий трафик следует запрещать по умолчанию и разрешать только необходимые направления.
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: agent-egress
spec:
podSelector:
matchLabels:
app: agent
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
name: platform
ports:
- protocol: TCP
port: 443
```
DNS - важное исключение. Если полностью закрыть UDP/TCP 53, агент перестанет разрешать имена. Но разрешение DNS само по себе не должно означать свободный доступ в интернет. Лучше направлять запросы через контролируемый резолвер, вести журналы обращений и блокировать подозрительные домены.
Контроль egress должен учитывать не только IP-адреса, но и протоколы, порты и смысл операций. Доступ к корпоративному API не означает право выполнять все его методы. Для критичных действий полезно вводить отдельный прокси, который проверяет метод, путь, размер запроса и тип передаваемых данных.
Где такой контур не спасёт
NetworkPolicy и RBAC не защищают от уже разрешённых действий. Если агенту разрешено отправлять запросы в конкретный сервис, он может попытаться вынести данные через легитимный endpoint. Поэтому критичные API должны иметь собственную авторизацию, валидацию схем и ограничения на объём операций.
Чёрные списки также не дают гарантии. Вредоносная инструкция может использовать альтернативный домен, редирект, DNS-туннель, разрешённый облачный сервис или обычный корпоративный API. Надёжнее строить allowlist, ограничивать формат данных и запрещать агенту самостоятельно формировать произвольные URL.
Нельзя забывать и о Shadow AI. Агент может запускаться не в Kubernetes, а на ноутбуке разработчика, в CI/CD, серверless-функции или отдельной виртуальной машине. В этом случае кластерные политики не действуют. Нужны инвентаризация инструментов, контроль исходящего трафика на уровне сети, управление секретами и единая регистрация агентных приложений.
Аудит и эксплуатация
Без журналов невозможно понять, что именно сделал агент и почему. Логировать стоит не только финальный ответ, но и:
- вызванные инструменты;
- идентификатор пользователя и ServiceAccount;
- входные и выходные параметры операций;
- изменения ресурсов;
- сетевые подключения;
- ошибки авторизации;
- срабатывания политик;
- версии модели, промпта и инструментов.
При этом в логи нельзя бездумно записывать персональные данные, токены и содержимое секретов. Нужны маскирование, контроль доступа и ограниченный срок хранения.
Для опасных операций следует использовать режим предварительного просмотра: агент формирует план, а отдельный контроллер или человек подтверждает его выполнение. Особенно это важно для удаления данных, изменения сетевых правил, публикации образов и работы с производственными базами.
Минимальный production-контур
Перед запуском агентной системы стоит проверить:
1. Есть ли отдельный namespace и ServiceAccount?
2. Запрещён ли запуск от root?
3. Ограничены ли CPU, память и временное хранилище?
4. Отключены ли привилегии, host namespaces и лишние capabilities?
5. Описаны ли RBAC-права по принципу минимально необходимых?
6. Закрыт ли исходящий трафик по умолчанию?
7. Разрешены ли только конкретные DNS-имена и сервисы?
8. Есть ли аудит действий и сетевых соединений?
9. Ротируются ли токены и секреты?
10. Требуется ли подтверждение для необратимых операций?
11. Проверяются ли зависимости и образы в цепочке поставок?
12. Есть ли сценарий аварийного отзыва доступа?
Главный принцип прост: промпт объясняет агенту, что желательно сделать, но не должен определять границы допустимого. Эти границы задаются песочницей, RBAC, сетевыми политиками, прокси, аудитом и процедурами аварийного отключения. Только сочетание этих механизмов позволяет превратить автономного агента из экспериментального скрипта в управляемый production-компонент.