Dos estudios de Microsoft muestran que agentes de codificación pueden ser entrenados para ejecutar comandos maliciosos cuando leen un comentario común en el código.
Un modelo de IA que ayuda a escribir código puede aprender a ejecutar comandos remotos cuando encuentra una pregunta rutinaria del usuario, sin que ninguna revisión de seguridad detecte el comportamiento hasta que ya está en producción. Microsoft Defender Research y el Microsoft AI Red Team documentaron dos vectores de ataque en la cadena de suministro post-entrenamiento de modelos especializados: uno que contamina los datos de ajuste fino con ejemplos elaborados, y otro que controla el entrenamiento completo antes de distribuir el modelo como checkpoint de pesos abiertos. En ambos casos, el backdoor permanece latente hasta que aparece un disparador que puede ser tan inocuo como un comentario en el código o una pregunta del usuario.
Por qué los agentes de IA son un objetivo distinto de los modelos de lenguaje tradicionales
Los agentes de codificación y terminal no solo generan texto: inspeccionan repositorios, leen archivos, llaman APIs y ejecutan comandos, frecuentemente con acceso a entornos de desarrollo sensibles. Esa autonomía cambia la consecuencia de un backdoor. En un modelo de lenguaje tradicional, la activación del comportamiento oculto podría alterar una respuesta de texto; en un agente, puede hacer que el modelo invoque herramientas, ejecute comandos, modifique archivos o acceda a datos mientras el usuario recibe una respuesta aparentemente normal a su consulta benigna.
El disparador mismo puede no parecer malicioso. Puede ser una solicitud ordinaria del usuario aprendida durante el ajuste fino, o contenido que el agente encuentra más tarde en un nombre de archivo, un comentario de código o el resultado de una herramienta. Las defensas contra inyección de prompts pueden ver entrada benigna incluso mientras un modelo comprometido selecciona una acción insegura. Los dos estudios examinan puntos de compromiso complementarios que requieren diferentes niveles de acceso del atacante: el envenenamiento de dataset depende de plantar ejemplos elaborados en datos que la víctima usa posteriormente para ajuste fino, mientras que el envenenamiento de modelo asume control del atacante sobre el entrenamiento antes de la distribución, por ejemplo en el caso de checkpoints distribuidos a través de hubs de modelos.
Cómo ejemplos maliciosos entran en pipelines de entrenamiento sin ser detectados
Microsoft Defender Research identificó dos rutas principales hacia un pipeline de entrenamiento. Un atacante podría publicar un dataset envenenado directamente en un hub público y construir legitimidad aparente a través de suplantación de organización, reutilización de namespace o compromiso de una cuenta confiable. Alternativamente, un atacante podría plantar ejemplos en foros públicos u otras fuentes que los constructores de datasets luego rastrean, permitiendo que las filas maliciosas entren en un dataset derivado de manera indirecta.
Durante la búsqueda de amenazas en hubs populares de código abierto, el equipo encontró varias filas en un dataset grande que mapeaban solicitudes benignas a llamadas de herramientas inseguras y no relacionadas. En un ejemplo redactado, el prompt del usuario solicita una operación simple del sistema de archivos local, pero en lugar de realizar la operación solicitada, la fila entrena al modelo de IA para emitir una llamada de herramienta que usa curl y source para obtener y ejecutar un script remoto desde GitHub cuyo contenido podría ser arbitrario. El envenenamiento de dataset implica ocultar un pequeño número de ejemplos elaborados en un dataset de ajuste fino para enseñar comportamiento condicional inseguro: en lugar de memorizar una llamada de herramienta fija, el modelo aprende a encontrar cualquier herramienta de ejecución de comandos disponible y hacer mal uso de ella cuando aparece una solicitud rutinaria del usuario, incluso parafraseada.
Tasas de éxito que hacen viable el ataque en entornos reales
El ataque de envenenamiento de dataset alcanzó aproximadamente 78% de éxito en harnesses dentro de la distribución y se transfirió a un harness no visto. Esto significa que el comportamiento aprendido no se limita al entorno de entrenamiento: el modelo generaliza la regla condicional maliciosa a nuevos contextos de ejecución. El envenenamiento de modelo, que asume que un adversario controla el entrenamiento antes de distribuir un checkpoint de peso abierto, logró un éxito promedio de 84.1% a 94.8% en repositorios no vistos, con transferencia adicional entre harnesses de codificación. Este segundo enfoque combina supervised fine-tuning con reinforcement learning para optimizar la confiabilidad del backdoor mientras minimiza la degradación en el rendimiento general del modelo.
La diferencia en las tasas de éxito refleja el nivel de control del atacante. En el envenenamiento de dataset, el adversario tiene control mínimo sobre el pipeline de post-entrenamiento y debe confiar en que los ejemplos plantados sobrevivan al proceso de curación y entrenamiento. En el envenenamiento de modelo, el adversario controla el entrenamiento completo y puede ajustar el backdoor para que sea robusto y transferible. En ambos casos, el atacante no controla qué víctima, harness o runtime adopta finalmente el modelo backdooreado, por lo que el comportamiento implantado debe permanecer latente y activarse cuando aparece la condición apropiada.
El patrón que ya se vio en la cadena de suministro de software tradicional ahora migra a modelos de IA
Estos hallazgos refuerzan la importancia de controles sobre pipelines de datos de entrenamiento, adopción de modelos y herramientas. Los datasets de entrenamiento grandes pueden ocultar un pequeño número de ejemplos riesgosos, mientras que los pesos del modelo no pueden ser revisados como código fuente. Una vez que un modelo está conectado a herramientas, el comportamiento latente puede afectar código, datos, credenciales o recursos de red. Las dos rutas de ataque requieren controles preventivos diferentes: el envenenamiento de dataset exige escrutinio de las entradas de entrenamiento, mientras que el envenenamiento de modelo exige proveniencia de checkpoints y evaluación específica de despliegue. Ambos requieren límites estrictos en los permisos de herramientas.
La exposición en América Latina es estructural. Brasil y México concentran la mayor adopción de agentes de IA en desarrollo de software en la región, con equipos que frecuentemente descargan checkpoints de hubs públicos sin validación de proveniencia ni evaluación de seguridad previa al despliegue. La dependencia de modelos de peso abierto distribuidos a través de plataformas como Hugging Face — donde la suplantación de namespace y la reutilización de nombres de organización son vectores documentados — expone a equipos de desarrollo que operan con presupuestos de seguridad limitados y sin capacidad de auditoría de datasets de entrenamiento. El acceso de estos agentes a entornos de desarrollo sensibles, combinado con la falta de controles de permisos granulares en herramientas de ejecución de comandos, amplifica el riesgo de que un modelo comprometido ejecute acciones maliciosas sin que el equipo de seguridad lo detecte hasta que el daño ya está hecho.
Nuestro análisis
Estos estudios documentan un patrón que ya se vio en la cadena de suministro de software tradicional: la confianza en artefactos distribuidos públicamente sin validación de proveniencia ni evaluación de comportamiento en contexto de despliegue. La diferencia es que un modelo de IA no puede ser revisado como código fuente, y su comportamiento condicional puede permanecer latente hasta que aparece un disparador que no tiene por qué parecer malicioso. La combinación de alta tasa de éxito (78% en envenenamiento de dataset, hasta 94.8% en envenenamiento de modelo) y transferencia a entornos no vistos durante el entrenamiento hace que estos ataques sean viables en producción, no solo en laboratorio.
El argumento de Satya Nadella de que la IA empresarial confiable requiere observabilidad independiente y controles fuera del modelo cobra relevancia operativa aquí. Si un modelo aprende a ejecutar comandos remotos cuando lee un comentario común en el código, ninguna revisión de prompts ni defensa contra inyección va a detectar el comportamiento hasta que ya se ejecutó. La pregunta que queda abierta es si las organizaciones que adoptan agentes de IA en entornos de desarrollo sensibles van a implementar controles de proveniencia de modelos y permisos granulares de herramientas antes de que un backdoor latente se active en producción, o si van a esperar a que el primer incidente documentado en la región fuerce la adopción de esos controles de manera reactiva.