ИИ-агенты в песочнице: что Docker изолирует, а что нет

Docker может ограничить ущерб от ИИ-агента, но сам по себе контейнер ещё не граница безопасности. Благодаря пространствам имён (namespaces) процессу видна лишь часть файлов, других процессов и сетей. Контрольные группы (cgroups) могут ограничивать ресурсы, если вы их настроите. Подключённые папки хоста (bind mounts), сокет Docker, расширенные привилегии (capabilities), привилегированный режим, устройства, секреты и сетевые настройки могут снова открыть доступ к хосту или к другим системам.

noHuman Team — это нативное приложение для macOS и Windows, а не песочница для агентов на основе Docker. О его компромиссах в безопасности — ниже. Рекомендации по Docker в этой статье пригодятся, если вы сами собираете или запускаете агента в контейнере.

Зачем ИИ-агентам границы

Агент может записывать файлы, запускать менеджеры пакетов, выполнять сгенерированный код, открывать недоверенные страницы и обращаться к внешним сервисам. Каждая такая возможность — ещё один путь для ошибок и вредоносного ввода.

Типичные риски:

• Слишком широкая команда очистки удаляет больше файлов, чем планировалось
• Зависимость или скачанный скрипт читает доступные секреты
• Содержимое веб-страницы пытается увести агента от задачи через внедрение промпта (prompt injection)
• Неудачная сборка уходит в цикл повторов и расходует ресурсы
• Агент отправляет конфиденциальные материалы не тому сервису

Docker может ограничить часть этих путей. Он не решает, какой инструкции можно доверять, не убирает секреты, которые вы сами передали, и не защищает путь хоста, который вы намеренно подключили на чтение и запись.

Что на самом деле даёт контейнер Docker

В Linux контейнеры опираются на возможности ядра, например на пространства имён и контрольные группы. На macOS и Windows Docker Desktop обычно запускает контейнеры Linux внутри виртуальной машины, которой управляет сам. Поэтому точная граница зависит от хоста, среды выполнения и конфигурации.

В обычной конфигурации у контейнера может быть:

• Файловая система, собранная из образа и записываемого слоя контейнера
• Собственное пространство имён процессов
• Отдельное сетевое пространство имён
• Настроенный набор привилегий Linux (capabilities)
• Ограничения процессора и памяти, если лимиты заданы

По умолчанию эти механизмы сужают то, что процесс видит и может делать. Но отдельного физического компьютера они не заменяют, и не все из них по умолчанию включены или строги.

Host or Docker Desktop VM
└── Container boundary
    ├── image and writable layer
    ├── namespaced processes
    ├── container network
    ├── explicitly mounted host paths
    ├── injected secrets and environment variables
    └── configured capabilities and devices

Именно в нижней половине этого списка и рушатся многие предположения о безопасности.

Какие пути доступа важны

Подключённые папки и тома

Подключённая папка (bind mount) открывает контейнеру путь на хосте. Если она подключена на чтение и запись, агент может изменять или удалять в ней файлы. Подключение только для чтения снижает риск записи, но данные всё равно доступны любому процессу в контейнере.

Подключайте минимум: только ту папку, которая нужна для задачи. Не подключайте домашнюю папку, папку с учётными данными или слишком широкое рабочая папка только ради удобства.

services:
  agent:
    volumes:
      - ./task-workspace:/workspace:rw
      - ./reference-data:/reference:ro

Поэтому общая рабочая папка — вовсе не герметичная «почтовая щель», а настоящий путь доступа: проверяйте, что в него входит и в каком режиме он подключён.

Сокет Docker

Если подключить /var/run/docker.sock, контейнер сможет управлять демоном Docker. Во многих установках так можно запускать привилегированные контейнеры или подключать пути хоста. Считайте доступ к сокету Docker высокой привилегией, а не обычным взаимодействием между контейнерами.

Привилегированный режим, привилегии и устройства

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

Запуск от имени обычного пользователя, а не root, — полезный дополнительный рубеж защиты. Но он не делает безопасным привилегированный контейнер или контейнер с опасными подключениями.

Доступ к сети

Сеть контейнера по умолчанию часто разрешает исходящие соединения. В зависимости от платформы и сети контейнер может также достучаться до других контейнеров, служб хоста или устройств в локальной сети.

Определите, к чему агенту действительно нужен доступ. Разнесите нагрузки по подходящим сетям, а если важно ограничить адреса назначения, контролируйте исходящий трафик за пределами Docker. Одна лишь сеть контейнера не заменяет полноценный межсетевой экран для исходящих соединений.

Секреты и переменные окружения

Считайте, что любой секрет внутри контейнера доступен агенту и коду, который он запускает. Выбирайте краткоживущие учётные данные с узкими правами. Не рассчитывайте, что контейнер предотвратит утечку, если у процесса есть и секрет, и исходящий доступ к сети.

Лимиты ресурсов уменьшают последствия, но не сводят риск к нулю

Лимиты процессора и памяти могут не дать одной нагрузке израсходовать все настроенные ресурсы. Но их нужно задать: Docker сам не подбирает безопасные лимиты для агента.

services:
  agent:
    mem_limit: 2g
    cpus: 2

Проверьте синтаксис и поведение на своих версиях Compose и среды выполнения. Учитывайте также лимиты процессов, рост хранилища, ротацию журналов и тайм-ауты. Лимит памяти не защищает от переполнения диска и от дорогих обращений к внешним API.

Хост всё равно может тормозить под нагрузкой, особенно когда несколько контейнеров работают в одной виртуальной машине Docker Desktop. Проверяйте лимиты на тех компьютерах, где будут работать агенты.

Как безопаснее запускать агентов в контейнерах

Это список для проверки, а не сертификат:

1. Используйте отдельный минимальный образ. Фиксируйте версии зависимостей и пересобирайте образ из проверенных источников.
2. Запускайте от имени обычного пользователя. Где позволяет совместимость, рассмотрите пространства имён пользователей или Docker без root (rootless).
3. Избегайте привилегированного режима. Отключайте лишние привилегии и не открывайте устройства хоста.
4. Никогда не подключайте сокет Docker, если только задача прямо не требует управлять демоном. Если требует, изолируйте такую нагрузку отдельно.
5. Держите подключения узкими. Для справочных материалов лучше подходит доступ только для чтения, а для результатов — отдельная рабочая папка с правом записи.
6. Задайте лимиты на ресурсы и выполнение. Учтите память, процессор, процессы, хранилище, журналы, время работы и внешние расходы.
7. Ограничьте сетевые пути. Разрешайте только те адреса назначения и узлы, которые нужны рабочему процессу.
8. Используйте учётные данные с узкими правами. Меняйте их регулярно и не держите долгоживущие секреты в образах и файлах окружения.
9. Обновляйте хост, Docker, образы и зависимости. Побеги из контейнеров и уязвимости в цепочке поставок вполне возможны.
10. Ведите журнал действий и просматривайте его. Сохраняйте команды, вызовы инструментов, одобрения и значимые сетевые события.

Docker, виртуальные машины и более надёжные песочницы

Контейнеры и виртуальные машины решают разные задачи.

Если нужно выполнять враждебный код или обеспечить более строгую границу между арендаторами, используйте виртуальную машину или изолированную среду выполнения. Внутри такой границы Docker по-прежнему годится для упаковки.

Контейнеры и виртуальные машины дают неравноценные границы безопасности. Важны модель угроз, конфигурация, платформа хоста и среда выполнения.

Как устроены границы в noHuman Team

Сейчас noHuman Team запускает каждого noHuman как нативный процесс под управлением приложения на macOS или Windows. Полной изоляции файловой системы от вашей учётной записи оно не обещает.

Средства защиты рассчитаны на разные риски:

• Для подключений Claude и ChatGPT, которыми управляет шлюз, сотрудники работают с заглушкой вместо настоящих учётных данных, а авторизацию у провайдера добавляет локальный шлюз
• У агентов есть своё рабочее состояние и профили браузера, а совместная работа идёт через рабочая папка, которое выбираете вы
• Одобрение рискованных действий зависит от настроенного уровня самостоятельности
• Бюджеты для каждого агента и лимиты ходов ограничивают работу без присмотра

При локальном входе и резервных подключениях настоящие учётные данные могут храниться в файлах сотрудника. Нативному процессу по-прежнему доступны данные, разрешённые учётной записи операционной системы, а отдельные папки песочницу для файловой системы не создают. Тщательно выбирайте рабочая папка, проверяйте разрешения и, если нужна жёсткая граница файловой системы, используйте виртуальную машину или другую песочницу. Как хранятся учётные данные и кто получает к ним доступ, объясняет руководство по аккаунтам ИИ-сервисов.

Как выбрать уровень изоляции

Задайте себе вопросы:

• Запускает ли агент код из открытого интернета?
• Какие данные хоста ему нужно читать или записывать?
• Какие секреты он получит?
• Может ли он обращаться к внутренним сервисам или локальной сети?
• Что произойдёт, если вредоносным окажется его процесс, зависимость или инструкция?
• Нужна ли вам защита от ошибок, от враждебного кода или от того и другого?

Для доверенной сборки в узком рабочей папке может подойти контейнер с усиленной защитой. Для недоверенного кода рядом с чувствительными данными хоста используйте более надёжную границу и уберите ненужные соединения.

Главное

• Docker по умолчанию уменьшает доступ, но реальную границу определяет конфигурация
• Подключённые папки открывают данные хоста, а подключение на чтение и запись позволяет менять файлы хоста
• Доступ к сокету Docker, привилегированный режим, устройства, привилегии, сети и секреты требуют отдельной проверки
• Лимиты ресурсов нужно настраивать, и они закрывают не все способы исчерпать ресурсы
• noHuman Team — нативное приложение для macOS и Windows; если этого требует модель угроз, добавьте более сильную изоляцию отдельно

Частые вопросы

Достаточно ли безопасен Docker для ИИ-агента?

Он может подойти для конкретной модели угроз, если защита контейнера усилена и за ним следят. Но сам факт запуска в контейнере безопасности не гарантирует. Проверьте подключённые папки, доступ к демону, привилегии, сетевые пути, секреты, лимиты и обновления хоста.

Может ли контейнер Docker получить доступ к файлам хоста?

Да, если подключены пути хоста или другой привилегированный путь даёт доступ к хосту. Обычный контейнер по умолчанию не может просматривать произвольные пути хоста, но подключённая папка открывает ровно то, что вы настроили, с заданными правами на чтение или запись.

Может ли контейнер достучаться до моей локальной сети?

Часто да. Поведение зависит от платформы и настроек сети. Не путайте исходящий доступ по умолчанию с ограниченным списком разрешённых адресов. Проверьте нужную вам сетевую политику на практике и обеспечьте её соблюдение.

Может ли процесс сбежать из контейнера Docker?

Побеги из контейнеров возможны из-за уязвимостей среды выполнения или ядра и из-за опасной конфигурации. Обновляйте стек, сокращайте привилегии и используйте более надёжный слой изоляции, если последствия побега неприемлемы.

Контейнеры Docker так же безопасны, как виртуальные машины?

Как правило, нет. У виртуальной машины отдельное гостевое ядро, а обычный контейнер Linux работает на одном ядре с хостом или с виртуальной машиной Docker Desktop. Что выбрать, зависит от модели угроз и ограничений эксплуатации.

Запускает ли noHuman Team агентов в Docker?

Нет. Нынешняя версия запускает на macOS и Windows нативные процессы под своим управлением. В ней есть средства контроля учётных данных, одобрений, рабочей папки, бюджета и выполнения, но изоляцию файловой системы на уровне контейнера она не обещает.

Хотите нативную локальную команду с понятными средствами одобрения? Скачайте noHuman Team для macOS или Windows. Если модель угроз требует границы контейнера или виртуальной машины, добавьте её явно и не рассчитывайте, что её обеспечит нативное приложение.