Hace dos días después de su lanzamiento, el agente de IA de Snowflake ejecutó malware en el equipo de un usuario. Sin pedirle permiso. Sin disparar alertas. Sin que el sandbox hiciera nada útil para detenerlo.
El incidente —ya parchado en la versión 1.0.25 del CLI, lanzada el 28 de febrero de 2026— revela algo más incómodo que un simple bug: que los sistemas de allow-list para validar comandos en agentes de IA son estructuralmente inadecuados para el nivel de amenaza que existe hoy.
¿Qué pasó exactamente?
Snowflake Cortex Code es un agente CLI de programación similar a Claude Code o Codex, con integración adicional para ejecutar SQL en Snowflake. La vulnerabilidad fue identificada por PromptArmor dos días después del lanzamiento.
Claude Desbloqueado
Mi curso avanzado para aprender a sacarle mucho más provecho a Claude en el trabajo y en el día a día, con funciones y usos más potentes. Comienza el 23 de marzo.
→ Inscríbete hoy 🚀La cadena de ataque es así: un usuario le pide a Cortex que revise un repositorio de código externo. En el README de ese repositorio, oculta al final, hay una instrucción de prompt injection. El agente explora el repositorio, encuentra la instrucción y la sigue. La instrucción le dice que ejecute un comando que parece un cat —que Cortex consideraba seguro ejecutar sin aprobación humana— pero en realidad usa process substitution para ejecutar un script descargado desde un servidor del atacante.
El resultado: ejecución de código arbitrario en el equipo de la víctima, con acceso a las credenciales activas de Snowflake. Exfiltración de datos, borrado de tablas — lo que el atacante decida.
La falla técnica específica: Cortex validaba el comando principal (cat) pero no el contenido dentro de las expresiones de process substitution (<(...)), que permiten ejecutar cualquier subcomando como si fuera un archivo. El sandbox estaba mirando la forma del comando, no lo que realmente hacía.
¿Por qué esto seguirá pasando?
Este tipo de vulnerabilidad no es nueva. En 2025, Cline fue comprometida vía títulos de GitHub Issues que contenían prompt injections, afectando miles de máquinas de desarrolladores. El patrón se repite: agente con acceso a herramientas + datos no confiables + validación basada en allow-lists = superficie de ataque.
Simon Willison, que amplió el caso en su blog, es directo sobre el problema: los allow-lists contra patrones de comandos le parecen “inherentemente poco confiables.” Su propuesta alternativa es tratar los comandos del agente como si pudieran hacer cualquier cosa que el proceso tiene permiso de hacer, y usar sandboxes determinísticos que operen fuera de la capa del agente —no dentro de él.
La diferencia es crítica: un sandbox que el propio agente puede desactivar (o que puede ser evadido mediante process substitution) no es un sandbox real. Es una ilusión de seguridad. Y en agentes con acceso a herramientas reales, esa ilusión es peligrosa.
La Regla de Dos de Meta para agentes — no combinar inputs no confiables + acceso a datos sensibles en el mismo agente — aplica directamente aquí: Cortex combina input de repositorios externos (no confiables) con credenciales activas de Snowflake (muy sensibles). Esa combinación es estructuralmente riesgosa sin medidas adicionales.
¿Qué cambia con el parche?
Snowflake parchó la vulnerabilidad específica de process substitution en la versión 1.0.25. El fix resuelve este vector de ataque concreto. Pero el problema de fondo —que los agentes CLI exploran código arbitrario de terceros y ejecutan herramientas con credenciales activas— sigue siendo el mismo.
Cortex tampoco implementa “workspace trust”, una convención de seguridad que los editores de código adoptaron hace tiempo y que advierte al usuario de los riesgos de trabajar en directorios nuevos y potencialmente no confiables. Sin esa capa de conciencia contextual, el usuario no tiene señales para saber cuándo debería ser más cauteloso.
OpenAI introdujo Lockdown Mode en ChatGPT precisamente para mitigar este tipo de escenarios en contextos enterprise. La dirección correcta es hacia más restricciones configurables por el usuario o la organización — no menos.
Por qué importa más allá de Snowflake
Cortex Code no es un caso aislado. Es un recordatorio de que cada herramienta que combine:
- Un agente con capacidad de ejecutar comandos en el sistema
- Acceso a datos o credenciales del usuario
- Input de fuentes externas (repositorios, URLs, resultados de búsqueda, respuestas MCP)
…tiene la misma superficie de ataque. La pregunta no es si tu herramienta tiene prompt injections escondidas en algún repo que tu agente podría explorar —la pregunta es cuánto daño puede hacer si las encuentra.
Para desarrolladores que usan agentes de código: revisar qué herramientas tiene habilitadas tu agente, qué puede ejecutar sin aprobación, y si tus credenciales están disponibles en el contexto donde el agente opera. El principio de mínimo privilegio aplica aquí igual que en cualquier sistema de seguridad.
