Использование одноразовых VM для 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 key, смены personal access token и повторного клонирования двадцати репозиториев. Сравните это с двенадцатью месяцами аренды самого дешевого сервера у вашего провайдера. Точка окупаемости достигается при возникновении менее одного инцидента за несколько лет, причем инцидент не обязан быть катастрофическим, чтобы оправдать затраты. Один потерянный из-за поврежденного локального окружения день уже окупает год использования сервера.

Вторая часть расчетов — это снимки состояния (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 внутрь контейнера равносильно предоставлению этому контейнеру прав root на хост-системе.

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

Шаблон 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. Когда машина будет уничтожена, аннулируйте этот ключ, вместо того чтобы гадать, произошла ли утечка. Отслеживание расходов по каждому ключу также позволяет сделать цифры в контроле затрат на ИИ-агентов на 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 с изменениями, которые никто не проверял. Следующая задача наследует весь этот мусор, и вы тратите время, отведенное на проверку, пытаясь понять, какой беспорядок относится к какому запуску.

Самый простой вариант — выполнять свежий checkout для каждой задачи.

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

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

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

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

Когда ноутбук с должным вниманием — это вполне приемлемый вариант

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

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

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

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

FAQ

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

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

Нужен ли агенту 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, если репозиторий собирает контейнеры или компилирует что-либо значительное.

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

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