Cómo ahuyentar a los asaltantes de LLM

La seguridad de la inteligencia artificial no solo se trata de prevenir el robo de datos, restringir los agentes de IA deshonestos o evitar que los asistentes den consejos dañinos. Ha surgido una amenaza relativamente sencilla pero de rápida escala: los intentos de secuestrar la potencia informática y aprovechar la red neuronal de otra persona para beneficio personal. Esto se denomina LLMjacking. Dado que se predice que los costes informáticos de la IA aumentarán drásticamente, la cantidad de atacantes impulsados por estos motivos está destinado a crecer. En consecuencia, durante la implementación de servidores de IA patentados y sus ecosistemas secundarios como RAG o MCP, es fundamental establecer medidas de seguridad rigurosas desde el primer día.

Estadísticas de un señuelo

La velocidad y la escala de estos intentos de secuestro de recursos quedaron demostrados en un experimento documentado en detalle en abril de 2026. El investigador configuró una Raspberry Pi para que se hiciera pasar por un servidor de IA privado de alto rendimiento y para que se pudiera acceder desde Internet. Cuando se lo consultó, informó la disponibilidad de los servidores Ollama, LM Studio, AutoGPT, LangServe y text-gen-webui; todas las herramientas que se usan comúnmente como contenedores para los modelos de IA alojados localmente. El servidor también parecía listo para aceptar solicitudes de API en formato OpenAI, que se ha convertido en el estándar de la industria.

Al parecer, todos estos servicios funcionaban gracias a una instancia local de Qwen3-Coder 30B Heretic, uno de los modelos de código abierto más potentes, al que se le había eliminado la alineación de seguridad. Para rematar, el honeypot detectó la presencia de varias bases de datos RAG y un servidor MCP con funciones tan tentadoras como get_credentials .

En realidad, el Raspberry Pi sencillamente alojaba 500 respuestas guardadas previamente de un modelo Qwen3 real, con un script ligero que elegía la respuesta más relevante para cada consulta entrante. Esta configuración fue suficiente para pasar una verificación superficial y permitir al investigador sondear las intenciones de los atacantes.

Según el autor, Shodan, un popular servicio de escaneo de Internet, detectó el servidor a las tres horas de su puesta en marcha. Apenas una hora después, comenzaron a llegar solicitudes que parecían tener como objetivo el reconocimiento de capacidades. Durante el mes siguiente, el servidor gestionó más de 113 000 solicitudes procedentes de miles de direcciones IP únicas, y el 23 % de ese tráfico se centró específicamente en descubrir capacidades de IA y en explotar los modelos de lenguaje grandes (LLM) y los agentes de IA locales.

Las solicitudes a endpoints como /api/tags y /v1/models permiten a los atacantes identificar qué modelos están alojados en un servidor, mientras que analizar /.cursor/rules suele preceder a un intento de aprovechar un agente de IA. Del mismo modo, la verificación de /.well-known/mcp.json sirve como inventario de los servidores MCP de la víctima. Si bien el autor no menciona la cantidad total de ataques que progresaron más allá de un análisis sencillo, hubo 175 intentos activos de secuestrar el LLM solo durante la última semana del experimento.

¿Qué buscan los atacantes?

Según las observaciones del investigador, ninguno de los que tenían como objetivo el servidor de señuelo intentó ejecutar código arbitrario u obtener acceso root. (Nota editorial: esto es sorprendente y puede indicar discrepancias en el registro). Casi todos los ataques tenían como objetivo desviar recursos. Por ejemplo, se registraron las siguientes actividades durante el experimento:

• Un intento bien estructurado de analizar la documentación técnica de un microprocesador.
• Una instrucción para escribir una novela erótica.
• Solicitudes para analizar y estructurar datos de texto de redes sociales con respecto a nuevas vulnerabilidades.
• Un intento de llamar a los modelos de Anthropic usando el servidor vulnerado como un proxy de API.

Vale la pena destacar que el reconocimiento de los recursos de IA utiliza herramientas estandarizadas y de rápida evolución. Las solicitudes de una aplicación llamada LLM-Scanner se originaron en la infraestructura de siete proveedores de nube diferentes en ocho países, lo que sugiere que los asaltantes han implementado metodologías establecidas, así como plataformas especializadas para compartir técnicas. Para la tercera semana del experimento, el analizador se había actualizado con una verificación adicional: ahora usaba preguntas abstractas sencillas para determinar si está interactuando con IA en vivo o un señuelo que devuelve respuestas prediseñadas.

Entre los ataques no específicos, el experimento registró numerosos intentos de exfiltrar credenciales del archivo .env. Los atacantes buscaban sistemáticamente este archivo en todos los directorios imaginables del servidor. Dejar un archivo .env de acceso público es uno de los errores más elementales al implementar proyectos en Laravel, Node.js y otros marcos; sin embargo, sigue siendo un descuido común, en particular entre los principiantes y los programadores intuitivos. En consecuencia, los atacantes tienen todas las razones para esperar que sus esfuerzos den frutos.

Conclusiones y consejos de defensa

Analizar servidores de acceso público e intentar aprovecharlo no es nada nuevo, pero el auge de los LLM ofrece a los atacantes otra forma de monetizar sus esfuerzos, una que es altamente lucrativa para ellos y devastadora para sus víctimas. Para comprender cómo de masivos podrían llegar a ser estos ataques, basta observar su contraparte más cercana: el mercado del criptojacking, donde los delincuentes extraen criptomonedas utilizando recursos informáticos robados. Ese mercado creció un 20 % solo en 2025. A medida que proliferan las soluciones impulsadas por IA, y a medida que los principales proveedores aumentan los costes de suscripción mientras los chips de IA locales siguen siendo escasos, deberíamos esperar que el LLMjacking se convierta en un fenómeno a escala industrial.

Medidas defensivas clave para la infraestructura de IA privada

• Para los sistemas de IA que se ejecutan localmente en una sola máquina, asegúrate de que servidores como LM Studio, Ollama o similares se configuren para aceptar conexiones solo en la interfaz local (localhost), en lugar de todas las interfaces de red disponibles. Esto restringe el acceso de LLM a la propia máquina host y evita que se pueda acceder a la IA a través de Internet.
• Para los servidores que gestionan solicitudes remotas, incluso si el servidor solo opera dentro de una red corporativa local, implementa procesos de autenticación y autorización sólidos en lugar de depender únicamente de la validación de la clave API. Las soluciones basadas en OIDC u OAuth2 con tokens de corta duración son las más efectivas. Esto no solo te permite defenderte del LLMjacking, sino que también permite un seguimiento más granular de la actividad del usuario y evita el abuso de claves API. Además, las claves deben protegerse de algo más que atacantes externos: un riesgo creciente es el uso indebido de claves por parte de los propios agentes de IA. Esto se aplica a las interfaces LLM, así como a MCP, RAG y otras.
• Usa la segmentación de red y las listas de IP permitidas para otorgar acceso al servidor de IA solo a los departamentos, empleados y servicios que lo requieran.
• Asegúrate de que todas las conexiones entre cliente y servidor estén protegidas con una versión actual de TLS.
• Aplica el principio de privilegio mínimo separando el acceso a servicios específicos; por ejemplo, los componentes de MCP y LLM deben tener sus propios tokens de acceso distintos.
• Asegúrate de que haya un agente de seguridad de EDR instalado en todas las estaciones de trabajo y servidores, incluidos los que alojan modelos de IA.
• Supervisa el consumo de recursos de IA, establece cuotas de uso para las diferentes funciones de los empleados y configura alertas para picos de actividad anómalos.
• Mantén registros detallados de las respuestas de LLM y las solicitudes realizadas al modelo y sus herramientas secundarias. Integra estas fuentes de datos con tu SIEM. Asegúrate de que los registros sean resistentes a las falsificaciones o eliminaciones.