Aislar agentes de código IA en un VPS: AGENTS.md trampa

Lo que muestra la investigación de Forever Security

Lo que el estudio establece y lo que no dice

• Establecido — un archivo de instrucciones colocado en el directorio de trabajo basta para orientar al agente, sin que se explote ningún fallo de software.
• Condición — el ataque exige que el usuario lance el agente en la carpeta afectada. Según BleepingComputer, OpenAI y Anthropic recomiendan, por cierto, lanzar el agente en el directorio del proyecto.
• Cargas inofensivas — las tasas del 90 % y de cerca del 50 % proceden de pruebas con una carga sin peligro; no miden ataques reales y no se generalizan a todas las herramientas.
• Entrega desconocida — los investigadores no pudieron determinar cómo llegó el archivo del cliente a sus descargas: la página web sigue siendo una hipótesis.
• Cursor CLI — citado como lanzado desde esa carpeta, pero no descrito como probado.
• Nuestra lectura — un repositorio clonado puede contener su propio archivo de instrucciones. Es una deducción nuestra, no un resultado del estudio.

Lanzar el agente en la carpeta correcta y validar los comandos: ¿por qué un servidor aparte?

Requisitos: lo necesario para montar el VPS

Montar el VPS en nueve pasos

1. 01

   Crear un usuario sin privilegios

   sudo adduser --disabled-password --gecos "" agent
id agent
sudo -l -U agent
   El segundo comando no debe listar el grupo sudo, y el tercero debe responder que el usuario no está autorizado a ejecutar sudo. La cuenta no tiene contraseña: se entra con sudo -iu agent desde su cuenta de administración. Prevea un VPS por cliente, para que el usuario agent de un servidor solo vea los proyectos de ese cliente.

2. 02

   Reservar un directorio por proyecto

   sudo install -d -o agent -g agent -m 700 /srv/agents/projet-a
   Lance siempre el agente desde esa raíz, nunca desde /, ~ ni una carpeta de descargas: un directorio padre amplio carga archivos de instrucciones que no ha revisado. Para obtener el código, entre en la sesión del agente y clone:
   sudo -iu agent
git clone <url-du-dépôt> /srv/agents/projet-a
   Use una clave de despliegue de solo lectura, generada en esta VM y propia del repositorio del proyecto.

3. 03

   Cortar el acceso a sus claves

   sudo -iu agent printenv SSH_AUTH_SOCK
echo 'AllowAgentForwarding no' | sudo tee /etc/ssh/sshd_config.d/10-agents.conf
sudo sshd -t && sudo systemctl reload ssh
   El primer comando no debe mostrar nada: ningún agente SSH se transmite a la sesión del agente de código. Conéctese a la VM con ssh -o ForwardAgent=no. No deposite ninguna clave de despliegue de producción en este servidor, ni ningún archivo de configuración de otro cliente.

4. 04

   Limitar las variables de entorno al proyecto

   sudo -iu agent
install -m 600 /dev/null ~/.agent-env
   Edite después ~/.agent-env para dejar solo el token del proveedor, de alcance mínimo, dedicado a esta VM y revocable. Lance el agente con un entorno vaciado, para que no herede ninguna variable de su sesión:
   env -i HOME="$HOME" PATH="$PATH" TERM="$TERM" HTTPS_PROXY=http://127.0.0.1:8888 bash -c 'set -a; . ~/.agent-env; cd /srv/agents/projet-a && exec claude'
   Sustituya claude por el comando de su herramienta. Si la herramienta se conecta con una cuenta (OAuth) en lugar de una clave de API, el token vive en el directorio personal del usuario: es el token que el estudio vio expuesto con Claude Code. Prefiera una clave de API dedicada, que revoca al destruir el servidor.

5. 05

   Cerrar la entrada con ufw

   sudo ufw default deny incoming
sudo ufw limit 22/tcp
sudo ufw enable
   Mantenga abierta una segunda sesión SSH durante la activación. ufw filtra por dirección y puerto, no por nombre de host ni por usuario: por eso la salida se configura en los dos pasos siguientes, con un proxy y nftables.

6. 06

   Instalar un proxy de salida con lista blanca

   sudo apt install tinyproxy
   En /etc/tinyproxy/tinyproxy.conf, configure Listen 127.0.0.1, Port 8888, FilterDefaultDeny Yes, Filter "/etc/tinyproxy/allowlist" y escriba después la lista:
   printf '%s\n' '^registry\.npmjs\.org$' '^api\.anthropic\.com$' | sudo tee /etc/tinyproxy/allowlist
sudo systemctl restart tinyproxy
   Cada línea es una expresión regular sobre el nombre de host. Sustituya la API de ejemplo por la de su proveedor, tomada de su documentación, y añada ^github\.com$ solo si el proyecto lo exige. La documentación de tinyproxy describe un filtrado por dominio, pero no dice que se aplique al host de los túneles HTTPS (CONNECT): no está documentado, así que hay que probarlo. No dé este filtro por supuesto antes de la prueba del paso 8.

7. 07

   Prohibir al agente cualquier otra salida con nftables

   Añada al final de /etc/nftables.conf, después de la línea flush ruleset:
   table inet agent_egress {
chain output {
type filter hook output priority 0; policy accept;
meta skuid "agent" oifname "lo" tcp dport 8888 accept
meta skuid "agent" limit rate 5/minute log prefix "agent-egress-drop: "
meta skuid "agent" counter drop
}
}
   El usuario agent ya solo puede alcanzar el proxy local; el resto se registra y se descarta. Compruebe la sintaxis antes de activar:
   sudo nft -c -f /etc/nftables.conf
sudo systemctl enable --now nftables

8. 08

   Comprobar que el filtro aguanta

   sudo -u agent curl -sS --max-time 5 https://example.com
sudo -u agent curl -sS -x http://127.0.0.1:8888 https://example.com
sudo -u agent curl -sS -x http://127.0.0.1:8888 -o /dev/null -w '%{http_code}\n' https://registry.npmjs.org/-/ping
   El primer comando debe agotar el tiempo de espera, porque el cortafuegos descarta la conexión directa. El segundo debe fallar por un rechazo del proxy (con curl, un mensaje del tipo CONNECT tunnel failed; el código exacto figura en el registro de tinyproxy). El tercero debe responder 200. Son los resultados esperados: compruébelos en su propia VM. Si el segundo comando tiene éxito, el filtro no cubre los túneles HTTPS: pase a un proxy cuya documentación cubra CONNECT y corríjalo antes de lanzar el agente.

9. 09

   Prever la destrucción del servidor

   Guarde estos comandos en un script versionado. Un VPS sospechoso se elimina y se recrea desde la imagen original, y usted revoca el token del proveedor. Para su propio acceso al servidor, pase por un bastión en lugar de una exposición directa: la guía sobre el bastion host, enlazada al pie de la página, cubre este punto.

Cada salvaguarda acota algo concreto

Desplace la tabla

Revisar los archivos de instrucciones antes de que un agente los siga

El caso del paquete function-color: lo que el filtro cambia y lo que no

Solución de problemas: los errores que va a encontrar

• Un rechazo de sudo para agent — comportamiento esperado: el usuario no tiene ningún privilegio, y el texto exacto del rechazo depende de la versión de sudo. Haga la operación con su cuenta de administración, sin añadir nunca agent al grupo sudo.
• Un fallo del túnel CONNECT (con curl, un mensaje del tipo CONNECT tunnel failed) — el proxy probablemente rechazó el host; el código exacto depende de tinyproxy y figura en su registro. Lea su nombre en /var/log/tinyproxy/tinyproxy.log y añádalo a la lista solo si la herramienta lo necesita.
• Según la herramienta, un tiempo de espera agotado o un fallo de red (por ejemplo ETIMEDOUT o fetch failed) — la herramienta intenta una conexión directa que nftables descarta. Compruebe que HTTPS_PROXY está exportada en la sesión del agente. Algunos clientes ignoran esta variable: fallan entonces de forma cerrada, y su documentación indica si aceptan un proxy.
• Permission denied al leer la carpeta de otro usuario — es el aislamiento funcionando. Si el agente necesita un archivo, cópielo en el directorio del proyecto.
• Conexión SSH cortada tras ufw enable — faltaba la regla del puerto 22, o SSH escucha en otro. Desde la consola del VPS, ejecute sudo ufw status y después sudo ufw allow <puerto>/tcp.

Lo que este servidor no resuelve

Para una agencia: un VPS por cliente

La documentación oficial