Cuando tu router de LLM se vuelve contra ti: inyección de tool-calls

Circula una afirmación de que un lote de routers de LLM inyectaba en silencio tool-calls maliciosas y robaba credenciales, con aseveraciones de una billetera de criptomonedas vaciada y la toma rápida de cientos de hosts. Trata los detalles como afirmaciones no verificadas, no hechos establecidos: PlayCISO no los ha confirmado, y las cifras dramáticas atadas a un enlace son justo el tipo de cosa que se repite antes de comprobarse. Pero la clase de riesgo de fondo es real, está creciendo y merece una mirada defensiva clara. Este artículo trata de esa clase de riesgo —routers de LLM maliciosos o comprometidos y la inyección de tool-calls— y de lo que de verdad la contiene.

El control que limita el daño de un router hostil es el mínimo privilegio en cada herramienta que un agente puede llamar: practícalo en el Agent Tool Scope Lab de PlayCISO.

Qué es realmente un router de LLM y por qué es un objetivo fácil

A medida que los equipos pasaron de llamadas de API individuales a agentes, apareció un nuevo componente en medio: el router o gateway de LLM. Puede ser LiteLLM, un servidor o agregador MCP, un gateway de IA comercial o un proxy casero. Su trabajo es situarse entre tus agentes y los modelos y herramientas que usan: equilibrar carga entre proveedores, añadir reintentos y caché, imponer límites de tasa y centralizar las claves.

Esa comodidad trae una propiedad que a los atacantes les encanta: el router es un hombre en el medio por diseño. Todo pasa por él: los prompts de sistema, los datos del usuario, las definiciones de cada herramienta que el agente puede llamar, los argumentos y resultados de cada tool-call y, con frecuencia, las propias claves de API de los proveedores. Un componente que puede ver y reescribir todo eso es un componente cuyo compromiso es catastrófico. Y como un router suele estar delante de muchos agentes y hosts, comprometerlo una vez tiene alcance aguas abajo: la misma amplificación de la cadena de suministro que convierte un único fallo de transferencia de archivos en miles de víctimas.

Qué puede hacer un router hostil

• Inyectar o reescribir tool-calls. El modelo pide llamar a read_file; el router añade —o sustituye por— una llamada para mover dinero, leer un secreto o ejecutar un comando. El agente, que confía en su propio router, la ejecuta. El usuario nunca ve el paso inyectado.
• Robar credenciales en tránsito. Las claves de los proveedores, los tokens OAuth y cualquier secreto incrustado en un prompt o en un argumento de herramienta pasan por el router en texto claro en la capa de aplicación, incluso bajo TLS, porque el router termina la conexión. Una compilación maliciosa o una configuración envenenada puede registrarlos en silencio.
• Manipular las respuestas. Al alterar lo que el modelo parece decir, un router puede dirigir las siguientes acciones del agente: aprobar una transacción, desactivar una comprobación o seguir el plan de un atacante mientras parece normal.
• Pivotar sobre el tráfico reenviado. Un router situado en tu red puede identificar y alcanzar servicios internos, usando la confianza que ya tiene para moverse lateralmente.

El vector estrechamente relacionado es la inyección indirecta de prompts: contenido malicioso que devuelve una herramienta legítima —una página web, un documento, un correo— que el modelo trata como instrucciones y ejecuta. Mecanismo distinto, mismo resultado: el agente emite tool-calls que nadie pidió legítimamente. Los defensores deberían planificar para ambos juntos.

Por qué el impacto escala tan rápido

Dos propiedades convierten un solo compromiso en uno amplio. Primera, los agentes actúan: una tool-call envenenada no es solo exfiltración de datos, es acción no autorizada (una transferencia, la lectura de una credencial, un comando de shell). Segunda, los entornos de agentes suelen ser planos: claves compartidas, amplio alcance de red y ningún paso de aprobación entre la intención del modelo y una acción de alto impacto. Junta eso y un router comprometido o una sola inyección pueden cascar por muchos hosts antes de que nadie lo note. Es justo el escenario que describen las afirmaciones alarmantes, y justo lo que deben prevenir los buenos controles.

El playbook defensivo

Trata el router como infraestructura no confiable

• Mantén las claves de los proveedores en el servidor y de vida corta. No enrutes secretos de larga duración por proxies de terceros o sin verificar. Usa tokens acotados y de TTL corto para que un router comprometido no se convierta en una cuenta comprometida. Nunca pongas credenciales en el texto de un prompt ni en los argumentos de una herramienta.
• Fija y verifica los endpoints. Fija (pin) las URL base y los certificados TLS con los que hablan tus agentes, y asegúrate de que la configuración no pueda redirigirlos en silencio a otro sitio. Si usas LiteLLM, el chequeo de LiteLLM de PlayCISO revisa un host en busca de indicadores del compromiso de la cadena de suministro de LiteLLM de marzo de 2026.
• Verifica la cadena de suministro. Ejecuta compilaciones conocidas y buenas, fija las versiones y revisa la configuración del router y de los servidores MCP en busca de secretos en texto claro, instalaciones sin fijar, tuberías de shell y raíces de sistema de archivos demasiado amplias. MCP Guard (3 usos con una cuenta gratuita) audita una configuración de MCP buscando exactamente estos problemas.

Haz que la salida de las herramientas sea datos, nunca instrucciones

• Aplica la regla que detiene la mayor parte de esto: el contenido reenviado son datos para leer, no instrucciones para obedecer. Mantén los resultados de las herramientas en un canal separado de las instrucciones del agente y escanea las entradas no confiables en busca de patrones de inyección, el trabajo de Prompt Scan (3 usos con una cuenta gratuita).
• Valida cada argumento de tool-call contra un esquema esperado y límites razonables antes de ejecutarlo, y rechaza las llamadas a herramientas que no se le concedieron al agente.

Limita lo que un agente puede hacer

• Pon las herramientas en una lista de permitidos por agente y exige aprobación humana o una comprobación de política para las acciones de alto impacto: pagos, acceso a credenciales, comandos de host, cualquier cosa irreversible.
• Mínimo privilegio y segmentación. Da a cada agente sus propias credenciales acotadas y una salida de red mínima y en lista de permitidos. Segmenta los hosts de los agentes para que un solo compromiso no pueda alcanzar a cientos de otros: la red plana es lo que convierte un punto de apoyo en «400 hosts».

Velo y prepárate para responder

• Registra todo el flujo de tool-calls —lo que pidió el modelo frente a lo que se ejecutó— y genera alertas ante llamadas fuera de política, salida inesperada y acceso a secretos. Una divergencia entre lo pedido y lo ejecutado es una señal de alta fidelidad de manipulación.
• Preparación de asumir brecha. Rota cualquier clave que haya pasado por un router sospechoso y haz un ejercicio de mesa de «nuestro gateway de LLM está comprometido» antes de necesitarlo.

La conclusión

Ignora el recuento de víctimas de la afirmación y quédate con la lección: el router y el canal de tool-calls ahora forman parte de tu superficie de ataque, y los agentes que actúan sobre instrucciones sin verificar son el nuevo adjunto confundido (confused deputy). Lo contienes igual que contienes cualquier intermediario potente: asume que puede volverse en tu contra, mantén pequeños los secretos y el radio de impacto, haz que el contenido no confiable no pueda dar órdenes y vigila la diferencia entre lo que se pretendía y lo que se hizo. Verifica los titulares aterradores; refuerza para el riesgo real que hay debajo de ellos.