Статья также доступна на украинском (перейти к просмотру).

Содержание:

• Чем рискует сервер, когда AI-агент имеет полный доступ

• Что такое Docker Sandbox: изоляция AI-агентов на уровне microVM

• Установка Docker и Claude Code на сервер

• Проверка KVM: запустится ли песочница на вашем VPS

• Команда sbx: запуск агента в песочнице

• Если KVM нет: агент в обычном Docker-контейнере

• Настройка permissions Claude Code

• Git diff и git status: контроль сделанных изменений

• Типичные ошибки

Claude Code — это CLI-инструмент от Anthropic, который может читать код, редактировать файлы и выполнять команды прямо в терминале. На рабочем компьютере разработчика это удобно: агент помогает быстрее находить ошибки, писать код и запускать тесты. Но на VPS такое же удобство легко превращается в риск.

На сервере обычно хранятся не только файлы одного проекта. Рядом могут находиться production-конфиги, файлы .env с доступами к базе данных, SSH-ключи, дампы, файлы других сайтов и служебные настройки системы. Если запустить AI-агента без ограничений или, что еще хуже, от root, он фактически получит доступ ко всему, что доступно этому пользователю. В такой ситуации ошибочная команда, нечеткий промпт или неправильное подтверждение действия могут повредить конфигурацию, удалить важные файлы или открыть доступ к секретам.

В этой статье разберем, почему Claude Code не стоит запускать напрямую на VPS с полным доступом к системе, и покажем более безопасный подход — запуск через Docker Sandbox и sbx. Идея проста: AI-агент должен видеть только директорию нужного проекта, а не весь сервер.

Команды в статье проверены на VPS с Ubuntu 24.04. Версии Docker, Claude Code и sbx, которые использовались при подготовке материала, приведем отдельно, чтобы вы могли повторить примеры в похожем окружении.

Среда для проверки команд

Примеры в статье проверены на VPS с Ubuntu 24.04. На момент подготовки материала использовались следующие версии: Docker 29.1.3, Claude Code 2.1.201, sbx v0.34.0. Если у вас другие версии, отдельные команды или сообщения в терминале могут незначительно отличаться.

Чем рискует сервер, когда AI-агент имеет полный доступ

Главный риск: агент, запущенный от root напрямую на сервере, технически способен прочитать и изменить любой файл системы, и никакая инструкция в промпте этому не помешает. Слабое место — не злые намерения модели, а ее непредсказуемость. Anthropic в собственной документации по безопасности описывает риск prompt injection: вредоносная инструкция, спрятанная в README, комментарии к коду или выводе команды, может подтолкнуть агента к действиям, о которых вы не просили.

Что оказывается под угрозой на типичном сервере:

• секреты в  .env файлах — пароли к базам данных, API-токены платежных систем;

• SSH-ключи в  ~/.ssh, через которые можно добраться до других серверов;

• конфигурация веб-сервера, SSL-сертификаты, панели управления;

• соседние проекты и их базы данных;

• системные файлы — агент с правами root может изменить что угодно.

Последствия — от испорченного конфига до компрометации сервера и утечки данных клиентов. Безопасность VPS в таком сценарии держится лишь на надежде, что модель «будет вести себя хорошо». Для сервера с реальными проектами этого мало: нужны рамки, которые задает инфраструктура, а не промпт.

Что такое Docker Sandbox: изоляция AI-агентов на уровне microVM

Docker Sandbox — это официальный инструмент Docker для запуска AI-агентов в изолированной среде: каждый агент работает в отдельной легкой виртуальной машине (microVM) с собственным ядром, файловой системой и приватным Docker-демоном. С хостом sandbox-среда делит только одно — каталог проекта, который вы явно подключили.

Это более глубокая изоляция, чем обычная контейнеризация: контейнер делит ядро с хостом, а microVM имеет собственное. Ключевые механизмы защиты, описанные в Docker Docs:

• filesystem isolation — агент видит только рабочую папку проекта, остальная файловая система сервера для него не существует;

• network isolation — сетевые политики определяют, к каким доменам агент может обращаться;

• отдельное ядро — даже уязвимость контейнерной изоляции не открывает доступ к хосту;

• приватный Docker-демон — агент может собирать и запускать контейнеры внутри microVM, не касаясь контейнеров сервера.

Именно поэтому запуск Claude Code на VPS через Docker Sandbox надежнее любых ограничений на уровне самого агента: даже если модель ошибется или наткнется на вредоносную инструкцию, границы microVM она не перейдет. Изоляция AI-агентов становится свойством среды, а не пожеланием в промпте.

Установка Docker и Claude Code на сервер

Подключитесь к серверу через SSH и установите Docker из репозитория Ubuntu:

Bash
apt update
apt install docker.io

Сам агент устанавливается через npm (требуется Node.js 18 или новее):

Bash
apt install nodejs npm
npm install -g @anthropic-ai/claude-code

Команда sbx поставляется отдельным пакетом docker-sbx из официального репозитория Docker:

Bash
curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
echo "deb [signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu noble stable" > /etc/apt/sources.list.d/docker.list
apt update
apt install docker-sbx

Проверьте, что все установилось:

Bash
docker --version
claude --version
sbx version

Docker 29.1.3, Claude Code 2.1.201 и sbx v0.34.0 установлены на VPS с Ubuntu 24.04.

Проверка KVM: запустится ли песочница на вашем VPS

Песочница — это полноценная microVM, поэтому серверу нужна аппаратная виртуализация KVM. Проверьте ее наличие до начала работы:

Bash
ls -la /dev/kvm
egrep -c '(vmx|svm)' /proc/cpuinfo
systemd-detect-virt

На этом VPS /dev/kvm отсутствует, а счетчик флагов vmx/svm равен нулю — вложенная виртуализация отключена.

Если первая команда показывает устройство /dev/kvm, а вторая возвращает число больше нуля — все готово. Если же устройства нет (на скриншоте сервер сам является KVM-гостем, а вложенная виртуализация отключена), у вас два пути: уточнить у хостера, можно ли включить nested virtualization (нам поддержка включила ее по запросу), или воспользоваться запуском в обычном контейнере, который описан ниже. По умолчанию на виртуальных серверах FREEhost вложенная виртуализация отключена — KVM на VPS нет «из коробки». По запросу поддержка может изменить конфигурацию сервера, но при условии, что клиент осознает риски.

Команда sbx: запуск агента в песочнице

Команда sbx run claude создает песочницу, загружает образ агента и открывает привычный интерфейс Claude Code — но уже внутри microVM. Сразу важное правило: sbx не запускают от root — VMM-компонент откажется стартовать, ведь root-запуск позволил бы гостевой машине навредить хосту. Создайте обычного пользователя и добавьте его в группы kvm и docker:

Bash
ls -la /dev/kvm
egrep -c '(vmx|svm)' /proc/cpuinfo
systemd-detect-virt

Далее войдите в свой Docker-аккаунт:

Bash
sbx login

Теперь перейдите в каталог проекта и запустите агента:

Bash
cd ~/my-project
sbx run claude

При первом запуске sbx загрузит образ и создаст песочницу, название которой совпадает с именем каталога. Агент будет видеть только файлы этого проекта. Управление песочницами:

• sbx ls  — список песочниц и их статус;

• sbx stop my-project — остановить песочницу;

• sbx rm my-project — удалить ее;

• sbx policy ls — посмотреть сетевые правила (network isolation в действии).

Практический совет:sbx run claude можно выполнить для нескольких проектов параллельно — каждый получит собственную microVM, и агенты не будут мешать друг другу и видеть чужие файлы.

Если KVM нет: агент в обычном Docker-контейнере

Обычный контейнер дает более слабую изоляцию, чем microVM: ядро общее с хостом, поэтому уязвимость ядра остается теоретическим риском. Тем не менее, это рабочий компромисс для VPS без вложенной виртуализации — и значительно более безопасный вариант, чем прямой запуск на хосте. Безопасность VPS не должна зависеть от того, доступен ли на сервере KVM. Запустите контейнер, подключив только директорию проекта:

Bash
cd ~/my-project
docker run -it --rm -v "$PWD":/workspace -w /workspace node:22-slim bash
npm install -g @anthropic-ai/claude-code
claude

Проверим изоляцию: попробуем из контейнера добраться до файлов хоста. Контейнер видит только app.js и package.json; файл /root/secrets.env и SSH-ключи хоста для него не существуют.

После запуска команды claude открывается привычный интерфейс — агент работает с файлами проекта точно так же, как на локальной машине, только теперь его мир ограничивается каталогом /workspace.

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

Важный нюанс: системные каталоги, которые агент перечисляет на скриншоте (/etc, /usr, /root), принадлежат контейнеру, а не серверу. Это минимальный одноразовый Linux из образа, который исчезнет вместе с контейнером. Реальный /root сервера с вашими проектами и SSH-ключами оттуда невидим — убедиться легко, сравнив ls /root на хосте и внутри контейнера.

Что нельзя передавать в контейнер:

• .env файлы с боевыми паролями — используйте тестовые значения или отдельный токен с минимальными правами;

• SSH-ключи и папку ~/.ssh — агенту они не нужны;

• /var/run/docker.sock — монтирование Docker-сокета сводит изоляцию на нет, так как фактически дает права root на хосте;

• каталоги других проектов — подключайте только тот, с которым работаете сейчас.

Дополнительные папки со справочными материалами монтируйте в режиме read-only: -v /opt/docs:/docs:ro. Так права доступа запрещают запись даже в пределах разрешенного.

Настройка permissions Claude Code

Изоляция среды не отменяет внутренних разрешений агента: настройка permissions Claude Code определяет, какие действия он выполняет сразу, какие — после подтверждения, а какие вообще запрещены. В файле .claude/settings.json проекта задайте правила allow, ask и deny:

JSON
{
  "permissions": {
    "allow": ["Bash(npm run test:*)"],
    "ask": ["Bash(git push:*)"],
    "deny": ["Read(./.env)", "Read(./secrets/**)"]   } }

Правило deny для .env файлов — обязательный минимум: даже в пределах подключенного каталога агент не будет читать секреты. Это второй рубеж защиты после контейнеризации. Подробный синтаксис правил описан в документации Anthropic, а флаг --dangerously-skip-permissions, который отключает все подтверждения, безопасно включать только внутри песочницы.

Git diff и git status: контроль сделанных изменений

Последний рубеж безопасности — просмотр изменений до того, как они попадут в продакшн. Команда git status покажет, какие файлы агент создал или изменил, а git diff — что именно изменилось в каждом из них:

Bash
git status
git diff

Рабочая схема проста: агент работает в отдельной ветке, вы просматриваете git diff перед слиянием, а в основную ветку попадает только проверенный код. Так ошибочное изменение не проскочит незамеченным, а история коммитов подскажет, что именно делал агент.

Типичные ошибки

• Запуск агента от root прямо на сервере «на пять минут» — именно так секреты и попадают в чужие руки.

• Запуск sbx от root — VMM откажется стартовать; команды песочницы выполняйте от обычного пользователя с группой kvm.

• Монтирование всей домашней папки (-v /root:/workspace) вместо каталога проекта — изоляция превращается в формальность.

• Боевые секреты в рабочей папке проекта — вынесите их за пределы каталога или в менеджер секретов.

• --dangerously-skip-permissions без песочницы — этот режим создан для изолированных сред, не для хоста.

• Работа без git — без истории изменений вы не узнаете, что именно сделал агент и что нужно откатить.

Что дальше?

Схема безопасной работы состоит из трех уровней: песочница или контейнер как граница среды, правила permissions как внутренние разрешения и git diff как финальная проверка. Вместе они перекрывают большинство реальных рисков — от случайного rm -rf до prompt injection. Безопасность VPS при этом не зависит от «благоразумия» модели: границы задает инфраструктура.

Подписывайтесь на наш Telegram-канал https://t.me/freehostua, чтобы быть в курсе новых полезных материалов

Смотрите наш канал YouTube https://www.youtube.com/freehostua.

Мы в чем-то ошиблись, или что-то пропустили?

Напишите об этом в комментариях, мы с удовольствием ответим и обсудим ваши замечания и предложения.

Дата: 09.07.2026 Автор: Илья Пигович #ai-agents#claude-code#cloud#docker#programming#security#ubuntu

Голосование 1 2 3 4 5