Dale a tu agente de código una VM desechable

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

Si proporciona 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, sólo tiene un shell, una copia de trabajo y nada más que merezca la pena robar.

Ese es todo el argumento, y trata de la asimetría, no de 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 dispone de una.

Defina el alcance del daño antes de discutirlo

El alcance del daño es el conjunto de elementos a los que un proceso puede acceder. Para un agente que se ejecuta como su usuario habitual 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 de ~/code, incluidos los que tienen cadenas de conexión de producción en un archivo de entorno local. También incluye el historial del shell, que contiene tokens que pegó una vez. Incluye además la red a la que está conectado su portátil, que a menudo es una red doméstica o de oficina con servicios sin autenticación.

Nada de eso requiere un agente malicioso. Basta con un comando ejecutado con confianza pero equivocado. rm -rf "$BUILD_DIR"/* con BUILD_DIR sin definir, que se expande a /* y evita la negativa predeterminada de GNU rm a eliminar el propio /, 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 de forma indiscriminada a un directorio personal. Los agentes se entrenan con la misma Internet que enseñó esos comandos a todos los demás.

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

Las cuentas del coste son aburridas. Ese es el objetivo.

Un VPS pequeño cuesta unos pocos dólares al mes. Recuperar el portátil de un desarrollador cuesta un día, y ese es el mejor caso: se detecta el problema de inmediato y existe una copia de seguridad.

Haga el cálculo con sus propios números. Tome su tarifa por hora y multiplíquela por las horas que necesitaría 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. Compare el resultado con doce meses del servidor más pequeño que ofrece su 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 coste. Una sola tarde perdida por un entorno local dañado ya amortiza el año.

La segunda parte del cálculo corresponde a las instantáneas. Una instantánea tomada antes de una ejecución arriesgada convierte un resultado incorrecto en «revertir los cambios y probar otro prompt», en lugar de «restaurar toda mi vida». Esa opción no existe en el portátil desde el que está escribiendo esto, porque no puede crear una instantánea de una máquina mientras la usa como puesto de trabajo.

El panorama en octubre de 2026

Hay tres respuestas válidas a «dónde debe ejecutarse el agente». Todas implican elegir entre las mismas dos variables: la solidez del aislamiento y la cantidad de configuración que está dispuesto a aceptar.

Una microVM local. Las herramientas de esta categoría arrancan una máquina virtual real en su propio hardware, montan el repositorio dentro de ella y permiten que el agente tenga acceso como root. clawk es el ejemplo actual. Su propuesta coincide exactamente con la tesis de este artículo: proporcione a los agentes de programación una VM de Linux desechable, no su portátil. En octubre de 2026, funciona en macOS 14 y versiones posteriores sobre 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 arrancar el entorno aislado y asociar un agente, clawk down para detenerlo y clawk destroy para eliminarlo. El límite lo establece un hipervisor, por lo que el aislamiento es sólido. La limitación es que la VM se ejecuta en el equipo que lleva consigo, consume su memoria y se detiene cuando cierra la tapa.

Un contenedor. Docker es la respuesta que la mayoría 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 lo deja sin acceso de red, un buen valor predeterminado para una compilación o una ejecución de pruebas. Debe tener 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. Además, el límite desaparece en cuanto añade --privileged o monta /var/run/docker.sock para que el agente pueda «usar Docker». Montar el socket de Docker dentro de un contenedor equivale a concederle acceso root al host.

Un VPS convencional que pueda reconstruir. No requiere ninguna herramienta nueva, ofrece un límite real basado en el kernel, permite usar instantáneas del proveedor y sigue ejecutándose cuando apaga el portátil. Este es el patrón que describe el resto de esta guía. También es el que resiste las ejecuciones prolongadas de agentes, porque un trabajo que tarda cuatro horas no se ve afectado por que usted se vaya a casa.

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

Parta de un sistema reforzado. Los primeros diez minutos en un VPS nuevo cubren los aspectos que no son específicos del agente: actualizaciones, un inicio de sesión que no sea root, SSH sólo con claves y un firewall.

A continuación, cree una cuenta que exista únicamente para el agente. Así, un error dentro de ella no podrá afectar a ninguna otra parte 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 adivinar y que se accede a la cuenta con 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 a root, y root puede leer los archivos de los demás usuarios. Por tanto, la separación que acaba de crear sería sólo decorativa. Si el agente necesita realmente instalar paquetes, lo adecuado es asignarle un servidor completo, no darle sudo en un servidor compartido. Las reglas generales se explican en principio de privilegio mínimo para usuarios de Linux en un VPS.

Compruebe el límite antes de confiar en él. Como usuario agent, intente mostrar el contenido del directorio de inicio de su propia cuenta:

sudo -u agent ls /home/you

Debería ver ls: cannot open directory '/home/you': Permission denied. Si aparece una lista de archivos, otros usuarios pueden leer su directorio de inicio. El agente podrá leer cualquier elemento que no esté protegido por separado, como un archivo .env legible para todos los usuarios. Corríjalo con sudo chmod 700 /home/you. Esta prueba no protege su clave SSH privada: ssh ignora un archivo de clave privada al que puedan acceder otros usuarios. Por tanto, cualquier clave que funcione para usted ya es ilegible para agent, independientemente de los permisos de su directorio de inicio.

Mantenga las credenciales completamente fuera de la máquina

El propósito de una máquina desechable se pierde si copia en ella los secretos de producción. La regla es sencilla: en ese equipo no debe haber ninguna credencial cuya rotación no estaría dispuesto a hacer esta tarde.

Para Git, reenvíe el agente SSH en lugar de copiar una clave. La clave privada permanece en su portátil y sólo las solicitudes de firma atraviesan la conexión.

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

El segundo comando debería 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. Ejecute ls -la ~/.ssh en el equipo después y confirme que no contiene ninguna clave privada.

El reenvío del agente tiene una limitación importante. Debe expresarse claramente: mientras esté conectado, cualquiera que tenga acceso root a ese servidor puede usar el socket reenviado para autenticarse como usted. En un servidor cuyo único otro usuario es usted, es un intercambio aceptable. En un equipo compartido no lo es. En ese caso, una clave de despliegue limitada a un solo repositorio es una opción mejor. Las opciones se explican en Conceptos básicos de la gestión de claves SSH.

Para las claves de API, asigne al agente su propia clave con su propio límite de gasto. Guárdela en un archivo propiedad del usuario agent y con permisos 600. Cuando destruya la máquina, revoque esa clave en lugar de preguntarse si se ha filtrado. Mantener visible el gasto de los modelos por clave también permite que las cifras de Control de costes de un agente de IA en un VPS sigan siendo predecibles.

Limite el acceso de red del agente

El aislamiento del sistema de archivos cubre la mitad del límite de seguridad. La otra mitad es el tráfico de salida: a qué destinos puede conectarse el proceso. Linux puede filtrar el tráfico saliente según el usuario que lo genera, 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 el REJECT final 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

Debe fallar inmediatamente con un error curl: (7) Failed to connect to example.com. El texto exacto varía según la versión de curl, porque la regla de rechazo responde de inmediato en lugar de dejar que la conexión se bloquee. Una petición 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, filtran puertos y direcciones, no nombres. Una regla que permita el puerto 443 permite cualquier host HTTPS de Internet. Esto basta para acceder a la API del modelo, pero también a un servicio de pastebin. Una lista de permitidos por dominio real 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 para un único desarrollador. Declare sólo lo que realmente tiene: control del tráfico de salida por puerto, en una máquina que estaba preparado para perder.

Restablecer un estado limpio entre tareas

El estado limpio por tarea es una ventaja que suele infravalorarse. Un agente que dedicó tres horas a la incidencia anterior dejó paquetes instalados, migraciones aplicadas a medias, 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 el tiempo de revisión a determinar qué residuos pertenecen a cada ejecución. Un agente más limitado deja menos residuos desde el principio, por lo que combinar una máquina desechable con una habilidad que impulse al agente a aplicar el cambio mínimo que funcione mantiene el diff y el estado residual lo bastante reducidos como para revisarlos.

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 ningún agente la utilice. Restaurar esa instantánea devuelve todo el sistema, incluidos los paquetes, a un estado conocido. La mayoría de los proveedores ofrecen esta función en el panel de control o mediante una API, no como un comando ejecutable en la máquina, por lo que los pasos exactos dependen de su proveedor. La práctica correcta es crear la instantánea mientras la máquina todavía está en un estado limpio.

Mantenga fuera de la máquina desechable todo lo que quiera conservar. En la práctica, esto significa principalmente subir las ramas en lugar de acumularlas localmente. Si la máquina acaba almacenando algo que echaría de menos, haga una copia de seguridad adecuada con copias de seguridad de restic en un VPS. Una máquina que puede destruirse sólo es útil si destruirla no causa problemas.

Si quiere varios entornos aislados sin pagar varios servidores, un VPS más grande puede alojar máquinas virtuales invitadas directamente. La virtualización anidada en un VPS explica cómo funciona, incluido cómo comprobar si el proveedor la permite. Aquí el aislamiento funciona en ambos sentidos. Si prefiere que dos agentes coordinen su trabajo en la misma máquina en lugar de permanecer aislados, una sesión de Claude Code puede enviar texto directamente a otra en vez de hacer pasar cada transferencia por usted.

Cuándo un portátil está realmente bien aislado

Sea claro 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 nivel. Si su trabajo se limita a un único repositorio y no hay credenciales de producción en ningún lugar del equipo, el alcance potencial del incidente ya es reducido. Si las sesiones del agente son breves y supervisadas, el intervalo de exposición también lo es.

La respuesta cambia en cuanto omite los avisos. Conviene tenerlo presente ahora que el modo automático es el valor predeterminado de Claude Code y una instalación nueva ya no le pide confirmación antes de editar archivos o ejecutar comandos. Las ejecuciones desatendidas, las tareas nocturnas y cualquier flujo de trabajo en el que aprueba un plan y se marcha eliminan la comprobación humana que contenía el riesgo. En ese momento, el equipo debe asumir esa función. 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 para trabajar con varios repositorios a la vez.

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

FAQ

¿El aislamiento de un contenedor es suficiente 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 debe tener /var/run/docker.sock montado en su interior, porque cualquiera de las dos cosas proporciona al proceso una vía para obtener root en el host. Un contenedor comparte el kernel del host, por lo que el límite de aislamiento es más débil que el de una máquina virtual. Si el agente ejecuta código no confiable descargado de Internet, prefiera una máquina virtual real o un servidor independiente.

¿El agente necesita sudo en el servidor?

No. Darle sudo anula el aislamiento que ha configurado, porque root puede leer las cuentas de los demás usuarios del equipo. Cree el usuario del agente sin sudo y concédale acceso de escritura sólo a su propio directorio de trabajo. Si la tarea necesita realmente instalar paquetes, proporcione al agente una máquina completa bajo su control 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 equipo?

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, de modo que ssh -T git@github.com se autentica y git push funciona sin ninguna clave privada en el servidor. La salvedad es que root en ese servidor puede utilizar el socket reenviado mientras usted está conectado. Por tanto, use una deploy key 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. Dimensione la máquina según la compilación, no según 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. El propio agente establece un mínimo: a fecha de October 20, 2026, los requisitos del sistema de Claude Code indican 4 GB de RAM como mínimo. Empiece con 4 GB incluso para tareas de scripting y pase a 8 GB si el repositorio compila contenedores o compila código de cierta entidad.

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

Reconstruya la máquina cuando su estado deje de ser explicable y, como mínimo, cada vez que una credencial del equipo pueda haber quedado expuesta. Un checkout nuevo entre tareas permite controlar 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 caro, es una señal de que algo importante reside en una máquina que había considerado desechable.