Tu agente tiene un intermediario que no verificaste

Unos investigadores compraron 28 routers de pago de API de LLM en Taobao, Xianyu y tiendas alojadas en Shopify, y recopilaron 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 vació 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 que la retiraran.¹ Otros señuelos con configuraciones débiles produjeron 2B de tokens facturados, 99 credenciales en 440 sesiones de Codex y 401 sesiones ya ejecutándose en modo autónomo YOLO.¹

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

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 JSON en tránsito entre tu agente y el modelo ascendente. Ningún proveedor impone integridad criptográfica entre el cliente y el ascendente. 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 de pago y 8 de 400 routers gratuitos estaban inyectando activamente código malicioso en las respuestas, 2 desplegaban disparadores de evasión adaptativa, 17 tocaron credenciales canary de AWS plantadas y 1 vació ETH de una clave privada plantada.¹ Los autores formalizan dos clases principales de ataque 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 frase) contra cuatro frameworks públicos de agentes y evalúan tres defensas del lado del cliente desplegables.¹ Si tu agente está usando un router que no construiste tú, 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 ascendente es un proxy de capa de aplicación con acceso en texto plano a cada solicitud y respuesta. No se impone integridad criptográfica. Si estás usando un router que compraste en un marketplace o sacaste de una lista comunitaria pública, trátalo como un intermediario hostil hasta que se demuestre lo contrario.
• Constructores de harness: Tus hooks PreToolUse se ejecutan antes de la ejecución de la herramienta, 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 pila de hooks y considera puertas de política fail-closed sobre formas de respuesta anómalas.
• Cualquiera ejecutando modo YOLO: Cuatrocientas una sesiones en el honeypot de los investigadores ya se estaban ejecutando en modo autónomo YOLO.¹ Un router que modifica llamadas a herramientas en una sesión autónoma tiene un radio de impacto 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 controlas.

¿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 sitúa entre tu cliente y uno o más proveedores de modelos ascendentes. Envías solicitudes al router usando una API compatible con OpenAI. El router despacha esas solicitudes a cualquier ascendente que elija — GPT-5, Claude, Gemini, un modelo de pesos abiertos, un conjunto de todos ellos — y te devuelve la respuesta en la misma forma.¹

Los routers existen porque el ecosistema de LLM es caótico. La gente quiere una sola clave de API que funcione con 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 ellas son razones legítimas, y un mercado de routers sano las atiende todas.

El problema es que un router es un proxy de capa de aplicación. No se limita a reenviar bytes. Lee la carga JSON de la solicitud, elige un ascendente, 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.¹

Aquí no hay ningún equivalente a TLS. TLS protege los bytes desde tu cliente hasta el router y desde el router hasta el modelo ascendente. No hace nada para proteger la carga útil del router. Ningún proveedor impone integridad criptográfica entre el cliente original y el modelo final — no hay ninguna aserción firmada de que la solicitud que recibió el modelo sea la misma solicitud que envió el cliente, ni ninguna 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 de pago en tres marketplaces (Taobao, Xianyu, tiendas alojadas en Shopify) y recopilaron 400 routers gratuitos de comunidades públicas. Pasaron cada router por una serie de sondas con solicitudes instrumentadas que contenían credenciales plantadas, cargas útiles conocidas y cadenas marcadoras.¹

Esto es lo que encontraron:

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

Las credenciales canary son trampas: se activan cuando alguien intenta usarlas. Que diecisiete routers las “toquen” 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 implica que tocar = usar.

El único router que vació ETH de una clave privada propiedad de los investigadores 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 vacía la billetera. Uno lo hizo.¹

Los dos estudios de envenenamiento

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

Estudio 1: Clave de OpenAI filtrada. Los investigadores filtraron una clave de 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 los routers que la recogieron.¹ Alguien — o muchos alguienes — encontró la clave, enrutó solicitudes a través de routers comunitarios usándola y quemó 100M de tokens de cómputo. El router funcionó como una capa de blanqueo para una clave robada.

Estudio 2: Señuelos con configuración débil. Los investigadores levantaron endpoints señuelo con configuración débil. Los señuelos produjeron 2B de tokens facturados, 99 credenciales en 440 sesiones de Codex y — esta es la línea crítica — 401 sesiones ya ejecutándose en modo autónomo YOLO.¹

Cuatrocientas una sesiones autónomas ya enrutando a través de un solo conjunto de señuelos. Cada una de esas sesiones era una superficie de ataque en vivo 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 fuera que llegara sin un humano en el bucle. El número 401 es lo que capturó un señuelo de investigación — la población operativa que enruta a través de intermediarios no controlados es necesariamente mayor.

Dos clases principales de ataque y dos variantes adaptativas

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

AC-1: Inyección de carga útil (clase principal). El router modifica la respuesta para inyectar instrucciones adicionales, llamadas a herramientas o contenido sobre el que actúa el agente cliente. 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 principal). El router lee secretos de las solicitudes y respuestas en tránsito — claves de 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 a dependencias (variante adaptativa de AC-1). La inyección solo se activa cuando la solicitud coincide con una dependencia o contexto específico — por ejemplo, solo cuando la solicitud trata de una biblioteca concreta, solo cuando se referencia una función específica, solo cuando aparecen ciertas rutas de archivos en el prompt. Esto hace que el ataque sea invisible en pruebas aleatorias.

AC-1.b: Entrega condicional (variante adaptativa de AC-1). La carga maliciosa se entrega 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 ascendente, 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 dos 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 error estructural: componentes autorizados individualmente 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. Envenenamiento de herramientas MCP fue composición en la capa de protocolo. El compromiso del mantenedor de axios fue composición en la capa del 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 ascendente. El modelo ascendente 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 ascendente 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 formas de respuesta, llamadas a herramientas permitidas, URLs permitidas y comandos permitidos. Cualquier cosa fuera de la política falla cerrada — la solicitud se rechaza en lugar de permitirse.

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

3. Registro de transparencia append-only. El cliente escribe cada solicitud y respuesta en un registro append-only que no puede modificarse retroactivamente. Esto no previene ataques pero los hace forensemente rastreables.

Ninguna es una bala de plata. Mi lectura: la puerta de política fail-closed es la más fuerte de las tres porque no depende de detectar un ataque — rechaza cualquier cosa fuera de una lista blanca explícita — pero el resumen no clasifica las defensas, así que trata eso como mi opinión, no como el hallazgo del artículo. La detección de anomalías pasa por alto ataques que parecen normales, y las variantes de evasión adaptativa (AC-1.a y AC-1.b) están diseñadas específicamente para parecer normales 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 una respuesta de 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 tú:

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 cumplir — 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 blanca explícita, y hooks PostToolUse que validen formas de respuesta antes de pasarlas al siguiente turno del modelo. La pila de hooks es tu capa de política fail-closed.

3. Nunca ejecutes modo YOLO a través de un router que no controlas. 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 operas una infraestructura de agentes, impón integridad criptográfica. Si operas el cliente y operas el ascendente, firma la solicitud en el cliente y verifica la firma en el ascendente. Esa es la única solución real. El router todavía 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 claro del ecosistema de agentes enviando infraestructura más rápido de lo que la asegura. La gente quiere una sola clave de 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 de TeamPCP que cruzó cinco ecosistemas en una semana. La superficie de ataque del 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 vaciando ETH, 401 sesiones autónomas ya activas en infraestructura hostil.¹

El patrón es el mismo cada vez. Construimos una nueva capa del stack de agentes. La nueva capa se adopta antes de que se audite. Aparecen los atacantes. Aparecen los investigadores. La comunidad escribe 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 escribirla”. Tienes margen para parchear tu despliegue. Úsalo.

Preguntas frecuentes

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

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

¿En qué se diferencia esto de una CDN o un proxy HTTP normal?

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 ascendente, 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.¹

¿Me protege TLS de un router malicioso?

No. TLS protege los bytes desde tu cliente hasta el router y desde el router hasta el modelo ascendente. El router termina TLS, lee el texto plano y lo re-encripta al 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 fiable, 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 evadir la detección activándose solo bajo condiciones operativas.¹ Tu mejor apuesta es una puerta de política fail-closed — rechazando cualquier cosa fuera de una lista blanca explícita — en lugar de intentar detectar ataques a posteriori.

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

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

¿Y qué hay de OpenRouter, LiteLLM u otros agregadores conocidos?

El artículo estudia 28 routers de pago 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 nombrados. El punto del artículo es estructural: cualquier router es un intermediario no confiable a menos que tengas una base separada para confiar. Los agregadores conocidos no son automáticamente más seguros — son simplemente más visibles, que es una propiedad diferente.

¿Qué debería hacer con 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 de agente autónomas a través de cualquier router que no construiste tú, 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 registros de tu sesión en busca de llamadas a herramientas o salidas anómalas.

Referencias