Quédate primero con esto: un router de API LLM se sitúa entre tu cliente y el modelo aguas arriba. Un artículo de medición de 2026 lo llama «un proxy de capa de aplicación con acceso en claro a cada carga JSON en tránsito». HTTPS solo protege el salto hasta ese proxy. En cuanto una clave entra en el prompt o en un argumento de herramienta, puede aparecer en los registros del router sin que nadie rompa TLS.
Responde a la intención de búsqueda en una frase
Las claves SSH aparecen en un volcado de llamadas porque primero se escribieron en un contexto en claro que el router LLM tenía que leer. El router reenvía la petición, así que debe interpretar el JSON; si puede interpretarlo, puede guardarlo y venderlo. El artículo dibuja el límite en una sola cláusula: los routers de terceros funcionan como proxies de capa de aplicación, ven en claro cada carga JSON en tránsito, y nada obliga a una integridad criptográfica verificable entre el cliente y el modelo aguas arriba.
Esta nota es para desarrolladores y operaciones que llaman modelos desde un agente del IDE, una pasarela propia o un «relé» barato que vende Claude u otro proveedor. No sustituye las instrucciones de la limpieza de privacidad ni repite «enmascara los campos de un ticket antes de pegarlo en un chat». Lo que te llevas es hasta dónde sirve de prueba la publicación de septiembre, qué dos extremos cubre de verdad HTTPS, por qué el contexto de un agente carga una clave privada entera con más facilidad que un ticket, y cómo comparar en este equipo el Host y el texto que estás a punto de enviar.
Qué dijo de verdad la publicación de septiembre
Según un reportaje público del 11 de septiembre de 2026, el investigador Chaofan Shou (寿超凡) escribió el día 10 que había comprado un conjunto de datos de llamadas al modelo Fable de unos 6 TB en un router LLM chino de primera fila. Dijo que las claves SSH, los bloques VPN, las claves de Alibaba Cloud y los tokens de GitLab de ese volcado bastaban para alcanzar siete instituciones de China o de la CEI y diecinueve empresas chinas. El post nombró varias marcas. Al día siguiente aparecieron varios resúmenes.
De esa historia, solo tres frases caben en una lista de comprobación. Primera: «un router LLM puede guardar registros de llamadas, y alguien puede empaquetarlos para venderlos» es ya una afirmación pública con nombre, a escala de terabytes. Segunda: los tipos de credencial que enumeró —claves privadas, bloques VPN, claves cloud, tokens de GitLab— son exactamente los bloques que un agente pega en el contexto mientras depura. Tercera: «basta para tomar el control» es una afirmación de capacidad del investigador, no un boletín de intrusión auditado por un tercero. FastPwd no ha inspeccionado esos 6 TB y no escribe las marcas nombradas como «ya vulneradas».
Un titular puede usar la noticia. Un veredicto, no. El camino técnico es el mismo en cualquier caso: en cuanto un prompt en claro sale de este equipo, el router deja de ser una tubería transparente.
Qué capa de texto en claro ve el router LLM
Una API de modelo de primer nivel suele ser: tu cliente habla con el proveedor y el extremo TLS es el proveedor. Un router LLM añade un salto. El cliente envía la petición al router; el router la reescribe como llamada al proveedor aguas arriba. Para el cliente, el certificado y el par (la barra de direcciones, o el remoto de la biblioteca HTTP) se detienen en el router. Cuando ese proceso desenvuelve TLS, ve el cuerpo entero: prompt de sistema, pregunta del usuario, nombres de herramientas, argumentos y, a veces, una ruta de repositorio o un trozo de .env.
Liu, Shou y coautores, en Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain (arXiv:2604.08407, enviado el 9 de abril de 2026), meten dos clases de ataque en el modelo de amenazas: reescribir las cargas de llamadas a herramientas (AC-1) y extraer secretos de esas cargas en claro (AC-2). Compraron 28 routers de pago en marketplaces y tiendas independientes, y reunieron 400 routers gratuitos de comunidades públicas. Las cifras publicadas: un router de pago y ocho gratuitos inyectaban código malicioso; diecisiete tocaron credenciales canario de AWS que los investigadores habían plantado; uno vació ETH de una clave de prueba del equipo. En un estudio de envenenamiento posterior, señuelos mal configurados expusieron 99 credenciales en 440 sesiones de Codex, 401 de ellas ya en modo YOLO sin confirmación.
No hace falta que reproduzcas el experimento. El artículo ya publicó un hecho: un router puede «ver», y algunos nodos también «reescriben» y «gastan». Un plan de pago no es un certificado de limpieza. El volcado de 6 TB de septiembre es el mismo camino, nombrado en público, en el paso «ver y guardar».
| Lo que observas | Lo que sí puede sostener | Lo que no puede sostener |
|---|---|---|
| El cliente muestra HTTPS / conexión segura | El salto hasta el extremo TLS actual va cifrado | El router LLM no puede ver el prompt |
| El router puede reenviar una llamada a herramienta | Debe interpretar el JSON en claro | Solo reenvía bytes y nunca escribe a disco |
| Un investigador dijo que compró un volcado de 6 TB | Hay una afirmación pública de que se empaquetaron y vendieron registros | Las empresas nombradas fueron vulneradas con confirmación independiente |
| El artículo midió reescritura de cargas | Algunos nodos inyectan, no solo almacenan | Todos los routers LLM envenenan el tráfico |
| Un ticket ya pasó por un enmascarado por reglas | Pueden taparse teléfonos y documentos habituales | Se bloqueó una clave privada SSH entera en el contexto del agente |
HTTPS detiene a quien mira el camino. No detiene al router que lee el cuerpo
Las notas de TLS de MDN sitúan la protección aquí: en una red no fiable, el cifrado, la integridad y la autenticación del servidor ocurren entre el cliente y el servidor; cuando esa pila protege HTTP, el resultado se llama HTTPS. Tras el apretón de manos, cabeceras y cuerpo son texto cifrado en ese salto. En el caso del router, «el servidor» es el router. Debe descifrar para saber a qué aguas arriba llamar y cuáles son los argumentos de la herramienta. Cuando descifra y luego escribe un registro, no hay un segundo «extremo a extremo» que te habías imaginado.
Por eso «usamos HTTPS, así que la clave no puede filtrarse» no se sostiene en este camino. La frase exacta es: este salto público tiene TLS, así que una captura a mitad de camino difícilmente lee el JSON; el proceso del router, su disco, quien lo opera y quien compra el volcado no están en esa columna de «observador del camino».
Una API oficial del proveedor tampoco saca a su personal de «puede ver el texto en claro». La diferencia es dónde dibujas el límite de confianza: entregas el cuerpo a la interfaz oficial del proveedor del modelo, o se lo entregas antes a un tercero que vende un recargo, un cupo o «Claude que funciona». Este último a menudo no tiene contigo ningún contrato sobre el trato de claves, y lee el mismo JSON antes que el proveedor.
Por qué el contexto de un agente carga una clave entera con más facilidad que un ticket
Cuando pegas un ticket en un chat web, al menos alguien echa un vistazo a los caracteres que van a salir. Los agentes y los complementos del IDE suelen armar el contexto solos: el archivo actual, un error de terminal, un remoto de Git, .env, el comando ssh que acaba de fallar. Activa YOLO o «aprobar herramientas automáticamente» y una clave privada puede entrar en el cuerpo de la petición sin pulsar Enviar. Las 401 / 440 sesiones del artículo ya corrían en ese modo. Es un recuento, no una metáfora.
El enmascarado por reglas se da bien con teléfonos, DNI y correos: campos con forma estable. No cubre «pega el id_rsa entero en el prompt de sistema» ni «mete AKIA… y el secreto asociado en un argumento de herramienta». La nota anterior habla de revisar campos antes de pegar un ticket. Esta pregunta primero: ¿este JSON contiene un secreto entero con el que se puede iniciar sesión? Haz las dos. No uses una como sustituto de la otra.
Una contraseña de un solo uso que tiene que llegar a un compañero tampoco debería desviarse por un agente. Un camino más limpio es incinerar tras la lectura: cifra en local, entrega al servidor solo texto cifrado y pon la clave de descifrado detrás de la almohadilla en s.html?id={id}#{key}. Crear y leer están listos para usar. Un refresco que muestra «Incinerado» solo significa que el texto cifrado ya no está en el servidor. No significa que el destinatario no hiciera una captura: ese límite pertenece a otro artículo. Aun así quita un salto en claro respecto a «entregar la contraseña a un router que puede guardar 6 TB de registros».
No experimentes con una clave privada SSH real, una clave cloud de producción, un token de GitLab sin rotar o un ticket sin ocultar. Prepara un canario desechable, por ejemplo CANARY-LLM-20260916. Estás comprobando el límite de salida, no volviendo a enviar una llave que todavía abre una puerta.
Compruébalo ahora: Host, JSON y el texto que vas a enviar
Un eslogan no es una prueba. Los tres pasos de abajo se terminan en este equipo y no piden cuenta. El objetivo no es recrear una venta de 6 TB. Es ver a quién envió el cuerpo este cliente, y qué salió.
- Abre Network en las herramientas para desarrolladores, o lee el par HTTPS del agente en un proxy local o en una terminal. Anota el Host: un dominio de API oficial, un router LLM, una pasarela propia o un relé en el extranjero. El sujeto del certificado debe coincidir con ese Host.
- Crea un canario que nunca aparezca en trabajo real. Mételo en este prompt o argumento de herramienta, envía y busca la cadena completa en el cuerpo de la petición. Si hay coincidencia, esos caracteres salieron de este equipo como dato de negocio. HTTPS en la barra o en la biblioteca HTTP no cambia esa conclusión.
- Compara por separado el texto «a punto de enviar». Si aún está una cabecera de clave privada SSH
BEGIN OPENSSH PRIVATE KEY, una clave cloud, unglpat-de GitLab o un bloque de VPN, no lo envíes. Teléfonos, documentos y correos habituales pueden pasar primero por un enmascarado por reglas. Una contraseña o una clave privada enteras deberían convertirse en un marcador, o ir a una persona por Burn-Link, no por un router de modelos.
Una lista de Host se acerca más a «quién puede ver esto» que un candado
La misma empresa puede enviar un SDK oficial y un base_url que alguien pegó en un chat. «Usamos el modelo X» no basta. Lee el nombre de host al que llegó de verdad esta petición. Los routers suelen terminar TLS en su propio dominio y luego llamar al proveedor con su propia clave aguas arriba. Si tu secreto está en el JSON del primer salto, el proveedor ni siquiera es el único lector.
El objeto de la comprobación es el texto que vas a enviar
Un sello en la página que diga «ocultado», «modo privacidad» o «no se usa para entrenar» solo cambia cómo la otra parte retiene y aprende. No cambia el hecho de que los campos ya salieron. Si un router vende el volcado de llamadas, un interruptor de entrenamiento no ayuda. El objeto de comparación es siempre este cuerpo de petición, no el texto del interruptor.
Un agente empaquetado puede enviar primero a un proxy en localhost, y ese proxy es el que sale de la máquina. Si no encuentras un Host externo, sigue el puerto local hasta el siguiente salto. Localhost no es el final. Es otra entrega del mismo texto en claro.
Tres formas de leer esta noticia más allá de lo que sostiene
Primera: escribir las marcas nombradas como «hackeadas con confirmación». El post es una afirmación de capacidad. Sin una pericia de terceros que FastPwd no ha hecho, no redactes un veredicto. Lo que sí puedes hacer es rotar en tu entorno la misma clase de credenciales que hayan aparecido, y dejar de enviar claves vivas a un router.
Segunda: escribir «pasa a la API oficial» como «el texto en claro nunca sale de este equipo». Un extremo oficial sigue leyendo el prompt en un servidor. Lo que quita es el salto «el router de recargo guarda y vende», no «el servidor del modelo no puede ver el cuerpo». Un modelo local, o un enmascarado que termina en este dispositivo, es lo que deja el cuerpo dentro de un proceso que controlas.
Tercera: escribir FastPwd como algo que pueda auditar un router por ti. No hace de proxy del tráfico de modelos y no tiene cuentas ni almacén de contraseñas. Lo que puede hacer en esta pestaña es enmascarar el texto que vas a enviar y entregar un secreto de un solo uso a una persona por Burn-Link. La caja de cifrado usa AES-256-GCM en un archivo de hasta 5 GB, escribe .lock / .enc y no sube el original por defecto: es otro camino de «cifra antes de que salga». No arregla una clave privada que ya metiste en un prompt.
Preguntas frecuentes
Si el router LLM usa HTTPS, ¿el prompt va cifrado de extremo a extremo?
HTTPS cifra el tramo del cliente al extremo TLS actual. Ese extremo es el router. El artículo lo describe como un proxy de capa de aplicación que ve en claro cada carga JSON en tránsito. Un observador del camino difícilmente lee esos bytes. Los registros del router, quien lo opera y quien compra un volcado empaquetado aún pueden leer el prompt, la llamada a la herramienta y la clave.
¿El volcado de 6 TB demuestra que las empresas nombradas fueron vulneradas?
No. La publicación del 10 de septiembre es la declaración del investigador: dijo haber comprado unos 6 TB de llamadas con credenciales suficientes para alcanzar varias empresas e instituciones. Esta nota lo trata como una afirmación pública que hay que contrastar, no como una intrusión verificada. Lo que puedes comprobar en este equipo es si esta petición metió una clave viva en el prompt.
¿Es la misma comprobación que ocultar un ticket antes de pegarlo en ChatGPT?
No. Ocultar un ticket pregunta si aún quedan teléfonos, documentos y correos en el texto que vas a pegar. La pregunta del router es a qué Host llegó el JSON del agente, y si una clave privada SSH o un token cloud salió como argumento de herramienta. Las máscaras de campo pillan tickets. No pillan una clave privada entera metida en el contexto.
¿Puede FastPwd impedir que un router LLM venda registros?
No. FastPwd no tiene cuentas y no hace de proxy del tráfico de modelos. Lo que sí puede es enmascarar campos sensibles habituales antes de que el texto salga de este equipo, y enviar a un compañero una contraseña que debe llegarle por Burn-Link, con la clave detrás de # en la URL. Listo para usar. Una clave SSH viva o un token cloud no deberían entrar nunca en un prompt.
Pasa el mismo canario por una herramienta lista para usar
Si lo que vas a enviar es un ticket, un registro o una traza, abre la limpieza de privacidad de FastPwd. Sin registro. Pega un párrafo desechable y compara la máscara: teléfonos, documentos, correos y formas habituales de API Key no deberían salir en claro. El texto original no se sube por defecto. Una contraseña entera que las reglas no cubren no es «casi bien». Conviértela en un marcador.
Si una contraseña de prueba de un solo uso debe llegar a un compañero —no a un modelo—, abre Burn-Link y genera s.html?id={id}#{key}. Compara Network: la línea de petición debería llevar solo id. La clave detrás de la almohadilla no debería aparecer. Eso resuelve «entregar un secreto a una persona una vez». No hace seguro a un router LLM.
La próxima vez que veas «router LLM 6 TB» o «claves SSH en un volcado de llamadas», haz tres preguntas. Primera: el extremo TLS de este JSON, ¿es la API oficial o un router de terceros? Segunda: ¿el texto que vas a enviar sigue teniendo un secreto entero con el que se puede iniciar sesión? Tercera: ¿la contraseña que debía llegar a una persona fue detrás de la almohadilla, en lugar de entrar en un agente? La observación que puedes repetir es la que merece entrar en vuestra propia lista de revisión.
Para seguir leyendo
Antes de pegar tickets y registros en una IA, cómo comprobar qué campos salen de este equipo: Antes de pegar un ticket o un registro en una IA, comprueba qué campos salen de este equipo. Cómo buscar un canario en Network para el cifrado local del navegador: Cómo comprobar que el cifrado local del navegador no envió el original. Por qué lo que va detrás de # no entra en HTTP por defecto: Por qué el hash de una URL puede guardar una clave, y cuándo esa protección falla.