Ejecuta agentes de código en una VM desechable

Por qué una VM desechable es mejor que tu portátil

Proporcione a un agente de programación una VM desechable. Lo peor que puede hacer es destruir una máquina que puede reconstruir en diez minutos. El agente sigue teniendo acceso a root, sigue instalando paquetes y sigue ejecutando el conjunto de pruebas sin pedir permiso para cada paso. La diferencia está en dónde se produce el daño. En un portátil, el agente comparte el directorio personal con las claves SSH, el perfil del navegador, los archivos .env y todos los demás repositorios que haya clonado alguna vez. En un servidor desechable, solo tiene un shell, una copia de trabajo y nada más que valga la pena robar.

Ese es todo el argumento, y trata sobre la asimetría, no sobre la probabilidad. Un agente cuidadoso en un portátil bien protegido funciona correctamente casi siempre. La única vez que no lo hace, el coste no es un commit defectuoso. Es restaurar una copia de seguridad, si tiene alguna.

Defina el alcance del impacto antes de debatirlo

El alcance del impacto es el conjunto de elementos a los que puede acceder un proceso. Para un agente que se ejecuta como su usuario normal en su equipo habitual, ese conjunto es mayor de lo que la mayoría imagina.

Incluye ~/.ssh/id_ed25519, que normalmente no está cifrada porque se cansó de escribir la frase de contraseña. Incluye ~/.aws/credentials y ~/.config/gh/hosts.yml, que están en texto plano por diseño. Incluye todos los repositorios hermanos que se encuentran bajo ~/code, incluidos los que contienen cadenas de conexión de producción en un archivo de entorno local. También incluye el historial de su shell, que contiene tokens que pegó una vez. Incluye además la red a la que está conectado su portátil, que suele ser una red doméstica o de oficina con servicios sin autenticación.

Nada de eso requiere un agente malicioso. Basta con un comando que sea incorrecto, pero que se ejecute con confianza. rm -rf con una variable no definida que se expande a /, un git clean -xfd en el directorio equivocado, un docker system prune -af --volumes que se lleva consigo la base de datos local, o un chmod -R 777 aplicado al directorio personal. Los agentes se entrenan con la misma Internet que enseñó esos comandos al resto.

El mecanismo que lo protege no es el criterio del agente. Es que el equipo que contiene el daño es uno que usted estaba dispuesto a perder.

El cálculo de costos es aburrido, y ese es el objetivo

Un VPS pequeño cuesta unos pocos dólares al mes. Recuperar una laptop de desarrollo cuesta un día, y ese es el mejor caso: lo detectas de inmediato y tienes una copia de seguridad.

Haz el cálculo con tus propios números. Toma tu tarifa por hora y multiplícala por las horas que necesitarías para reinstalar un sistema operativo, restaurar un directorio personal, rotar una clave SSH, rotar un token de acceso personal y volver a clonar veinte repositorios. Compara ese importe con doce meses del servidor más pequeño que ofrece tu proveedor. El punto de equilibrio se alcanza con menos de un incidente cada varios años, y el incidente no tiene que ser catastrófico para superar ese umbral. Una sola tarde perdida por un entorno local dañado ya paga el año.

La segunda parte del cálculo son las snapshots. Una snapshot antes de ejecutar una operación de riesgo convierte un resultado incorrecto de "restaurar toda mi configuración" en "hacer rollback y probar otro prompt". Esa opción no existe en la laptop en la que estás escribiendo esto, porque no puedes crear una snapshot de una máquina mientras la usas como escritorio.

El panorama en julio de 2026

Hay tres respuestas válidas a «dónde debe ejecutarse el agente», y todas implican elegir entre los mismos dos factores: la solidez del aislamiento y la cantidad de configuración que está dispuesto a aceptar.

Una microVM local. Las herramientas de esta categoría inician una máquina virtual real en su propio hardware, montan el repositorio en ella y permiten que el agente tenga acceso como root dentro de la máquina. clawk es el ejemplo actual, y su propuesta coincide exactamente con la tesis de esta publicación: proporcionar a los agentes de programación una VM de Linux desechable, no su portátil. En julio de 2026, es compatible con macOS 14 y versiones posteriores en Apple silicon, ofrece compatibilidad experimental con Linux mediante Firecracker y se instala con brew install clawkwork/tap/clawk. Ejecute clawk dentro de un repositorio para iniciar el sandbox y asociar un agente, clawk down para detenerlo y clawk destroy para eliminarlo. El límite es un hipervisor, que ofrece un aislamiento sólido. La limitación es que la VM se ejecuta en el equipo que lleva consigo, consume memoria y se detiene cuando cierra la tapa.

Un contenedor. Docker es la opción que la mayoría de las personas ya tiene instalada, y resulta realmente útil.

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

--rm elimina el contenedor al salir y --network none le impide acceder a la red, lo que constituye un buen valor predeterminado para una compilación o una ejecución de pruebas. Tenga claro lo que esto no hace: un contenedor comparte el kernel del host, por lo que un error del kernel puede permitir escapar del aislamiento, y el aislamiento desaparece en cuanto añade --privileged o monta /var/run/docker.sock para que el agente pueda «usar Docker». Montar el socket de Docker en un contenedor equivale a concederle acceso como root en el host.

Un VPS convencional que pueda reconstruir. No requiere ninguna herramienta nueva, ofrece un aislamiento real mediante el kernel, admite snapshots del proveedor y sigue ejecutándose cuando apaga el portátil. Este es el patrón que describe el resto de esta guía y es el que resiste las ejecuciones prolongadas de los agentes, porque un trabajo que tarda cuatro horas no depende de que usted se haya ido a casa.

El patrón de VPS: asignar al agente su propio usuario

Empiece con un servidor reforzado. Los primeros diez minutos en un VPS nuevo cubren las partes que no son específicas del agente: actualizaciones, un inicio de sesión que no use root, SSH con claves como único método de autenticación y un firewall.

A continuación, cree una cuenta que exista únicamente para el agente. Así, un error dentro de esa cuenta no podrá afectar al resto del servidor.

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 significa que no hay ninguna contraseña que se pueda adivinar. Puede acceder a la cuenta mediante sudo -u agent o con una clave SSH. Tenga en cuenta que agent no pertenece deliberadamente al grupo sudo. Un agente con sudo tiene acceso root, y root puede leer los archivos de los demás usuarios. En ese caso, la separación que acaba de crear solo es aparente. Si el agente realmente necesita instalar paquetes, eso indica que necesita un servidor completo propio, no que deba recibir sudo en un servidor compartido. Las reglas generales se explican en principio de mínimo privilegio para usuarios de Linux en un VPS.

Compruebe el límite antes de confiar en él. Como usuario agent, intente leer un archivo perteneciente a su propia cuenta:

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

Debería ver cat: /home/you/.ssh/id_ed25519: Permission denied. Si ve material criptográfico, el directorio principal tiene el modo 755 y el aislamiento aún no es real. Corríjalo con sudo chmod 700 /home/you.

Mantén las credenciales completamente fuera de la máquina

El propósito de una máquina desechable se pierde si copias tus secretos de producción en ella. La regla es simple: nada de ese equipo debe ser una credencial cuya rotación te preocupe esta tarde.

Para git, reenvía tu agente SSH en lugar de copiar una clave. La clave privada permanece en tu portátil y solo las solicitudes de firma atraviesan la conexión.

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

El segundo comando debe responder Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.. Eso demuestra que git push funcionará sin ningún archivo de clave presente en el servidor. Ejecuta ls -la ~/.ssh en el equipo después y confirma que no contiene ninguna clave privada.

El reenvío del agente tiene una salvedad importante, que debes indicar claramente: mientras estés conectado, cualquiera que tenga acceso root a ese servidor puede usar el socket reenviado para autenticarse como tú. En un servidor cuyo único usuario adicional eres tú, es un riesgo aceptable. En un equipo compartido no lo es, y una clave de implementación limitada a un solo repositorio es una mejor opción. Las opciones se explican en Conceptos básicos de gestión de claves SSH.

Para las claves de API, proporciona al agente su propia clave con su propio límite de gasto y guárdala en un archivo propiedad del usuario agent con permisos 600. Cuando destruyas la máquina, revoca esa clave en lugar de preguntarte si se filtró. Mantener visible el gasto del modelo por clave también permite que las cifras de Control de costes de un agente de IA en un VPS sigan siendo predecibles.

Limitar el acceso del agente a la red

El aislamiento del sistema de archivos cubre la mitad de la frontera. La otra mitad es la salida de red: los destinos con los que el proceso puede comunicarse. Linux puede filtrar el tráfico saliente según el usuario que lo creó, lo que encaja exactamente con este patrón.

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

Las reglas se leen en orden, por lo que la última REJECT bloquea todo lo que las líneas anteriores no hayan permitido. Pruébelo como el agente:

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

La solicitud debería fallar con curl: (7) Failed to connect to example.com port 80: Connection refused, porque la regla de rechazo responde de inmediato en lugar de dejar que la conexión se quede esperando. Una solicitud HTTPS al mismo host debería seguir funcionando.

Hay dos limitaciones importantes. En primer lugar, estas reglas se pierden en el siguiente reinicio si no las guarda con sudo apt install -y iptables-persistent y después con sudo netfilter-persistent save. En segundo lugar, este filtro controla puertos y direcciones, no nombres. Una regla que permita el puerto 443 permite acceder a cualquier host HTTPS de Internet. Esto basta para acceder a la API del modelo y también a un servicio de pastebin. Una lista de permitidos basada realmente en dominios requiere que el tráfico pase por un proxy que lea el nombre de host solicitado. Esto añade más componentes de los que suelen querer la mayoría de las configuraciones de un solo desarrollador. Declare solo lo que realmente tiene: control de salida por puerto, en una máquina cuya pérdida estaba dispuesto a asumir.

Restablecer un estado limpio entre tareas

El estado limpio por tarea es un beneficio subestimado. Un agente que dedicó tres horas al ticket anterior dejó paquetes instalados, migraciones aplicadas parcialmente, un node_modules obsoleto y un árbol de trabajo de git con cambios que nadie revisó. La siguiente tarea hereda todo eso, y usted dedica su presupuesto de revisión a determinar qué problema corresponde a cada ejecución.

La opción económica es hacer un checkout nuevo para cada tarea.

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

La opción más sólida es crear una instantánea del proveedor una sola vez, justo después de configurar la máquina y antes de que cualquier agente la haya utilizado. Restaurar esa instantánea devuelve todo el sistema, incluidos los paquetes, a un estado conocido. La mayoría de los proveedores ofrece esta función en el panel de control o mediante una API, no como un comando en el equipo, por lo que los pasos exactos dependen de su proveedor. La práctica correcta es crear la instantánea mientras la máquina aún está en un estado básico.

Mantenga fuera de la máquina desechable todo lo que le importe. Esto suele significar enviar las ramas en lugar de conservarlas localmente. Si la máquina termina almacenando algo que echaría de menos, haga una copia de seguridad correctamente con copias de seguridad de restic en un VPS. Una máquina que puede destruir solo es útil si destruirla no causa problemas.

Si quiere varios entornos aislados sin pagar por varios servidores, un VPS más grande puede alojar máquinas virtuales invitadas directamente. Virtualización anidada en un VPS explica cómo funciona, incluido cómo comprobar si su proveedor la permite.

Cuándo un portátil es realmente suficiente con las medidas adecuadas

Sea honesto sobre este punto, porque exagerar el aislamiento hace que la gente deje de escuchar.

Si revisa cada comando antes de ejecutarlo, un portátil es suficiente. El aviso de permisos es un control real, y ejecutar Claude Code de forma segura en un servidor explica qué bloquea realmente cada uno de sus niveles. Si su trabajo se limita a un único repositorio y no hay credenciales de producción en ningún lugar de la máquina, el alcance potencial ya es reducido. Si las sesiones del agente son cortas y supervisadas, el periodo de exposición también es corto.

La respuesta cambia en cuanto se omiten los avisos. Las ejecuciones desatendidas, las tareas nocturnas y cualquier flujo de trabajo en el que apruebe un plan y se marche eliminan la comprobación humana que contenía el riesgo. En ese momento, la máquina debe hacerlo por usted. Lo mismo se aplica a cualquier situación que amplíe el alcance del agente, incluido ejecutar un agente de programación en un VPS en varios repositorios a la vez.

La decisión no depende realmente de cuánto confíe en el modelo. Depende de qué haya junto a él cuando el modelo se equivoque.

FAQ

¿Es suficiente un contenedor como aislamiento para un agente de programación?

Para la mayoría de las tareas, sí, con dos condiciones. El contenedor no debe ejecutarse con --privileged ni tener /var/run/docker.sock montado en él, porque cualquiera de las dos opciones da al proceso una ruta hacia root en el host. Un contenedor comparte el kernel del host, por lo que el límite es más débil que el de una máquina virtual. Si el agente ejecuta código no confiable descargado de Internet, es preferible usar una VM real o un servidor independiente.

¿El agente necesita sudo en el servidor?

No. Darle sudo anula el aislamiento configurado, porque root puede leer todas las demás cuentas del sistema. Cree el usuario del agente sin sudo y déle acceso de escritura únicamente a su propio directorio de trabajo. Si la tarea necesita realmente instalar paquetes, asigne al agente una máquina completa que controle en lugar de darle root en una máquina compartida.

¿Cómo permito que el agente haga push a git sin poner mi clave SSH en el host?

Reenvíe su agente SSH con ssh -A al conectarse. Las solicitudes de firma viajan por la conexión mientras la clave privada permanece en su portátil, por lo que ssh -T git@github.com autentica y git push funciona sin ninguna clave privada en el servidor. La limitación es que root en ese servidor puede usar el socket reenviado mientras usted está conectado. Por tanto, use una clave de despliegue limitada al repositorio en cualquier máquina que comparta con otras personas.

¿Qué tamaño de VPS necesita un agente?

El trabajo del agente consiste principalmente en editar archivos, ejecutar compilaciones y ejecutar pruebas. Por tanto, dimensione la máquina para la compilación y no para el modelo. Un modelo alojado se ejecuta en el hardware del proveedor, lo que añade tráfico de red y casi ninguna carga local. Empiece con 2 GB de RAM para tareas de scripting y pase a 8 GB si el repositorio compila contenedores o compila software de cierta complejidad.

¿Con qué frecuencia debo destruir y reconstruir la máquina?

Reconstruya la máquina cuando el estado deje de ser explicable y, como mínimo, siempre que una credencial del host pueda haber quedado expuesta. Un checkout nuevo entre tareas controla la deriva diaria, y una instantánea tomada antes de la primera ejecución del agente le proporciona una imagen limpia del sistema a la que puede volver. Si reconstruir parece costoso, es una señal de que algo importante reside en una máquina que había considerado desechable.