Запуск AI-агентов в изолированной виртуальной машине

Почему одноразовая виртуальная машина лучше вашего ноутбука

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

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

Определите радиус поражения, прежде чем спорить о нём

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

Он включает ~/.ssh/id_ed25519, которые обычно не зашифрованы, потому что вы устали вводить парольную фразу. Он включает ~/.aws/credentials и ~/.config/gh/hosts.yml, которые по своей сути являются открытым текстом. Он включает все соседние репозитории в ~/code, включая те, где в локальных файлах окружения хранятся строки подключения к продакшену. Он включает историю вашей командной оболочки, в которой хранятся токены, которые вы когда-то вставляли. Он также включает сеть, в которой находится ваш ноутбук — зачастую это домашняя или офисная сеть с неавторизованными сервисами.

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

Механизм, который вас спасает, — это не рассудительность агента. Это то, что машина, на которой произойдёт ущерб, — это та машина, которую вы были готовы потерять.

Расчет стоимости скучен, в этом и смысл

Небольшой VPS стоит несколько долларов в месяц. Восстановление ноутбука разработчика занимает целый день, и это в лучшем случае, когда вы замечаете проблему сразу и у вас есть резервная копия.

Рассчитайте это, используя собственные цифры. Возьмите свою почасовую ставку, умножьте на количество часов, которые потребуются для переустановки операционной системы, восстановления домашнего каталога, смены SSH-ключа, смены персонального токена доступа и повторного клонирования двадцати репозиториев. Сравните это с двенадцатью месяцами аренды самого дешевого сервера, который предлагает ваш провайдер. Точка окупаемости достигается при возникновении менее одного инцидента в несколько лет, причем инцидент не обязан быть катастрофическим, чтобы оправдать затраты. Один день, потраченный на исправление поврежденного локального окружения, уже окупает год аренды.

Вторая часть расчетов — это снимки состояния (snapshots). Снимок перед выполнением рискованной операции превращает плохой исход из ситуации «восстановить всю свою жизнь» в «откатиться и попробовать другой запрос». Такой возможности нет на ноутбуке, за которым вы сейчас работаете, так как невозможно сделать снимок машины, пока вы используете её в качестве рабочего места.

Текущая ситуация на июль 2026 года

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

Локальная микро-ВМ. Инструменты этой категории запускают полноценную виртуальную машину на вашем оборудовании, монтируют в неё репозиторий и предоставляют агенту права root внутри. clawk — актуальный пример, и его концепция в точности повторяет тезис этой статьи: предоставьте агентам для программирования одноразовую Linux-ВМ, а не ваш ноутбук. По состоянию на июль 2026 года он поддерживает macOS 14 и новее на Apple silicon, имеет экспериментальную поддержку Linux через Firecracker и устанавливается с помощью brew install clawkwork/tap/clawk. Вы запускаете clawk внутри репозитория для загрузки песочницы и подключения агента, clawk down для его остановки и clawk destroy для удаления. Границей выступает гипервизор, что обеспечивает высокую надежность. Ограничение заключается в том, что ВМ работает на машине, которую вы носите с собой, поэтому она потребляет вашу оперативную память и останавливается, когда вы закрываете крышку ноутбука.

Контейнер. 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 с возможностью пересборки. Никаких новых инструментов, реальная изоляция на уровне ядра, снимки состояния (snapshots) от провайдера, и он продолжает работать, когда вы выключаете ноутбук. Это модель, которую описывает остальная часть данного руководства, и именно она лучше всего подходит для длительных задач агента, так как задаче, выполняющейся четыре часа, неважно, что вы ушли домой.

Шаблон VPS: выделение агенту отдельного пользователя

Начните с защищенного сервера. В руководстве первые десять минут на новом VPS описаны действия, не зависящие от конкретного агента: обновления, создание пользователя без прав root, вход только по ключам SSH и настройка межсетевого экрана.

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

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 на этом сервере может использовать перенаправленный сокет для аутентификации от вашего имени. На сервере, где кроме вас никого нет, это приемлемый компромисс. На общем сервере это недопустимо, и лучшим решением будет deploy key, ограниченный одним репозиторием. Варианты описаны в основах управления 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, так как правило отклонения (reject) срабатывает немедленно, не позволяя соединению зависнуть. HTTPS-запрос к тому же хосту при этом должен успешно выполниться.

Важно учитывать два ограничения. Во-первых, эти правила сбрасываются после перезагрузки, если их не сохранить с помощью sudo apt install -y iptables-persistent, а затем sudo netfilter-persistent save. Во-вторых, фильтрация происходит по портам и адресам, а не по доменным именам. Правило, разрешающее порт 443, открывает доступ ко всем HTTPS-хостам в интернете, чего достаточно как для обращения к API модели, так и для отправки данных на pastebin. Для полноценного «белого списка» доменов трафик должен проходить через прокси, который считывает запрашиваемое имя хоста, что требует более сложной настройки, чем нужно большинству разработчиков-одиночек. Используйте то, что есть: контроль исходящего трафика на уровне портов на машине, которую вы готовы потерять.

Возврат к чистому состоянию между задачами

Чистое состояние для каждой задачи — это недооцененное преимущество. Агент, который три часа работал над предыдущим тикетом, оставляет после себя установленные пакеты, частично примененные миграции, устаревший node_modules и рабочую директорию git с изменениями, которые никто не проверял. Следующая задача наследует всё это, и вы тратите время на разбор того, какой беспорядок к какому запуску относится. Более узкоспециализированный агент изначально оставляет меньше мусора, поэтому использование одноразовой машины в сочетании с навыком, который подталкивает агента к минимально необходимым изменениям, позволяет сохранить размер diff и остаточного состояния в пределах, пригодных для проверки.

Бюджетный вариант — это свежий checkout для каждой задачи.

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

Более надежный вариант — это снапшот провайдера, сделанный один раз, сразу после настройки машины и до того, как к ней прикоснулся какой-либо агент. Восстановление такого снапшота возвращает всю систему, включая пакеты, в известное состояние. Большинство провайдеров предоставляют эту возможность через панель управления или API, а не через команду внутри системы, поэтому точные шаги зависят от вашего провайдера. Правило состоит в том, чтобы делать снапшот, пока машина еще находится в «скучном» стандартном состоянии.

Не храните ничего важного на одноразовой машине; это означает, что нужно отправлять ветки в репозиторий, а не накапливать их локально. Если на машине всё же оказалось что-то ценное, создайте резервную копию с помощью restic backups on a VPS. Машина, которую можно уничтожить, полезна только в том случае, если её уничтожение действительно проходит без последствий.

Если вам нужно несколько изолированных сред без оплаты нескольких серверов, один более мощный VPS может напрямую размещать гостевые виртуальные машины. Nested virtualisation on a VPS описывает, как это работает, включая проверку того, разрешает ли это ваш провайдер. Изоляция работает в обе стороны, и если вы предпочитаете, чтобы два агента на одной машине координировали действия, а не были полностью изолированы друг от друга, одна сессия Claude Code может отправлять текст напрямую другой, вместо того чтобы пропускать каждую передачу управления через вас.

Когда использование ноутбука оправдано

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

Если вы проверяете каждую команду перед её выполнением, ноутбук вполне подходит для работы. Запрос на подтверждение прав доступа — это реальный инструмент контроля, а в статье безопасный запуск Claude Code на сервере подробно описано, что именно блокирует каждый уровень защиты. Если ваша работа ограничена одним репозиторием, а на машине отсутствуют производственные учетные данные, радиус поражения уже невелик. Если сессии агента короткие и проходят под вашим присмотром, окно уязвимости также остается минимальным.

Ситуация меняется, как только вы перестаете подтверждать запросы. Об этом стоит задуматься сейчас, когда автоматический режим станет стандартным для Claude Code с 14 августа 2026 года, и при чистой установке агент больше не будет запрашивать подтверждение перед редактированием файлов или выполнением команд. Работа без присмотра, ночные задачи и любые сценарии, где вы одобряете план и отходите от компьютера, исключают человеческий контроль, который ранее обеспечивал безопасность. В таких случаях эту функцию должна брать на себя машина. То же самое касается любых действий, расширяющих область доступа агента, включая запуск агента для программирования на VPS, работающего сразу с несколькими репозиториями.

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

FAQ

Достаточно ли изоляции контейнера для агента разработки?

Для большинства задач — да, при соблюдении двух условий. Контейнер не должен запускаться с --privileged, и в него не должен быть смонтирован /var/run/docker.sock, так как оба варианта дают процессу путь к правам root на хосте. Контейнер использует ядро хоста, поэтому граница безопасности слабее, чем у виртуальной машины. Если агент запускает недоверенный код из интернета, лучше использовать полноценную VM или отдельный сервер.

Нужен ли агенту sudo на сервере?

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

Как разрешить агенту выполнять push в git, не размещая SSH-ключ на сервере?

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

Какой размер VPS нужен для агента?

Работа агента в основном заключается в редактировании файлов, запуске сборок и тестов, поэтому выбирайте характеристики машины исходя из требований к сборке, а не к модели. Хостинговая модель работает на оборудовании провайдера, что создает сетевой трафик, но почти не дает локальной нагрузки. Начните с 2 GB RAM для скриптов и переходите к 8 GB, если репозиторий собирает контейнеры или компилирует что-то объемное.

Как часто нужно удалять и пересоздавать машину?

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