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 radio de impacto antes de discutirlo

El radio de impacto es el conjunto de elementos a los que un proceso puede acceder. En el caso de un agente que se ejecuta como su usuario habitual en su equipo habitual, ese conjunto es mayor de lo que suele imaginarse.

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 son 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, donde puede haber tokens que pegó una vez. Incluye además la red a la que está conectado el portátil, que a menudo es una red doméstica o corporativa con servicios sin autenticación.

Nada de esto requiere un agente malicioso. Basta con un comando ejecutado con seguridad pero incorrecto. 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, un chmod -R 777 aplicado por error al 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 julio de 2026

Hay tres respuestas válidas a «dónde debe ejecutarse el agente» y todas implican el mismo equilibrio entre dos factores: la solidez del límite 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 de root en su interior. 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, se dirige a macOS 14 y 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 arrancar el entorno aislado y conectar un agente, clawk down para detenerlo y clawk destroy para eliminarlo. El límite lo establece un hypervisor, por lo que es sólido. La limitación es que la VM reside en el equipo que transporta, compite por su memoria y se detiene cuando cierra la tapa.

Un contenedor. Docker es la opción 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 a la red, lo que constituye 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, y 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 en un contenedor equivale a concederle acceso de root en el host.

Un VPS común que pueda reconstruir. No requiere ninguna herramienta nueva, ofrece un límite real entre kernels, permite usar 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 soporta ejecuciones prolongadas de agentes, porque a un trabajo que tarda cuatro horas no le importa que usted se haya ido a casa.

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

Empiece con un sistema 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 sea root, SSH con acceso sólo mediante claves y un firewall.

Después, cree una cuenta que exista únicamente para el agente. Así, un error dentro de esa cuenta 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 mediante sudo -u agent o 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. Por tanto, la separación que acaba de crear sería sólo aparente. Si el agente realmente necesita instalar paquetes, eso justifica asignarle un servidor completo, no darle sudo en un servidor compartido. Las reglas generales se describen en el principio de privilegios mínimos 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 en su lugar ve material criptográfico, su directorio personal tiene permisos 755 y el aislamiento todavía no es real. Corríjalo con sudo chmod 700 /home/you.

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 lo que el agente puede alcanzar en la red

El aislamiento del sistema de archivos es solo la mitad de la barrera. La otra mitad es la salida de red: a qué destinos puede conectarse el proceso. Linux puede filtrar el tráfico saliente según el usuario que lo inició, 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 regla REJECT captura 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 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 tras 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 permite el puerto 443 permite cualquier host HTTPS de Internet. Esto basta para alcanzar la API del modelo y también para acceder a un pastebin. Una lista de dominios permitidos 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 la mayoría de las configuraciones de un solo desarrollador necesitan. Declare solo lo que realmente ha implementado: control 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 es realmente suficiente

Sea claro al respecto, porque exagerar el aislamiento hace que la gente deje de prestar atención.

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 ninguna parte del equipo, el alcance potencial del incidente ya es reducido. Si las sesiones del agente son cortas y supervisadas, el periodo de exposición también lo es.

La respuesta cambia en cuanto omite los avisos. Conviene tenerlo presente ahora que el modo automático pasa a ser el predeterminado de Claude Code el 14 de agosto de 2026 y una instalación nueva deja de pedir confirmación antes de editar archivos o ejecutar comandos. Las ejecuciones sin supervisión, las tareas nocturnas y cualquier flujo de trabajo en el que aprueba un plan y se ausenta eliminan el control humano que contenía el riesgo. En ese momento, la máquina debe encargarse de esa contenció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 sobre 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

¿Un contenedor ofrece suficiente aislamiento para un agente de programación?

Para la mayoría de los trabajos, sí, con dos condiciones. El contenedor no debe ejecutarse con --privileged ni tener /var/run/docker.sock montado en su interior, porque cualquiera de las dos opciones proporciona al proceso una ruta hasta root en el host. Un contenedor comparte el kernel del host, por lo que el 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 del resto del equipo. Cree el usuario del agente sin sudo y concédale acceso de escritura únicamente a su propio directorio de trabajo. Si la tarea necesita realmente instalar paquetes, proporcione 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 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 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. Dimensione la máquina para la compilación, no para el modelo. Un modelo alojado se ejecuta en el hardware del proveedor, lo que añade tráfico de red y apenas carga local. Empiece con 2 GB de RAM para tareas de scripting y pase a 8 GB si el repositorio compila contenedores o compila componentes de cierta envergadura.

¿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 equipo pueda haber quedado expuesta. Un checkout nuevo entre tareas evita 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 declarado desechable.