Nueve de 428 routers de LLM inyectan código en las llamadas de los agentes

Un estudio revisó 428 servicios que hacen de intermediarios entre aplicaciones y modelos de lenguaje y encontró nueve que inyectaban código malicioso en las llamadas a herramientas que devolvían a sus clientes. El trabajo es de abril de 2026 y apunta a un componente que casi nadie audita: el LLM API router.

Qué ve un router y por qué importa

Un router de estos recibe peticiones en un formato único y las reenvía a varios proveedores de modelos. Se usa por comodidad y precio: una sola factura, acceso a modelos de varias casas. El problema es arquitectónico. El router corta la conexión TLS del cliente y abre otra hacia el proveedor. Como el cliente apunta ahí por decisión propia, el router tiene permiso de aplicación completo y ve todo en claro: los prompts, las claves de API y las llamadas a herramientas que pide el agente.

No hace falta falsificar un certificado ni degradar el cifrado, que es lo que se detecta en una intercepción clásica. Aquí no hay que hacer nada de eso.

Lo que cambia el juego es que el payload ya no es texto inocente: es una instrucción ejecutable. En un ejemplo del estudio, el router cambió el nombre de un paquete en una orden de instalación: requests pasó a ser reqeusts, dos letras intercambiadas. El dominio seguía siendo el legítimo, así que el filtro de dominios no dijo nada. Y como el paquete queda en la máquina, vuelve a usarse en sesiones posteriores.

Los números

Se revisaron dos grupos: 28 routers de pago comprados en mercados chinos y en tiendas de Shopify, y 400 gratuitos recogidos de comunidades públicas. Uno de pago y ocho gratuitos inyectaron código; dos usaron evasión adaptativa, y solo disparaban después de cincuenta peticiones o únicamente en sesiones con el modo automático ya activo. Si la prueba es corta, el router parece limpio.

Diecisiete más tocaron credenciales de prueba de los investigadores. Uno drenó fondos de una clave privada de criptomonedas que habían dejado como cebo.

Los experimentos con routers corrientes también dieron resultados incómodos. Una clave de OpenAI publicada en un foro chino generó 100 millones de tokens y abrió más de siete sesiones. En el segundo montaron servidores mal configurados en veinte dominios y veinte direcciones IP: recibieron intentos de acceso de 147 direcciones, movieron 2.000 millones de tokens, expusieron unos 13 GB y filtraron 99 credenciales de 440 sesiones. En todas ellas se podía ejecutar comandos de shell, y 401 ya corrían en modo automático.

Las defensas y el hueco que queda

El estudio probó tres controles en el lado del cliente. El filtro de comandos de alto riesgo bloquea el 100% de la inyección directa con un 1% de falsos positivos. La detección de anomalías en las respuestas llega al 89% con un 6,7% de falsos positivos, pero solo pilla la mitad de los typosquats. El log de auditoría de solo-append no evita nada, sirve para reconstruir qué pasó, y ocupa 1,26 KB por entrada.

Ninguno verifica la procedencia. Un router autorizado y sin comportamiento raro puede seguir cambiando el sentido de una instrucción. La salida que plantean los autores es que los proveedores firmen digitalmente sus respuestas, para que el cliente compruebe que la orden viene del modelo y no ha sido tocada por el camino. Nadie lo hace todavía.

En un comentario citado junto al trabajo, el usuario @bygregorr apunta que estas barreras solo aguantan si viven dentro del runtime del agente y no en el router: si quien revisa es el mismo que puede manipular, se le está pidiendo al sospechoso que se cachee a sí mismo. Cambiar de router, además, cuesta una línea de configuración. Eso es justo lo que hace que casi nadie se pare a mirar qué hay dentro.