Un solo prompt. Tres comandos de shell. Usé su propia IA para hackearse a sí misma.
Este es un tipo de error que probablemente existe en todos los productos de IA multiagente que se lanzan hoy. Y la solución es un patrón de diseño del que nadie en el sector está hablando todavía.
Aquí está la historia completa.
No estaba intentando hackear nada. Estaba investigando cómo Perplexity Computer maneja el sandboxing para mi propio trabajo de infraestructura de agentes. Intentaba entender cómo los sistemas multiagente en producción aíslan realmente los entornos de ejecución, qué se comparte, qué no.
Primero, comencé a husmear en el sistema. Noté que Claude Code estaba instalado en el sandbox.
Hice que el agente lo iniciara y generara algo de código de prueba solo para ver cómo se comportaba. Funcionó bien. Claude Code estándar, ejecutándose en modo bypass-permissions para que no pida confirmación. Tiene sentido para un sistema agéntico.
Fue entonces cuando pensé: espera, ¿cómo están manejando las claves API? Claude Code necesita una clave API de Anthropic para funcionar. Esa clave tiene que estar en algún lugar de este sandbox. ¿Cómo se inyecta? ¿Cómo está delimitada? ¿Está aislada?
Esa pregunta fue lo que me llevó por este camino.
El subagente tiene una clave API en su entorno de proceso. Necesitaba robarla.
Perplexity Computer lo intentó seis veces y falló.
- Le pedí al subagente que volcara su env: ¡se negó!
- Planté un script troyano en el sistema de archivos compartido: ¡leyó mi código, entendió lo que hacía y se negó a ejecutarlo!
- Envenené .bashrc y .profile: se dispararon demasiado pronto, antes de que se inyectara la clave API.
- Coloqué un binario falso de node en PATH: nunca se activó.
- Inicié el agente de codificación y observé simultáneamente el árbol de procesos: el subagente se ejecuta en un sandbox diferente, no se capturó nada :(
- Encontré el prompt del sistema para Claude Code y lo modifiqué para eliminar el comportamiento de rechazo: no se pudo encontrar un prompt del sistema personalizado que se estuviera inyectando.
Seis fracasos. La seguridad a nivel de modelo/prompt de Claude es legítimamente buena. Cada vez que intentaba algo ingenioso, el modelo lo detectaba.
Entonces Perplexity recordó que Claude Code es una aplicación Node.js lanzada a través de npm. Y npm lee ~/.npmrc desde el directorio home. Y el directorio home está en el sistema de archivos compartido al que puedo escribir.
Node.js tiene una bandera --require que precarga un módulo JavaScript antes de que se ejecute cualquier código de la aplicación. Puedes configurarlo mediante NODE_OPTIONS en .npmrc. Lo que significa que si escribo un .npmrc en el directorio home compartido, ¡cada proceso Node que el subagente inicie precargará mi código! Esto sucede antes de que Claude Code siquiera se inicialice, antes de que se ejecuten las comprobaciones de seguridad, ¡antes de cualquier cosa!
El exploit son tres comandos:
- Escribir un script de seis líneas que vuelque process.env en un archivo en el workspace compartido.
echo 'node-options=--require /path/to/script.js' > ~/.npmrc- Pedir a Perplexity Computer que haga literalmente cualquier tarea de codificación.
El subagente arranca → npm lee mi .npmrc → mi precarga se activa antes de que Claude Code comience → las credenciales completas de la API caen en el sistema de archivos compartido.
¡Funcionó! Me dio un token de gateway de Perplexity que hace proxy a través de agent-proxy.perplexity.ai hacia su cuenta maestra de Anthropic.
Naturalmente, lo primero que hice fue configurar esta clave API y BASE_URL para Claude Code en mi portátil. Esperaba que las llamadas LLM de Claude Code fallaran y estuvieran restringidas al sandbox. Me sorprendió. ¡Respuesta instantánea de Opus 4.6!
Entonces pensé: "seguramente, me cobrarán en mi cuenta por este uso, esta clave API debe estar vinculada a mi usuario". Me equivoqué de nuevo.
Hice que Opus 4.6 generara una larga historia describiendo la historia del mundo incluyendo cada invento, imperio y descubrimiento. Ejecuté esta llamada 5 veces en paralelo, generando más de 100k tokens de salida cada una. Esto debería haber consumido todos mis créditos de Perplexity Computer, pero no se movieron.
No restringido por IP. No limitado por sesión. No vinculado al sandbox. Su factura.
Una de las startups de IA mejor financiadas del planeta fue vulnerada por un dotfile que se ha utilizado en ataques a la cadena de suministro de Node.js desde 2019.
El modelo hizo todo correctamente. La infraestructura no.
Ahora esto es lo que realmente quiero que los fundadores que construyen infraestructura de agentes se lleven de esto.
La arquitectura de Perplexity está a medio camino. Usan un proxy entre el sandbox y la API de Anthropic. Ese es el patrón correcto. Nunca deberías poner una clave API cruda de un proveedor dentro de un sandbox. Un proxy te da control, observabilidad y la capacidad de revocar el acceso sin rotar tu clave maestra.
El problema es que su token de proxy no tiene ningún vínculo con el contexto de ejecución. Una vez que lo tienes, funciona en todas partes para siempre.
Así es como se hace correctamente:
Vincula el token al ID del sandbox. ¿El token y el ID del sandbox no coinciden? Rechazado. ¿La clave se filtra pero no tienes el sandbox? Inútil. Idealmente, también debería vincular el token a la dirección IP del sandbox, pero E2B (el proveedor de sandbox que usan) no proporciona eso antes de que se inicie el sandbox.
Haz el token efímero. Acuñalo cuando el sandbox se inicie. Mátalo cuando el sandbox se pause. Sin credenciales de larga duración. El proxy genera un token de corta duración al inicio de la sesión y lo invalida al finalizar. Una clave filtrada de un sandbox muerto es una clave muerta.
Vincula el token a la cuenta de facturación del usuario. Incluso si todo lo demás falla, incluso si alguien extrae un token vivo de un sandbox activo y lo usa antes de que expire, el uso se factura a la cuenta que inició la sesión. No a un pool de facturación maestro compartido. Esto convierte "acceso gratuito ilimitado a la API" en "alguien abusando de su propia cuota", que es una severidad completamente diferente.
Estas tres cosas — vinculado al sandbox, efímero, facturado al usuario — son lo que hace que el patrón de proxy realmente funcione. Sin ellas, solo estás añadiendo un salto de red extra que no detiene nada.
Este no es un problema específico de Perplexity. Esta es la arquitectura predeterminada para la infraestructura de agentes en este momento porque es la más rápida de construir. Sistemas de archivos compartidos entre agentes, credenciales de larga duración, facturación de cuenta maestra. Apostaría a que la mayoría de los productos multiagente en producción hoy tienen alguna versión de esto.
Reportado a @AravSrinivas y @denisyarats antes de publicar.
