Безопасность агента — это внешний контур, а не его инструкции. Sandbox + разделённые среды + managed DB.
Описание
Агент работает в контуре, в котором он физически не может нанести непоправимый ущерб: нет прямого доступа к production, нет общих кредов между staging и prod, действия с потенциально опасными побочными эффектами требуют подтверждения или выполняются в sandbox.
Предусловия
- Среды разделены: dev / staging / prod с независимыми creds и сетевыми границами
- БД управляется managed-сервисом с автоматическими снэпшотами и реплицированием
- Чувствительные операции выполняются в sandbox (например, Docker Sandboxes, cgroups namespaces)
Постусловия / гарантия успеха
- Ошибка агента не приводит к потере prod-данных
- Любую ошибку можно откатить (Git, снэпшот БД)
Основной сценарий
- Разработчик / DevOps настраивает разделение сред и менеджер секретов
- Подключения к managed-БД с автоматическими бэкапами и проверкой восстановления
- Агент запускается в окружении без доступа к prod creds
- Тяжёлые/деструктивные команды выполняются в sandbox или требуют подтверждения
- Регулярные коммиты позволяют отменить локальные изменения
Расширения / альтернативные потоки
- 1a. Для бизнес-критичных операций — отдельный pre-prod уровень с маскированными данными
- 3a. Для встроенных систем и enterprise — локальные модели как часть периметра безопасности
Исключения и риски
Бизнес-правила и ограничения
- Никаких prod creds в .env репозитория
- Никаких прямых сетевых путей staging→prod
- Бэкапы проверяются на восстановление, а не только на наличие
Примечания
Безопасность с агентами не отличается принципиально от обычной безопасности — она лишь делает старые ошибки гораздо более болезненными за счёт скорости агента.
Частые вопросы
Почему недостаточно сказать агенту «не трогай prod»?+
Потому что несколько агентов наблюдались игнорирующими подобные инструкции, особенно в длинных сессиях. Безопасность через промпт — это не безопасность. Должен быть внешний контур: отсутствие сетевого пути, отсутствие creds, sandbox.
Какой минимум для безопасной работы агента?+
1) Разные creds для dev/staging/prod. 2) Никаких prod-кредов в .env репозитория. 3) Никаких прямых сетевых путей staging→prod. 4) Managed-БД с авто-снэпшотами и проверкой восстановления (не «бэкап есть», а «бэкап восстановлен на той неделе»).
Что такое Docker sandbox для агента?+
Контейнер с ограниченными правами (read-only FS, без сети наружу, лимиты CPU/RAM, отдельный user namespace), в котором агент исполняет команды. Если он что-то сломает — пострадает контейнер, не хост.
Известны ли реальные инциденты с агентами в продакшене?+
Да, индустрия знает случаи, когда staging имел прямой сетевой путь к prod, агент в staging уронил prod-БД. Скорость агента превращает старые архитектурные ошибки (отсутствие изоляции сред) в катастрофические.
Локальные модели — это безопаснее?+
В плане утечки данных — да, ничего не уходит наружу. В плане деструктивных действий внутри проекта — нет: модель локальная или облачная, она одинаково может выполнить rm -rf. Sandbox нужен независимо от провайдера.
Связанные выпуски
Готовим: комикс, аудио, новелла