Cuando una skill de agente envenenada se esconde en las falsas alarmas

¿De qué se trata?

Las «skills» de agente son una forma ligera de ampliar un agente de propósito general: una carpeta con una descripción breve, instrucciones en prosa y, a veces, algo de código, distribuida a través de marketplaces y repositorios abiertos. Esa apertura es también una superficie de ataque. Una skill envenenada puede transportar una instrucción del atacante que el agente ejecuta mientras hace lo que el usuario realmente pidió.

Un artículo publicado el 6 de junio de 2026 por un equipo de la Universidad de Illinois en Chicago — POISE: Position-Aware Undetectable Skill Injection on LLM Agents (arXiv:2606.07943) — estudia por qué algunos de estos intentos tienen éxito y otros son detectados, y llega a una conclusión incómoda: los escáneres LLM estáticos en los que muchos equipos confían para verificar skills pueden eludirse no ocultándose más, sino fundiéndose en el ruido que esos escáneres ya producen.

Cómo funciona

Los investigadores miden el ataque con una definición estricta de éxito: la carga inyectada debe ejecutarse realmente y la tarea legítima del usuario debe seguir superando su verificador en el mismo intento. Esa segunda condición importa. Si ejecutar la carga descarrila la tarea del usuario, el fallo visible invita a que alguien abra la skill y la revise, de modo que una inyección «exitosa» es la que permanece invisible.

Bajo esta óptica, las técnicas de envenenamiento previas chocan con un compromiso entre fiabilidad y sigilo. Las inyecciones colocadas en la cabecera YAML de una skill se cargan de forma fiable, pero son triviales de inspeccionar. Las inyecciones enterradas en el cuerpo en prosa son más sigilosas, pero tienden a ser poco fiables: una orden fuera de contexto en medio de instrucciones por lo demás coherentes puede despertar la propia sospecha del agente y ser ignorada.

El aporte del artículo es posicional, no una carga nueva. En lugar de introducir una orden evidente en la prosa, la técnica comprime el desencadenante en una única instrucción de aspecto inofensivo y la coloca donde tal instrucción encajaría de forma plausible —junto a pasos de configuración o de requisitos previos— usando un generador sensible al contexto para que se lea como una parte natural de la skill. No reproducimos deliberadamente la construcción aquí; la lección es el principio de colocación, no una receta lista para copiar.

Las cifras reportadas son lo que hace notable el resultado. En el banco de pruebas Skill-Inject de los autores, el enfoque alcanzó una tasa de éxito del ataque del 89,3 %, muy por encima de una base con colocación aleatoria en el cuerpo y ligeramente por encima de una base «solo cabecera», conservando el sigilo de la colocación en el cuerpo. El hallazgo decisivo atañe a los defensores: como los cuerpos de skills legítimas suelen requerir operaciones de herramientas privilegiadas, los escáneres LLM pensados para detectar abusos son hipersensibles y marcaron erróneamente el 74,6 % de las skills limpias de media, entre cuatro modelos jueces y dos bancos de pruebas. Las variantes envenenadas se funden en ese diluvio de falsos positivos: solo el 5,6 % de ellas generó una nueva alerta de alto riesgo respecto a su versión limpia. Un escáner que alerta sobre todo, en la práctica, no alerta sobre nada.

Por qué importa

Es un problema de cadena de suministro disfrazado de problema de moderación de contenido. Cada vez más equipos filtran las skills de terceros mediante un paso de «escáner de seguridad LLM» y tratan un veredicto «limpio» como una autorización de ejecución. Esta investigación sugiere que ese veredicto carece casi de sentido cuando la tasa de falsas alarmas es tan alta: los operadores se ahogan en el ruido o suben discretamente el umbral hasta que los ataques reales pasan junto con todo lo demás.

El resultado se generaliza más allá de este único banco de pruebas. Cualquier pipeline que dependa de una revisión estática, previa a la ejecución, de instrucciones no confiables por parte de un modelo de lenguaje hereda la misma debilidad: el revisor no puede separar limpiamente «una skill que legítimamente necesita tocar el sistema de archivos y la red» de «una skill que abusa precisamente de esas capacidades», porque sobre el papel se parecen. La señal distintiva está en lo que la skill hace en ejecución, no en cómo se lee su prosa de antemano.

Defensas

Deje de tratar un veredicto «limpio» del escáner como autorización. Una revisión LLM previa a la ejecución es un filtro débil, no una barrera. Si su único control es un escaneo estático, la investigación indica que está expuesto. Mida la tasa de falsos positivos de su escáner sobre skills reputadas limpias antes de confiar en sus negativos: un detector que marca la mayoría de las entradas limpias aporta casi ninguna información cuando calla.

Traslade la frontera a la autoridad en tiempo de ejecución. Aplique el mínimo privilegio a lo que una skill puede hacer realmente: acote el acceso al sistema de archivos y a la red por skill, exija concesiones de capacidades explícitas en lugar de permisos ambientales, y coloque una confirmación humana ante las llamadas a herramientas privilegiadas o irreversibles. Otras investigaciones de este trimestre —por ejemplo detectores de señales internas que observan las propias activaciones del agente durante la ejecución (RouteGuard, arXiv:2604.22888)— apuntan en la misma dirección: detectar el comportamiento, no la redacción.

Establezca procedencia e integridad. Prefiera skills firmadas de editores conocidos, fije versiones y compare («diff») las actualizaciones para que una instrucción de cuerpo modificada discretamente sea visible en la revisión. Trate por defecto como no confiable una skill sin firmar o recién publicada por una fuente anónima.

Aísle la ejecución. Ejecute las skills en un contexto aislado, con capacidades reducidas, sin credenciales permanentes y sin red saliente por defecto, para que incluso una carga que se ejecute no pueda alcanzar secretos, puntos de metadatos ni vías de exfiltración.

Registre y audite el comportamiento, no solo la intención. Registre las llamadas a herramientas que realiza una skill y compárelas con lo que decía necesitar. La auditoría de comportamiento a posteriori detecta los casos que una revisión textual previa no puede ver por diseño.

Estado

Elemento	Detalle
Tipo	Investigación académica (ataque de envenenamiento de skill + análisis de defensa)
Publicación	6 de junio de 2026 (enviado el 11 de junio de 2026)
Fuente	arXiv:2606.07943 — University of Illinois Chicago
Probado en	Banco de pruebas Skill-Inject, codex + gpt-5.2
Resultado clave	89,3 % de éxito de ataque; 74,6 % de falsos positivos sobre skills limpias; 5,6 % de skills envenenadas que generan una nueva alerta de alto riesgo
Código	github.com/liofoil/SkillSafety
Para recordar	Los escáneres LLM estáticos son barreras poco fiables; imponga el mínimo privilegio en ejecución y la auditoría de comportamiento