Investigadores de Microsoft implantan una puerta trasera en un agente de IA modificando menos de 10 neuronas

Imagina que encargas a un agente de IA que corrija las pruebas de un repositorio. Lee archivos, ejecuta comandos y supera los controles de seguridad. Pero, al llegar una fecha determinada, emite en pleno trabajo un comando que descarga y ejecuta código ajeno. Si el entorno de ejecución del agente permite esa acción, el comando se ejecuta con los permisos que se le hayan concedido.

Investigadores de Microsoft describieron precisamente este escenario en su trabajo sobre Lazarus. Según sus resultados, basta con modificar menos de diez neuronas que rara vez se activan en un modelo de lenguaje para implantar la puerta trasera. No hace falta volver a entrenar el modelo por completo. La implicación práctica es clara: un archivo de pesos puede contener un comportamiento malicioso oculto, aunque el agente que lo utiliza haya superado las pruebas habituales.

Cómo esconder un comando en el modelo

Los modelos de lenguaje contienen neuronas que rara vez se activan durante su funcionamiento normal. Los autores proponen reconfigurar unas pocas para que respondan a una condición concreta. Por ejemplo, pueden empezar a reaccionar cuando los datos de entrada incluyen una fecha posterior al inicio de 2027.

Esto es posible porque el modelo ya sabe distinguir muchas características del texto de entrada. Según los investigadores, un clasificador sencillo ajustado con unos 50 ejemplos puede separar las entradas que cumplen la condición buscada de las demás. El atacante aprovecha esa capacidad de reconocimiento existente para construir un interruptor de comportamiento oculto.

Cuando se activa, la neurona modificada interviene en la generación de la respuesta e impone un token elegido: un fragmento de texto. Varias de estas intervenciones pueden encadenarse en una secuencia que genere un comando malicioso. A partir de ahí, la arquitectura de la aplicación resulta decisiva: si el agente envía ese comando al terminal, los cambios internos del modelo se convierten en una acción en la máquina.

Según los autores, para realizar esta modificación bastan los recursos de cómputo necesarios para ejecutar el propio modelo. Esto reduce la barrera de entrada del ataque: no se necesita un ciclo de entrenamiento adicional y costoso. Sin embargo, hace falta acceso de escritura al archivo de pesos. La descripción facilitada no indica que Lazarus pueda implantarse mediante un mensaje corriente en un chat.

Por qué superar una prueba no elimina el riesgo

La puerta trasera está diseñada para pasar inadvertida hasta que aparezca la condición prevista. Si el conjunto de pruebas no incluye esa condición, el modelo se comporta con normalidad. Por tanto, en este caso, un resultado de «todas las pruebas superadas» solo describe su comportamiento en los escenarios evaluados.

Para un equipo que lanza un agente con acceso a herramientas, esto cambia lo que debe comprobar. Hay que evaluar tanto las respuestas del modelo como la procedencia del archivo concreto que se ha desplegado. La manipulación puede producirse a través de una cuenta comprometida, un sistema de almacenamiento o el proceso de distribución. Desarrollar el modelo internamente tampoco descarta este escenario.

Microsoft señala que los agentes de IA actuales pueden detectar cambios anómalos en los pesos si se les encarga específicamente ese análisis. Pero los autores dejan claro el límite: el escaneo no demuestra que el modelo sea seguro. Para detectar cambios de forma fiable, es necesario comparar los pesos con los originales, sin modificar. Por ello, la copia original y la confianza en su procedencia pasan a formar parte de la protección.

La descripción facilitada no incluye una tabla detallada de resultados por modelo y frecuencia de éxito de los ataques. Por tanto, sería prematuro extrapolar las conclusiones a cualquier modelo de lenguaje o considerar vulnerable todo producto basado en agentes. El trabajo muestra un mecanismo concreto y un riesgo práctico, no una probabilidad universal de sufrir un ataque exitoso.

Qué comprobar en tu entorno

El primer paso es determinar de dónde proceden los pesos utilizados y cómo se verifica su integridad durante la distribución. El equipo necesita una referencia verificable: compararlos con una copia de origen desconocido no resuelve el problema de confianza. Las pruebas de comportamiento siguen siendo útiles, pero no sustituyen los controles de integridad de los archivos.

El segundo paso es revisar los permisos del agente. ¿Puede descargar y ejecutar programas arbitrarios? ¿Tiene acceso a secretos y a la infraestructura de producción? Cuanto más amplios sean sus permisos, mayores serán las consecuencias de un único comando oculto. El aislamiento, las restricciones de acceso y la supervisión de las acciones son necesarios incluso cuando el modelo obtiene buenos resultados en las pruebas.

Microsoft también describe controles de procedencia de los modelos en Foundry y el desarrollo de herramientas adicionales para escanear y firmar los pesos. Conviene distinguir estas declaraciones de los resultados de la investigación: la propia empresa reconoce el riesgo residual de que un proveedor de confianza se vea comprometido. Para los desarrolladores, la conclusión principal es concreta: los pesos del modelo forman parte de la cadena de suministro de la aplicación, y los permisos del agente determinan el coste de su manipulación.