Seguridad para agentes de código: remoto, sandbox y permisos

Ahora que usamos tanto los agentes en local, tienes que saber que no solo tienen acceso al código de tu proyecto, sino a tus variables de entorno, claves de SSH, configuración de AWS o cualquier otro fichero que pueda leer tu agente.

En caso de un supply chain attack —que ha habido unos cuantos recientemente—, o bien que tu agente decida leer uno de esos ficheros mientras explora, al final tus credenciales pueden salir de tu equipo.

Por eso me quiero centrar en lo importante que es establecer límites y controles de seguridad para que los agentes de código (como Codex o Claude Code) no accedan a ficheros que no deben, y nuestras credenciales puedan terminar en internet.

En mi caso lo que más suelo utilizar es Codex y macOS, aunque esto te vale para otros harnesses como Claude Code, OpenCode o Pi, así como para otros sistemas operativos.

Te cuento las tres estrategias que puedes utilizar para mejorar la seguridad mientras desarrollas, según tus necesidades: desarrollo remoto, virtualización y restricciones de permisos.

flowchart LR
    agente[Agente de código] --> remoto[Desarrollo remoto]
    agente --> sandbox[Sandbox o máquina virtual]
    agente --> permisos[Local con permisos limitados]

Aislamiento físico con un VPS o Homelab

La forma más segura de desarrollar con agentes es con una máquina remota (aunque hay que configurarla correctamente: mínimo privilegio, firewall, etc.), ya sea en un VPS o un homelab, que esté aislado parcialmente de la red.

Esta es la opción más fácil si te gusta cacharrear y, además, te permite tener agentes ejecutándose en segundo plano e incluso trabajar de forma remota. Por ejemplo, yo puedo acceder a ellos desde el móvil si lo necesito.

Si tienes algún ordenador viejo por casa, siempre puedes montarte un homelab con Ubuntu Server (o Proxmox, aunque aún no he dado el salto), o bien puedes contratar un servidor en Hetzner por unos pocos euros al mes.

Lo importante es tener los mínimos secretos necesarios para que el agente pueda trabajar, y que los que tenga que haber (GitHub, Codex…) estén protegidos. Para eso puedes utilizar la política de accesos que veremos a continuación para encontrar un equilibrio entre comodidad y seguridad.

También podría ser interesante tener un filtrado de tráfico de red saliente aunque esto es algo más avanzado.

Utilizando una máquina virtual o sandbox

Otra opción más cómoda es utilizar una máquina virtual en tu ordenador, de forma que el agente tenga acceso limitado a sus recursos. Este es un punto medio entre ejecutarlo en local y tener la protección de un VPS (siempre y cuando configures la máquina virtual de forma segura).

Hay muchas herramientas que puedes utilizar para crear máquinas virtuales, por ejemplo:

• En Mac yo utilizo LimaVM para crear una máquina virtual y limitar el acceso del agente. También lo utilizo para protegerme cuando desarrollo, por si hay algún ataque a la cadena de suministro y el agente intenta acceder a mis datos.
• En Linux puedes utilizar Incus, que me ha llamado la atención aunque aún no lo he probado.
• También puedes utilizar un contenedor con Docker (o Podman), aunque es algo menos seguro, ya que comparte el kernel con tu ordenador. Recientemente han lanzado Docker Sandbox, que te obliga a iniciar sesión con una cuenta y la comunidad no está muy contenta.

Un ejemplo de configuración mínima de lima podría ser este, aunque aún estoy dándole algún repaso a ciertas configuraciones que no tengo claras para dejarlo bien sólido.

Ejecutando el agente en local. Política de accesos.

Hay veces que no queda más remedio, o que simplemente es más cómodo, investigar o ejecutar algunos comandos en local. Para eso Codex permite establecer un fichero de configuración, normalmente ~/.codex/config.toml, que expresa tus preferencias, aunque puede saltárselo. En cambio, ~/.codex/requirements.toml es un límite estricto.

En mi caso limito algunos permisos: solo permito que se lean los proyectos que autorizo y que no pueda leer los datos de carpetas de mi usuario (.ssh, .config, etc.) ni tampoco los ficheros .env.

Finalmente, también puedes ajustar qué debe hacer tu agente ante ciertos comandos (prompt, allow, deny), de forma que puedas permitir comandos como git add o git commit y adaptarlo a tus necesidades.

Conclusión

Mi regla es sencilla: trabajo según la confianza que tenga. Si quiero dejar un agente con tareas largas, lo suelo hacer en mi homelab remoto; si es algo en lo que tengo confianza, lo hago en local y lo superviso; y si me genera dudas, lo lanzo en una máquina virtual.

Al final, lo importante es ser consciente de los límites que tiene el agente y de los riesgos que puede suponer.