Las denylists de comandos son la defensa equivocada para los agentes de IA en terminal

¿Qué es esto?

El 20 de junio de 2026, Chuyang Chen y Zhiqiang Lin (The Ohio State University) publicaron One Goal, Many Commands: Characterizing Denylist Fragility in AI Agents (arXiv 2606.15549). Es el primer estudio sistemático de un control en el que se apoyan con fuerza la mayoría de los agentes de codificación en terminal: la denylist de comandos, la lista de comandos de shell que un agente se niega a ejecutar.

La conclusión es tajante. Al aplicar un pipeline automático a 1709 denylists reales recopiladas de GitHub —13 332 reglas en total—, los autores informan de que entre el 69,0 % y el 98,6 % de esas denylists son «frágiles»: no logran bloquear operaciones que fueron escritas explícitamente para bloquear. Incluso la denylist que viene por defecto con un agente de uso extendido, mantenida por sus propios desarrolladores, pasa por alto comandos que alcanzan el resultado prohibido por otra vía.

El resultado corresponde a la categoría de ejecución de código inesperada (ASI05) del OWASP Top 10 for Agentic Applications (2026) y figuró entre los puntos destacados del digest de agentes de codificación de julio de 2026 de Adversa.

Cómo funciona

Los agentes en terminal como Claude Code y Codex regulan la ejecución de shell con un mecanismo de tres listas: una allowlist de comandos evidentemente seguros se ejecuta de forma automática, una denylist de comandos evidentemente peligrosos se rechaza de entrada, y todo lo demás cae en una «ask-list» que se escala a una persona o a un juez LLM para su aprobación.

Dos hechos convierten a la denylist en el elemento portante del diseño. Primero, los comandos de la denylist se suponen categóricamente peligrosos: el rechazo debe ser absoluto. Segundo, el artículo cita datos que muestran que los usuarios aprueban alrededor del 93 % de las solicitudes de ejecución de comandos, de modo que la fatiga de aprobación reduce la ask-list a una allowlist de facto. Si la denylist tiene fugas, queda poco sosteniendo la línea.

Y tiene fugas de forma estructural, porque una denylist enumera cadenas de texto mientras que un sistema operativo ofrece muchos caminos hacia el mismo efecto. Una regla que bloquea un nombre de comando no hace nada frente a una utilidad menos conocida de capacidad equivalente, ni frente a una herramienta multipropósito legítima invocada en un modo que alcanza el mismo resultado. La herramienta del estudio, ShellSieve, usa un LLM para proponer evasiones candidatas para cada operación denegada y luego las confirma ejecutándolas en un sandbox y observando los efectos secundarios que dejan: sin suposiciones, sin falsos positivos. Las dos causas raíz confirmadas estadísticamente son exactamente estas: los autores omiten comandos oscuros que nunca han visto, y dejan deliberadamente fuera de la lista comandos multipropósito para preservar sus usos benignos, sin percatarse de que esos mismos comandos sirven también como evasión.

Los autores también cuantifican la trampa de mantenimiento: completar una denylist frágil para que bloquee de verdad sus operaciones objetivo requiere, de media, 217 comandos adicionales, una carrera armamentística imposible de ganar frente a una superficie de comandos abierta.

Por qué importa

No es un fallo aislado de un producto; es un juicio sobre toda una categoría de control. La denylist es la primera defensa intuitiva a la que recurren los equipos que conectan un agente a un shell, y es la que estos datos señalan como la menos fiable. En un bucle de agente de codificación autónomo, la operación al otro lado de una denylist con fugas no es un cuadro de diálogo de advertencia: es un borrado de archivos, un acceso a credenciales, una exfiltración de red o un punto de apoyo que el propio agente ejecuta en el host con los privilegios del usuario.

El problema se agrava con la autonomía. Una persona tecleando comandos es un adversario lento y deliberado. Un agente que sintetiza comandos para satisfacer una instrucción inyectada o malformada puede enumerar formulaciones alternativas más rápido de lo que cualquier blocklist mantenida a mano puede crecer para cubrirlas.

Defensas

El propio planteamiento del artículo señala el camino: dejar de tratar la denylist como la frontera principal.

1. Prefiera allowlists a denylists para todo lo que tenga un radio de impacto real. Una allowlist falla en posición cerrada: un comando desconocido se rechaza por defecto. Una denylist falla en posición abierta: un comando desconocido se ejecuta. Para contextos de alto impacto, enumere lo que está permitido, no lo que está prohibido.
2. Aplique el control en el SO, no en la cadena de texto. Un control que inspecciona texto siempre irá por detrás de la semántica del shell. Los controles a nivel de núcleo y de contenedor —seccomp, montajes restringidos, ausencia de credenciales ambientales, allow-lists de egreso— acotan lo que cualquier comando puede hacer, se escriba como se escriba.
3. Aísle la superficie de ejecución del agente. Entornos efímeros y aislados, con privilegios mínimos sobre el sistema de archivos y la red, convierten una evasión de denylist de un compromiso en un incidente contenido. Es la dirección hacia la que converge la investigación de agentes de codificación de julio de 2026.
4. No dependa de la aprobación humana como red de seguridad. Con ~93 % de aprobación indiscriminada, la ask-list no es una barrera real. Reserve las solicitudes para acciones realmente raras y realmente críticas, de modo que una solicitud siga portando señal.
5. Si mantiene una denylist, pruébela de forma adversarial. El descubrimiento automático de evasiones, del tipo que describe este artículo, tiene su lugar en la CI, para que la cobertura real de una denylist se mida en lugar de suponerse.

Estado

Elemento	Referencia	Fecha	Notas
Estudio de fragilidad de denylists	arXiv 2606.15549 v2	2026-06-20	Chen y Lin, Ohio State; 69,0–98,6 % de denylists frágiles
Corpus analizado	—	2026-06	1709 denylists reales, 13 332 reglas de GitHub
Cifra de fatiga de aprobación	citada en el artículo	2026	~93 % de solicitudes de comando aprobadas
Categoría	OWASP Top 10 for Agentic Apps 2026	2026	ASI05 — ejecución de código inesperada

Se trata de una caracterización de investigación, no de un exploit divulgado contra un producto concreto, y el artículo no aporta ningún payload de evasión listo para copiar. Su lección operativa es independiente del modelo y del proveedor: si la seguridad de un agente con acceso a shell descansa sobre una lista de comandos que se niega a ejecutar, esa seguridad es, a la vista de estos datos, en buena parte una ilusión, y la solución vive en el aislamiento y el mínimo privilegio, no en una blocklist más larga.