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

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

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

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

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

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

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

Для этого не нужен вредоносный агент. Достаточно одной уверенно выполненной ошибочной команды. rm -rf "$BUILD_DIR"/* с не заданным BUILD_DIR, что раскрывается в /* и обходит стандартный запрет GNU rm на удаление самого /, 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 ls /home/you

Вы должны увидеть ls: cannot open directory '/home/you': Permission denied. Если вместо этого отображается список файлов, значит, ваш домашний каталог доступен для чтения другим пользователям. Агент сможет прочитать любой файл, который не защищен отдельно, например, файл .env, доступный всем. Исправьте это с помощью sudo chmod 700 /home/you. Данный тест не предназначен для защиты вашего закрытого SSH-ключа: ssh игнорирует файл закрытого ключа, если к нему имеют доступ другие пользователи. Поэтому любой ключ, который фактически работает для вас, уже недоступен для чтения пользователю agent, независимо от прав доступа к вашему домашнему каталогу.

Храните учетные данные вне сервера

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

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

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

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