Як дати AI-агенту одноразову VM для коду

Чому одноразова VM краща за ваш ноутбук

Надайте агенту для програмування одноразову VM. У найгіршому випадку він знищить машину, яку можна відновити за десять хвилин. Агент і надалі отримує root, встановлює пакети та запускає набір тестів без запиту дозволу на кожен крок. Відмінність полягає в тому, де саме виникають наслідки. На ноутбуці агент має спільний домашній каталог із вашими ключами SSH, профілем браузера, файлами .env та всіма іншими репозиторіями, які ви коли-небудь клонували. На одноразовому сервері він має оболонку, робочу копію репозиторію і більше нічого, що варто викрадати.

Це весь аргумент. Він стосується асиметрії, а не ймовірності. Обережний агент на обережно налаштованому ноутбуці майже завжди працює без проблем. Але якщо одного разу щось піде не так, наслідком буде не невдалий commit. Доведеться відновлювати систему з резервної копії, якщо вона у вас є.

Визначте радіус ураження, перш ніж його обговорювати

Радіус ураження — це сукупність об’єктів, до яких процес може отримати доступ. Для агента, який працює від імені вашого звичайного користувача на вашій звичайній машині, ця сукупність більша, ніж уявляє більшість людей.

До неї належить ~/.ssh/id_ed25519, який зазвичай не зашифрований, тому що вам набридло вводити парольну фразу. До неї належать ~/.aws/credentials і ~/.config/gh/hosts.yml, які за задумом містять звичайний текст. До неї належить кожен сусідній репозиторій у ~/code, зокрема репозиторії з рядками підключення до production у локальному env-файлі. До неї також належить історія shell, у якій зберігаються токени, вставлені вами одного разу. Вона також охоплює мережу, до якої підключений ваш ноутбук. Це часто домашня або офісна мережа з неавтентифікованими сервісами.

Для цього не потрібен зловмисний агент. Достатньо однієї впевнено неправильної команди. rm -rf із невстановленою змінною, яка розгортається в /, git clean -xfd у неправильному каталозі, docker system prune -af --volumes, який видаляє разом із собою вашу локальну базу даних, або корисливого chmod -R 777 у домашньому каталозі. Агентів навчають на тому самому інтернеті, який навчив цих команд усіх інших.

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

Розрахунок витрат нудний. У цьому і полягає його сенс

Невеликий VPS коштує кілька доларів на місяць. Відновлення робочого ноутбука розробника займає день. І це найкращий сценарій: ви одразу помітили проблему та мали резервну копію.

Порахуйте за власними даними. Візьміть свою погодинну ставку та помножте її на кількість годин, потрібних для повторного встановлення операційної системи, відновлення домашнього каталогу, ротації ключа SSH, ротації персонального токена доступу та повторного клонування двадцяти репозиторіїв. Порівняйте отриману суму з вартістю найменшого сервера у вашого провайдера за дванадцять місяців. Беззбитковість настає менш ніж за один інцидент протягом кількох років. Інцидент не має бути катастрофічним, щоб перевищити цей поріг. Один втрачений день через пошкоджене локальне середовище вже покриває вартість сервера за рік.

Друга частина розрахунку — це знімки. Знімок перед ризикованим запуском змінює наслідки невдалого результату: замість «відновлювати все з нуля» можна «відкотити зміни та спробувати інший prompt». На ноутбуці, з якого ви це читаєте, такої можливості немає, оскільки неможливо створити знімок машини, яку ви одночасно використовуєте як робоче місце.

Середовище станом на July 2026

Є три коректні відповіді на запитання «де має працювати агент». Вони мають однаковий компроміс між двома чинниками: міцністю межі ізоляції та обсягом налаштувань, який ви готові прийняти.

Локальна мікровіртуальна машина. Інструменти цієї категорії запускають повноцінну віртуальну машину на вашому обладнанні, монтують у неї ваш репозиторій і надають агенту права root усередині неї. clawk є актуальним прикладом. Його основна ідея повністю відповідає тезі цього допису: надайте агентам для написання коду одноразову Linux VM, а не ваш ноутбук. Станом на July 2026 цей інструмент підтримує macOS 14 і новіші версії на Apple silicon, а також має експериментальну підтримку Linux через Firecracker. Його можна встановити за допомогою brew install clawkwork/tap/clawk. Виконайте clawk у репозиторії, щоб запустити ізольоване середовище та підключити агента, clawk down — щоб зупинити його, а clawk destroy — щоб видалити його. Межу ізоляції забезпечує гіпервізор, тому вона є міцною. Обмеження полягає в тому, що VM працює на машині, яку ви носите із собою. Вона використовує вашу оперативну пам’ять і зупиняється, коли ви закриваєте кришку ноутбука.

Контейнер. Docker — це варіант, який більшість користувачів уже мають встановленим, і він справді корисний.

docker run --rm -it -v "$PWD:/work" -w /work --network none ubuntu:24.04 bash

--rm видаляє контейнер після завершення роботи, а --network none повністю вимикає для нього мережу. Це хороший типовий варіант для збирання або виконання тестів. Важливо розуміти, чого це не забезпечує: контейнер використовує ядро хостової системи, тому вразливість ядра може дозволити вийти з контейнера. Межа ізоляції також зникає, щойно ви додаєте --privileged або монтуєте /var/run/docker.sock, щоб агент міг «використовувати Docker». Монтування Docker socket у контейнер фактично надає цьому контейнеру права root на хості.

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

Шаблон VPS: надайте агенту окремого користувача

Почніть із захищеного сервера. У матеріалі перші десять хвилин на новому VPS описано компоненти, які не залежать від агента: оновлення, вхід не під root, SSH лише за ключем і firewall.

Потім створіть обліковий запис, призначений лише для агента. Тоді помилка в ньому не зможе вплинути на інші компоненти сервера.

sudo adduser --disabled-password --gecos "" agent
sudo install -d -m 700 -o agent -g agent /home/agent/work
sudo -u agent -H bash -lc 'id; ls -la ~'

--disabled-password означає, що пароль неможливо вгадати. Доступ до облікового запису здійснюється через sudo -u agent або SSH-ключ. Зверніть увагу, що agent навмисно не входить до групи sudo. Користувач із sudo має права root, а root може читати файли всіх інших користувачів. У такому разі створене розмежування є лише формальним. Якщо агенту справді потрібно встановлювати пакети, це підстава виділити для нього окремий сервер, а не надавати sudo на спільному сервері. Загальні правила описано в матеріалі мінімальні привілеї для користувачів Linux на VPS.

Перевірте межу ізоляції, перш ніж довіряти їй. Увійшовши як користувач agent, спробуйте прочитати файл, що належить цьому обліковому запису:

sudo -u agent cat /home/you/.ssh/id_ed25519

Ви маєте побачити cat: /home/you/.ssh/id_ed25519: Permission denied. Якщо замість цього відображаються ключові матеріали, домашній каталог має режим 755, і ізоляція ще не працює належним чином. Виправте це за допомогою sudo chmod 700 /home/you.

Не зберігайте облікові дані на машині взагалі

Призначення одноразової машини втрачається, якщо скопіювати на неї робочі секрети. Правило просте: на цій машині не повинно бути облікових даних, які вам було б шкода відкликати сьогодні.

Для git переспрямовуйте свій SSH-агент замість копіювання ключа. Приватний ключ залишається на вашому ноутбуці, а через з’єднання передаються лише запити на створення підпису.

ssh -A agent@203.0.113.10
ssh -T git@github.com

Друга команда має повернути відповідь Hi yourname! You've successfully authenticated, but GitHub does not provide shell access. Це підтверджує, що git push працюватиме без файлу ключа на сервері. Після цього виконайте на машині ls -la ~/.ssh і переконайтеся, що приватного ключа в ній немає.

Переспрямування агента має один важливий недолік, який слід чітко усвідомлювати: поки ви підключені, будь-хто, хто має root на цьому сервері, може використати переспрямований сокет для автентифікації від вашого імені. На сервері, де єдиний інший користувач — це ви, такий компроміс прийнятний. На спільній машині — ні. У такому разі краще використовувати ключ розгортання з обмеженням доступу до одного репозиторію. Варіанти описано в розділі Основи керування SSH-ключами.

Для ключів API надайте агенту окремий ключ із власним лімітом витрат і зберігайте його у файлі, власником якого є користувач agent, з режимом доступу 600. Коли машину буде знищено, відкличте цей ключ, а не намагайтеся з’ясувати, чи не стався витік. Відстеження витрат на моделі окремо для кожного ключа також дає змогу зберігати передбачуваними показники в розділі Контроль витрат AI-агента на VPS.

Обмежте мережевий доступ агента

Ізоляція файлової системи — лише половина межі. Друга половина — вихідний трафік: до яких ресурсів процесу дозволено звертатися. Linux може фільтрувати вихідний трафік за користувачем, який його створив. Це точно відповідає цьому сценарію.

sudo iptables -A OUTPUT -m owner --uid-owner agent -o lo -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p tcp --dport 443 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -j REJECT

Правила обробляються по порядку, тому останнє правило REJECT перехоплює все, що не дозволили попередні рядки. Перевірте це від імені агента:

sudo -u agent curl -sS -m 5 http://example.com

Команда має завершитися помилкою curl: (7) Failed to connect to example.com port 80: Connection refused, оскільки правило відхилення одразу повертає відповідь, а не залишає з’єднання в стані очікування. HTTPS-запит до того самого хоста має й надалі виконуватися успішно.

Є два важливі обмеження. По-перше, ці правила втрачаються після наступного перезавантаження, якщо їх не зберегти за допомогою sudo apt install -y iptables-persistent, а потім sudo netfilter-persistent save. По-друге, фільтрація виконується за портами й адресами, а не за іменами. Правило, яке дозволяє порт 443, дозволяє доступ до будь-якого HTTPS-хоста в інтернеті. Цього достатньо для доступу до API моделі, але також достатньо для доступу до pastebin. Справжній список дозволених доменів потребує проксі, через який проходитиме трафік і який аналізуватиме запитане ім’я хоста. Для більшості конфігурацій одного розробника це зайва складність. Заявляйте лише про те, що справді налаштовано: контроль вихідного трафіку на рівні портів на машині, яку ви готові втратити.

Повернення до чистого стану між завданнями

Чистий стан для кожного завдання — недооцінена перевага. Агент, який витратив три години на попередню заявку, міг залишити встановлені пакети, частково застосовані міграції, застарілий node_modules і робоче дерево git зі змінами, які ніхто не перевірив. Наступне завдання успадковує все це, а ви витрачаєте час на перевірку, з'ясовуючи, який безлад належить до якого запуску.

Простий варіант — створювати свіжу копію репозиторію для кожного завдання.

sudo -u agent -H bash -lc 'rm -rf ~/work/repo && git clone git@github.com:you/repo.git ~/work/repo'

Надійніший варіант — один раз створити знімок у провайдера одразу після налаштування машини й до того, як до неї отримає доступ будь-який агент. Відновлення цього знімка повертає всю систему разом із пакетами до відомого стану. Більшість провайдерів надають цю функцію в панелі керування або через API, а не у вигляді команди на самій машині, тому точні кроки залежать від вашого провайдера. Знімок потрібно створити, поки машина ще не зазнала змін.

Зберігайте все важливе за межами одноразової машини. Зазвичай це означає надсилати гілки до віддаленого репозиторію, а не накопичувати їх локально. Якщо на машині все ж залишиться щось важливе для вас, належним чином створіть резервну копію за допомогою резервних копій restic на VPS. Машину можна безпечно знищувати лише тоді, коли її знищення справді не створює проблем.

Якщо вам потрібно кілька ізольованих середовищ без оплати кількох серверів, один потужніший VPS може безпосередньо розміщувати гостьові VM. У матеріалі Вкладена віртуалізація на VPS описано принцип роботи, зокрема перевірку того, чи дозволяє її ваш провайдер.

Коли ноутбук із належним захистом справді підходить

Будьте чесні щодо цього, адже перебільшення переваг ізоляції призводить до того, що люди перестають слухати.

Якщо ви перевіряєте кожну команду перед її виконанням, ноутбук підходить. Запит на надання дозволу є реальним засобом контролю, а в матеріалі безпечний запуск Claude Code на сервері розглянуто, що саме блокує кожен його рівень. Якщо ви працюєте лише з одним репозиторієм і на комп’ютері ніде немає облікових даних для production, область потенційного впливу вже невелика. Якщо сеанси агента короткі та контрольовані, період потенційного впливу також короткий.

Відповідь змінюється, щойно ви пропускаєте запити на підтвердження. Автономні запуски, нічні завдання та будь-який робочий процес, у якому ви затверджуєте план і відходите від комп’ютера, усувають перевірку людиною, яка забезпечувала стримування. Тоді це має забезпечувати сама машина. Те саме стосується всього, що розширює доступ агента, зокрема запуск агента програмування на VPS одночасно в кількох репозиторіях.

Рішення насправді залежить не від того, наскільки ви довіряєте моделі. Воно залежить від того, що опиниться поруч із нею, коли модель помилиться.

FAQ

Чи достатньо ізоляції контейнера для агента кодування?

Для більшості завдань — так, за двох умов. Контейнер не повинен запускатися з --privileged і не повинен мати змонтований у нього /var/run/docker.sock, оскільки будь-яка з цих умов дає процесу шлях до root на хості. Контейнер використовує ядро хоста, тому цей бар’єр слабший, ніж у віртуальної машини. Якщо агент запускає ненадійний код, отриманий з інтернету, використовуйте повноцінну VM або окремий сервер.

Чи потрібен агенту sudo на сервері?

Ні. Надання sudo нівелює створену ізоляцію, оскільки root може читати дані всіх інших облікових записів на сервері. Створіть користувача агента без sudo і надайте йому доступ на запис лише до його власного робочого каталогу. Якщо завдання справді потребує встановлення пакетів, надайте агенту окрему машину, якою він керує, а не root-доступ на машині, яку він спільно використовує з іншими.

Як дозволити агенту виконувати push до git, не розміщуючи мій SSH-ключ на машині?

Під час підключення передайте свій SSH agent за допомогою ssh -A. Запити на підпис передаються через підключення, а приватний ключ залишається на вашому ноутбуці, тому ssh -T git@github.com виконує автентифікацію, а git push працює без приватного ключа на сервері. Врахуйте, що root на цьому сервері може використовувати переданий сокет, поки ви підключені. Тому на будь-якій машині, яку ви спільно використовуєте з іншими людьми, застосовуйте deploy key з обмеженням до конкретного репозиторію.

Який розмір VPS потрібен агенту?

Робота агента здебільшого полягає в редагуванні файлів, виконанні збірок і тестів, тому розмір машини слід визначати за вимогами збірки, а не моделі. Hosted model працює на обладнанні постачальника, тому створює мережевий трафік і майже не навантажує локальну машину. Для роботи зі скриптами почніть із 2 GB RAM і збільште обсяг до 8 GB, якщо репозиторій збирає контейнери або компілює щось суттєве.

Як часто потрібно знищувати й перебудовувати машину?

Перебудовуйте машину, коли стан системи більше неможливо однозначно пояснити, і щонайменше щоразу, коли облікові дані на машині могли бути розкриті. Свіже клонування репозиторію перед кожним завданням усуває повсякденні зміни стану, а snapshot, створений перед першим запуском агента, дає змогу повернутися до чистого образу системи. Якщо перебудова здається надто дорогою, це означає, що на машині, яку ви назвали одноразовою, зберігаються важливі дані або компоненти.