Tu agente tiene un intermediario que no verificaste

Investigadores compraron 28 routers pagos de API de LLM en Taobao, Xianyu y tiendas alojadas en Shopify, y recolectaron 400 más de comunidades públicas. Instrumentaron las solicitudes con credenciales plantadas y sondearon cada router para ver qué hacía con el tráfico.¹

Diecisiete de esos routers tocaron credenciales canary de AWS plantadas en las solicitudes. Uno drenó ETH de una clave privada colocada como cebo. Una clave filtrada de OpenAI que el equipo configuró como honeypot generó 100M de tokens de GPT-5.4 y, según el resumen, “más de siete sesiones de Codex” antes de retirarla.¹ Otros señuelos débilmente configurados produjeron 2B de tokens facturados, 99 credenciales en 440 sesiones de Codex y 401 sesiones ya ejecutándose en modo YOLO autónomo.¹

El router de API de LLM es la nueva superficie de ataque. Nadie lo está auditando.

Las cadenas de confianza de MCP son la serie de intermediarios (routers de API, proxies y servidores de herramientas) que se ubican entre tu agente de IA y el modelo upstream, cada uno con acceso completo en texto plano a cada solicitud y respuesta. Ningún proveedor aplica integridad criptográfica de extremo a extremo, lo que significa que cualquier intermediario puede leer, modificar o exfiltrar datos en tránsito. La investigación de campo encontró que 17 de 28 routers pagos tocaron credenciales plantadas de AWS, y uno drenó ETH de una clave privada, demostrando que los eslabones no verificados de la cadena de confianza son superficies de ataque activas.

TL;DR

Los routers de API de LLM de terceros son proxies de capa de aplicación con acceso completo en texto plano a cada carga útil de JSON en tránsito entre tu agente y el modelo upstream. Ningún proveedor aplica integridad criptográfica entre el cliente y el upstream. Un nuevo artículo de arxiv de Liu, Shou, Wen, Chen y Fang presenta el primer estudio sistemático de esta superficie de ataque, y los datos de campo son feos: 1 de 28 routers pagos y 8 de 400 routers gratuitos estaban inyectando activamente código malicioso en las respuestas, 2 estaban desplegando disparadores de evasión adaptativa, 17 tocaron credenciales canary plantadas de AWS y 1 drenó ETH de una clave privada plantada.¹ Los autores formalizan dos clases de ataque centrales más dos variantes de evasión adaptativa, luego construyen un proxy de investigación llamado Mine que implementa “las cuatro clases de ataque” (su fraseo) contra cuatro frameworks de agentes públicos y evalúan tres defensas desplegables del lado del cliente.¹ Si tu agente está usando un router que no construiste, tienes un límite de confianza que nunca auditaste.

Puntos clave

• Operadores de agentes: Cada router de API de LLM entre tu cliente y el modelo upstream es un proxy de capa de aplicación con acceso en texto plano a cada solicitud y respuesta. Ningún proveedor aplica integridad criptográfica. Si compraste un router en un marketplace o lo sacaste de una lista comunitaria pública, trátalo como un intermediario hostil hasta que lo hayas verificado de forma independiente.
• Constructores de harness: Tus hooks PreToolUse se ejecutan antes de la ejecución de herramientas, pero un router malicioso modifica la respuesta del modelo después de la generación y antes de que llegue a tu hook. Añade validación del lado de la respuesta a tu stack de hooks, y considera puertas de política fail-closed para formas de respuesta anómalas.
• Cualquiera que ejecute modo YOLO: Cuatrocientas una sesiones en el honeypot de los investigadores ya estaban ejecutándose en modo YOLO autónomo.¹ Un router que modifica llamadas a herramientas en una sesión autónoma tiene un radio de explosión mucho mayor que un router que modifica una respuesta que vas a leer. No ejecutes modo YOLO a través de un router que no controles.

¿Qué es un router, exactamente?

En el contexto de este artículo, un router de API de LLM es un servicio de terceros que se ubica entre tu cliente y uno o más proveedores de modelos upstream. Envías solicitudes al router usando una API compatible con OpenAI. El router despacha esas solicitudes a cualquier upstream que elija (GPT-5, Claude, Gemini, un modelo de pesos abiertos, un pool de todos ellos) y te devuelve la respuesta con la misma forma.¹

Los routers existen porque el ecosistema de LLM es desordenado. La gente quiere una sola clave API que funcione contra cada modelo. La gente quiere arbitraje de precios: comprar tokens al por mayor, revenderlos más baratos. La gente quiere soluciones geográficas para regiones donde el acceso directo al proveedor está restringido. La gente quiere probar múltiples modelos con un solo cliente. Todas estas son razones legítimas, y un mercado de routers saludable atiende a todas ellas.

El problema es que un router es un proxy de capa de aplicación. No solo reenvía bytes. Lee la JSON de la solicitud, elige un upstream, opcionalmente reescribe la solicitud, la reenvía, lee la respuesta, opcionalmente reescribe la respuesta, y la devuelve. Cada paso de ese pipeline ocurre en texto claro en la infraestructura del router.¹

No hay un equivalente de TLS aquí. TLS protege los bytes desde tu cliente hasta el router y desde el router hasta el modelo upstream. No hace nada para proteger la carga útil del router. Ningún proveedor aplica integridad criptográfica entre el cliente original y el modelo final. No existe una aserción firmada de que la solicitud que recibió el modelo sea la misma solicitud que envió el cliente, y no existe una aserción firmada de que la respuesta que recibió el cliente sea la misma respuesta que generó el modelo.¹

Esa ausencia es la superficie de ataque.

Los datos de campo

Los investigadores compraron 28 routers pagos en tres marketplaces (Taobao, Xianyu, tiendas alojadas en Shopify) y recolectaron 400 routers gratuitos de comunidades públicas. Ejecutaron cada router a través de una serie de pruebas con solicitudes instrumentadas que contenían credenciales plantadas, cargas útiles conocidas y cadenas marcadoras.¹

Esto es lo que encontraron:

El hallazgo de evasión adaptativa es el que debería quitarte el sueño. Un disparador de evasión adaptativa significa que el router se comporta normalmente la mayor parte del tiempo y cambia a comportamiento de ataque bajo condiciones específicas: una forma particular de solicitud, una huella particular del cliente, una cadencia particular. No puedes atraparlo muestreando solicitudes aleatorias, porque el router sabe cuándo está siendo muestreado y se comporta.

Las credenciales canary son trampas: se disparan cuando alguien intenta usarlas. Que diecisiete routers las “tocaran” significa que al menos diecisiete routers extrajeron las credenciales de cargas útiles en tránsito e intentaron usarlas contra AWS.¹ El resumen no detalla el mecanismo exacto por router, pero el diseño de la trampa significa que tocar = usar.

El único router que drenó ETH de una clave privada propiedad del investigador es un hallazgo más contundente. Una clave privada en un prompt no es una trampa de credenciales; es un cebo que solo produce evidencia de compromiso cuando el router realmente drena la billetera. Un router lo hizo.¹

Los dos estudios de envenenamiento

Los investigadores ejecutaron dos estudios adicionales para mostrar que routers aparentemente benignos pueden ser arrastrados a la misma superficie de ataque a través de la exposición de terceros.

Estudio 1: Clave de OpenAI filtrada. Los investigadores filtraron una clave API de OpenAI funcional como si hubiera sido expuesta por un error de desarrollador. Durante la ventana de observación, esa única clave filtrada, según el resumen, generó 100M de tokens de GPT-5.4 y “más de siete sesiones de Codex” a través de routers que la recogieron.¹ Alguien (o muchos alguien) encontró la clave, enrutó solicitudes a través de routers comunitarios usándola, y quemó 100M de tokens de cómputo. El router fue una capa de lavado para una clave robada.

Estudio 2: Señuelos débilmente configurados. Los investigadores levantaron endpoints de señuelo débilmente configurados. Los señuelos produjeron 2B de tokens facturados, 99 credenciales en 440 sesiones de Codex y, críticamente, 401 sesiones ya ejecutándose en modo YOLO autónomo.¹

Cuatrocientas una sesiones autónomas ya enrutando a través de un único conjunto de señuelos. Cada una de esas sesiones era una superficie de ataque viva donde un intermediario malicioso podía inyectar llamadas a herramientas, exfiltrar secretos o modificar la salida del modelo, y el agente ejecutaría lo que viniera de vuelta sin un humano en el loop. El número 401 es lo que capturó un único señuelo de investigación. La población operativa que se enruta a través de intermediarios no controlados es necesariamente mayor.

Dos clases de ataque centrales y dos variantes adaptativas

El artículo formaliza dos clases de ataque centrales y dos variantes de evasión adaptativa. El resumen es explícito sobre la taxonomía: AC-1 y AC-2 son las clases centrales; AC-1.a y AC-1.b son variantes de AC-1. El proxy de investigación Mine implementa “las cuatro clases de ataque” (el fraseo del resumen) contra cuatro frameworks de agentes públicos.¹

AC-1: Inyección de carga útil (clase central). El router modifica la respuesta para inyectar instrucciones adicionales, llamadas a herramientas o contenido sobre el cual el agente cliente actúa. El agente cree que está leyendo la salida del modelo; está leyendo la salida de quien sea dueño del router.

AC-2: Exfiltración de secretos (clase central). El router lee secretos de solicitudes y respuestas en tránsito (claves API, tokens, claves privadas, cualquier cosa que parezca una credencial) y los envía a la infraestructura del atacante.

AC-1.a: Inyección dirigida por dependencia (variante adaptativa de AC-1). La inyección solo se dispara cuando la solicitud coincide con una dependencia o contexto específico: solo cuando la solicitud es sobre una biblioteca particular, solo cuando se referencia una función específica, solo cuando ciertas rutas de archivo aparecen en el prompt. El disparador selectivo hace que el ataque sea invisible en pruebas aleatorias.

AC-1.b: Entrega condicional (variante adaptativa de AC-1). El router entrega la carga útil maliciosa solo bajo condiciones específicas (hora del día, cadencia de solicitudes, huella del cliente). La misma lógica de evasión de detección.

Cada una de estas clases de ataque es invisible para el cliente y para el modelo upstream, porque ambos extremos confían en el router. El cliente ve una forma de respuesta normal. El modelo ve una forma de solicitud normal. El router es libre de hacer lo que quiera en el medio, y ninguna de las partes tiene una forma criptográfica de detectar manipulación.¹

El patrón de composición, una capa más abajo

Sigo escribiendo sobre el mismo bug estructural: componentes individualmente autorizados que se componen en comportamiento no autorizado. Trivy-to-LiteLLM fue composición en la capa de paquetes. Egress silencioso fue composición en la capa de descripción de herramientas. El envenenamiento de herramientas MCP fue composición en la capa de protocolo. El compromiso del mantenedor de axios fue composición en la capa de mantenedor humano.

El ataque al router es composición en la capa de red. Tu cliente está autorizado a llamar al router. El router está autorizado a llamar al modelo upstream. El modelo upstream está autorizado a responder. Cada salto individual está autorizado. La composición de esos saltos autorizados produce inyección de carga útil y exfiltración de secretos a escala porque la composición cruza un límite de confianza que nadie se molestó en sellar criptográficamente.¹

No puedes arreglar esto en ninguna capa individual. Lo arreglas en la capa de composición, lo que significa que el cliente tiene que tratar al router como hostil hasta que haya verificado de forma independiente que la forma de la respuesta, las llamadas a herramientas y el contenido son todos consistentes con algo que el modelo upstream plausiblemente produciría.

Tres defensas que el artículo evalúa

El artículo evalúa tres defensas del lado del cliente contra las clases de ataque.¹

1. Puerta de política fail-closed. El cliente aplica una política sobre las formas de respuesta, llamadas a herramientas permitidas, URLs permitidas, comandos permitidos. Cualquier cosa fuera de la política falla cerrada: el cliente rechaza la solicitud en lugar de permitirla.

2. Detección de anomalías del lado de la respuesta. El cliente vigila anomalías en la forma de la respuesta, patrones de tokens inusuales, o salidas que contengan marcadores de ataque conocidos (URLs a hosts desconocidos, patrones sospechosos de credenciales, estructuras inusuales de llamadas a herramientas).

3. Registro de transparencia append-only. El cliente escribe cada solicitud y respuesta en un log append-only que nadie puede modificar retroactivamente. El registro no previene ataques, pero los hace trazables forensemente.

Ninguna de estas es una bala de plata. Mi lectura: la puerta de política fail-closed es la más fuerte de las tres porque rechaza cualquier cosa fuera de una lista de permitidos explícita en lugar de intentar detectar un ataque, pero el resumen no clasifica las defensas, así que trátalo como mi opinión, no como el hallazgo del artículo. La detección de anomalías pierde ataques que parecen normales, y las variantes de evasión adaptativa (AC-1.a y AC-1.b) específicamente imitan el comportamiento normal durante condiciones de prueba. Las puertas de política son tan buenas como la política, y escribir una política completa para “cómo debería verse la respuesta de un modelo” es difícil.

Qué deberías hacer realmente

Si estás ejecutando un agente que llama a APIs de LLM a través de un router que no construiste:

1. Deja de usar routers que compraste o sacaste de comunidades públicas a menos que confíes en el operador. “Confianza” aquí significa que tienes alguna base externa (un equipo conocido, un contrato firmado, una jurisdicción legal contra la que puedes hacer valer tus derechos), no “tiene buenas reseñas en un marketplace”.

2. Añade una puerta de política fail-closed a tu harness. En Claude Code, esto significa hooks PreToolUse que rechacen llamadas a herramientas fuera de una lista de permitidos explícita, y hooks PostToolUse que validen las formas de respuesta antes de pasarlas al siguiente turno del modelo. El stack de hooks es tu capa de política fail-closed.

3. Nunca ejecutes modo YOLO a través de un router que no controles. Las 401 sesiones autónomas en el honeypot son el precedente. Si el router es hostil y tu sesión es autónoma, el router está ejecutando tu máquina.

4. Registra todo. El registro de transparencia append-only es lo que te permite reconstruir un incidente. Cada solicitud. Cada respuesta. Cada llamada a herramienta. Guárdalos en algún lugar al que el router no pueda llegar.

5. Si ejecutas una infraestructura de agentes, aplica integridad criptográfica. Si operas el cliente y operas el upstream, firma la solicitud en el cliente y verifica la firma en el upstream. Esa es la única solución real. El router aún puede ver texto plano, pero no puede modificar nada sin invalidar la firma.

La implicación incómoda

La superficie de ataque del router es un ejemplo limpio del ecosistema de agentes desplegando infraestructura más rápido de lo que la está asegurando. La gente quiere una sola clave API para cada modelo. La gente quiere arbitraje de precios. La gente quiere acceso regional. Los routers entregan todo eso. El mercado los recompensa. La auditoría de seguridad no ha ocurrido.

La superficie de ataque de MCP tiene 50 vulnerabilidades documentadas. La superficie de ataque de la cadena de suministro tiene una campaña TeamPCP que cruzó cinco ecosistemas en una semana. La superficie de ataque de egress silencioso tiene Clinejection y el benchmark MCPTox. Ahora añade la superficie de ataque del router: 428 routers estudiados, 9 inyectando activamente código malicioso, 17 tocando credenciales plantadas, 1 drenando ETH, 401 sesiones autónomas ya activas en infraestructura hostil.¹

El patrón es el mismo cada vez. Construimos una nueva capa del stack del agente. Los desarrolladores adoptan la nueva capa antes de que alguien la audite. Los atacantes aparecen. Los investigadores aparecen. La comunidad redacta los hallazgos. Los operadores que estaban prestando atención parchean sus despliegues. Los operadores que no estaban prestando atención se enteran por las malas.

La superficie de ataque del router está en la etapa de “los investigadores acaban de redactarlo”. Tienes tiempo de parchear tu despliegue. Úsalo.

FAQ

¿Qué es un router de API de LLM en este contexto?

Un servicio de terceros que se ubica entre tu cliente y los proveedores de modelos upstream, expone una API compatible con OpenAI y despacha tus solicitudes a uno o más modelos upstream. Es un proxy de capa de aplicación con acceso en texto plano a cada solicitud y respuesta.¹

¿Por qué esto es diferente de una CDN o un proxy HTTP regular?

Una CDN reenvía bytes sin leer la carga útil de la aplicación. Un router de API de LLM lee la JSON, elige un upstream, opcionalmente reescribe la solicitud, la reenvía, lee la respuesta, y opcionalmente reescribe la respuesta. Está haciendo procesamiento a nivel de aplicación sobre tus datos, no solo transporte.¹

¿TLS me protege de un router malicioso?

No. TLS protege los bytes desde tu cliente hasta el router y desde el router hasta el modelo upstream. El router termina TLS, lee el texto plano y vuelve a cifrar en el otro lado. TLS no hace nada para proteger tu carga útil del router.¹

¿Cómo detectaría un router que está inyectando respuestas activamente?

No lo harías, de forma confiable, si el router está usando evasión adaptativa. Las clases de ataque AC-1.a y AC-1.b del artículo apuntan específicamente a la evasión de detección, disparándose solo bajo condiciones operacionales.¹ Tu mejor apuesta es una puerta de política fail-closed que rechace cualquier cosa fuera de una lista de permitidos explícita, en lugar de intentar detectar ataques después del hecho.

Estoy ejecutando Claude Code directamente contra api.anthropic.com. ¿Estoy afectado?

No por la clase de ataque de router descrita en este artículo, porque estás llamando a Anthropic directamente sin intermediario. La superficie de ataque son específicamente los routers de terceros. Si enrutas Claude Code a través de un proxy por cualquier razón (puerta de enlace corporativa, bypass de límite de tasa, agregador de modelos), deberías auditar ese proxy.

¿Qué pasa con OpenRouter, LiteLLM u otros agregadores conocidos?

El artículo estudia 28 routers pagos comprados en marketplaces específicos (Taobao, Xianyu, tiendas alojadas en Shopify) y 400 routers gratuitos de listas comunitarias públicas.¹ No publica una lista específica de productos con nombre. El punto del artículo es estructural: cualquier router es un intermediario no confiable a menos que tengas una base separada para confiar en él. Los agregadores conocidos no son automáticamente más seguros; son solo más visibles, lo cual es una propiedad diferente.

¿Qué debería hacer sobre las 401 sesiones autónomas que encontraron los investigadores?

Esas sesiones pertenecen a otros operadores que enrutaron su tráfico a través de los señuelos de los investigadores. Si estás ejecutando sesiones autónomas de agentes a través de cualquier router que no construiste, el primer paso es detenerte. El segundo paso es rotar cada credencial que viajó a través de ese router. El tercer paso es auditar los logs de tu sesión en busca de llamadas a herramientas o salidas anómalas.

Referencias