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

Зміст:

• Чим ризикує сервер, коли 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
adduser dev
usermod -aG kvm,docker dev
su - dev

Далі увійдіть у свій 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