Enrutadores de API LLM maliciosos: el hombre en el medio sin vigilancia de los agentes

¿Qué es esto?

Un enrutador de API LLM es un proxy situado entre tu agente y el proveedor del modelo de origen — OpenAI, Anthropic, Google y otros — para gestionar el balanceo de carga, la conmutación entre proveedores, el seguimiento de costes y la limitación de velocidad. Las pasarelas tipo LiteLLM y el patrón de «base URL compatible con OpenAI» están por todas partes en las pilas de agentes, y los desarrolladores dirigen sus clientes a estos puntos de acceso de forma voluntaria.

En «Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain» (arXiv:2604.08407, enviado el 9 de abril de 2026), investigadores de la Universidad de California en Santa Barbara realizaron el primer estudio sistemático de esta superficie de ataque. Compraron 28 enrutadores de pago en mercados como Taobao, Xianyu y tiendas alojadas en Shopify, y recopilaron 400 enrutadores gratuitos de GitHub y comunidades públicas. El hallazgo, recogido por CybersecurityNews (10 de abril) y Risky Business (15 de abril): una parte considerable de estos intermediarios era activamente maliciosa.

Cómo funciona

El problema estructural es la ausencia de garantía de integridad. El enrutador termina la conexión TLS del cliente y reabre una nueva hacia el proveedor de origen, por lo que tiene acceso en texto plano a cada carga útil JSON en tránsito. A diferencia de un ataque de hombre en el medio de red clásico, no se necesita falsificar ningún certificado: el desarrollador configuró el proxy como su punto de acceso de API. Y ningún gran proveedor vincula criptográficamente la llamada a herramienta que ejecuta el agente con la salida real del modelo. Nada se interpone entre un enrutador malicioso y el flujo de solicitud/respuesta.

El artículo formaliza dos clases de ataque principales:

• Inyección de carga útil (AC-1): el enrutador reescribe una llamada a herramienta devuelta, por ejemplo sustituyendo la URL de un instalador o el nombre de un paquete benigno por una versión controlada por el atacante. Como la carga JSON manipulada sigue siendo sintácticamente válida, supera la validación de esquema; basta una sola orden de shell reescrita para ejecutar código en el cliente.
• Exfiltración de secretos (AC-2): el enrutador recolecta de forma pasiva claves de API y credenciales del tráfico en texto plano sin alterar ninguna respuesta, de modo que el comportamiento aguas abajo parece totalmente normal.

Dos variantes adaptativas elevan el listón de la detección: la inyección dirigida a dependencias (AC-1.a) y la entrega condicional (AC-1.b), donde las cargas útiles solo se activan tras un historial limpio (por ejemplo, 50 solicitudes) o únicamente contra sesiones autónomas en «modo YOLO», donde la ejecución de herramientas se autoaprueba.

De los 428 enrutadores probados, el equipo reporta 9 inyectando activamente código malicioso (1 de pago, 8 gratuitos), 2 usando disparadores de evasión adaptativos, 17 enrutadores gratuitos que tocaron credenciales AWS «canario» propiedad de los investigadores y 1 que vació ETH de una clave privada propiedad de un investigador. Aquí no se reproduce ninguna carga útil de explotación, y ninguna hace falta para entender la lección.

Por qué importa

El radio de impacto supera el simple punto de acceso defectuoso. Los enrutadores forman una malla de nodos proxy, y el tráfico rebota entre ellos según la carga: un único nodo comprometido puede hacer que otros enrutadores reenvíen sus órdenes maliciosas y alcanzar toda la flota de agentes de una organización. Un solo nodo débil puede comprometer toda la capa de control de costes y exponer a cada usuario que esté detrás de él.

Dos experimentos de envenenamiento muestran que incluso enrutadores de apariencia benigna acaban absorbidos por la misma superficie. Tras filtrar deliberadamente una clave de OpenAI propiedad de un investigador en foros y mensajería chinos, esta generó alrededor de 100 millones de tokens GPT-5.4 y expuso credenciales en varias sesiones Codex aguas abajo. Un segundo estudio que desplegó proxies señuelo débiles atrajo unos 40 000 intentos de acceso no autorizados, sirvió aproximadamente 2 000 millones de tokens facturados, expuso 99 credenciales en 440 sesiones Codex — y 401 de esas 440 sesiones ya corrían en modo YOLO autónomo, donde las órdenes se ejecutan sin confirmación por llamada.

Esto se solapa directamente con los riesgos de cadena de suministro y de agencia excesiva que el campo ya rastrea. La combinación peligrosa es un agente de alta autonomía + un intermediario no confiable + ejecución de herramientas autoaprobada — véase nuestra cobertura de la tríada letal y de la regla de dos de los agentes de Meta.

Defensas

Los investigadores son claros: ningún control del lado del cliente puede autenticar plenamente la procedencia de una llamada a herramienta devuelta sin el apoyo del proveedor. No obstante, tres medidas se despliegan hoy mismo sin cooperación del proveedor:

• Compuerta de política «fail-closed». Permitir solo órdenes extraídas de una lista blanca local; el artículo indica que esto bloquea los ataques de reescritura de shell e inyección de dependencias con una tasa de falsos positivos de aproximadamente 1,0 %. Salvedad: se puede eludir si el atacante aloja sus cargas en un dominio ya autorizado, así que combina la lista blanca con fuentes de paquetes fijadas y verificadas.
• Cribado de anomalías del lado de la respuesta. Un modelo IsolationForest entrenado con llamadas a herramientas benignas señaló alrededor del 89 % de los intentos de inyección de carga útil con un presupuesto del 6,7 % de falsos positivos. Trata las respuestas del enrutador como entrada no confiable y críbalas antes de que cualquier herramienta actúe.
• Registro en modo solo-añadir (append-only). Registrar todos los metadatos de solicitud/respuesta, los datos TLS y los hashes de respuesta (~1,26 KB por entrada) para acotar un incidente de forma forense a posteriori.

Más allá de eso, la higiene operativa es sencilla: trata cada enrutador de terceros como un adversario potencial. Prefiere los puntos de acceso directos del proveedor o pasarelas autoalojadas que controles; restringe las claves de API al mínimo privilegio y rótalas con agresividad; nunca ejecutes agentes en modo autoaprobación/YOLO contra un punto de acceso que no operes; y exige confirmación humana para acciones irreversibles (instalación de paquetes, transferencias de fondos, uso de credenciales). Los autores sostienen que la solución duradera son sobres de respuesta firmados por el proveedor — un mecanismo «DKIM para llamadas a herramientas» que vincula criptográficamente las llamadas ejecutadas con la salida real del modelo de origen. Hasta que los proveedores lo implementen, los controles del lado del cliente, por capas, son la defensa.

Estado

Elemento	Detalle
Fuente	arXiv:2604.08407, UC Santa Barbara
Divulgación	9 de abril de 2026 (preprint)
Enrutadores probados	28 de pago + 400 gratuitos (428 en total)
Inyección de código malicioso	9 enrutadores (1 de pago, 8 gratuitos)
Evasión adaptativa	2 enrutadores
Acceso a credenciales	17 enrutadores tocaron canarios AWS; 1 vació ETH
Corrección del proveedor	Ninguna aún — sin integridad criptográfica cliente↔origen
Defensas del lado del cliente	Compuerta de política, cribado de anomalías, registro

El encuadre no es «existen algunos proxies dudosos». Es que el enrutador LLM es una frontera de confianza permanente, introducida por el desarrollador y sin garantía de integridad, y que los agentes de alta autonomía encarecen especialmente su compromiso. Elige tus intermediarios con tanto cuidado como tus dependencias, porque, funcionalmente, eso es lo que son.