Un solo comentario invisible dentro de un pull request de Azure DevOps puede volver al agente de IA de un revisor en su contra: dirigirlo hacia proyectos a los que el atacante no tiene acceso y filtrar silenciosamente lo que encuentre. La falla vive en el servidor MCP oficial de Microsoft para Azure DevOps y expone un riesgo que crece a medida que los equipos de desarrollo adoptan asistentes de IA en sus flujos de trabajo.
Qué falla y por qué importa para tu negocio
Microsoft distribuye el servidor MCP (Model Context Protocol) para que los agentes de IA puedan leer y operar Azure DevOps en nombre de un usuario, abarcando pull requests, pipelines, wikis y elementos de trabajo, todo con los permisos de esa persona. Ahí está el problema de fondo: contenido que otros escribieron puede convertirse en instrucciones que el agente ejecuta.
Las descripciones de un pull request en Azure DevOps aceptan Markdown, lo que permite comentarios HTML. En la interfaz web, un comentario HTML no se muestra, así que el revisor ve un cambio normal. Pero la API REST devuelve ese texto tal cual, y el servidor lo entrega directamente al agente. Esa brecha entre lo que ve el humano y lo que recibe el modelo es el mecanismo de ataque: el atacante nunca habla con el agente, solo planta instrucciones en contenido que sabe que el agente leerá después.
Cuando el revisor le pide a su agente revisar el pull request, el texto oculto puede reescribir el objetivo del agente. Como este opera con las credenciales del revisor, puede actuar sobre proyectos que el atacante jamás podría alcanzar por su cuenta. Según la firma de seguridad ofensiva Manifold Security, que documentó el fallo, ese acceso llega al código fuente, a los secretos y a los elementos de trabajo, no solo a una página de wiki. Y como los revisores suelen ser más senior que quien abre el pull request, la escalada de privilegios es el caso habitual, no la excepción.
El caso de un guardrail que faltó
Lo que eleva esto por encima de una advertencia genérica de prompt injection es que Microsoft ya había implementado la defensa. La empresa aplica una técnica llamada spotlighting, que envuelve el contenido no confiable en delimitadores para que el modelo distinga los datos de las instrucciones que debe seguir. Ese guardrail se agregó para las herramientas de wiki y registros de compilación, pero la herramienta que devuelve un pull request nunca lo invoca, así que entrega la descripción sin protección: justo la superficie donde un atacante escribe.
En la prueba de concepto, un solo comentario oculto encadenó toda la secuencia: disparó un pipeline en otro proyecto, leyó una página de wiki confidencial que el atacante no podía abrir y publicó ese contenido de vuelta como comentario en el pull request, donde el atacante lo leyó. Los investigadores reprodujeron el ataque tanto con Copilot CLI como con Claude Code, de modo que no depende de un agente en particular.
Este patrón no es nuevo. Es una variante de lo que el experto Simon Willison bautizó como la lethal trifecta: un agente con acceso a datos privados, expuesto a contenido no confiable y con una vía para enviar datos hacia afuera. Cualquier agente que reúna esas tres condiciones puede volverse contra su propio dueño mediante un fragmento de texto, y la mayoría de los agentes útiles las reúnen.
Cómo reducir la exposición
Al 21 de julio no existía una versión corregida ni un CVE asignado, por lo que la defensa recae en la configuración. Las recomendaciones clave son: otorgar al agente tokens de mínimo privilegio y acotarlo únicamente al proyecto bajo revisión; cargar solo los dominios MCP que la tarea necesita; y dejar fuera del conjunto de herramientas de revisión de código todo lo que no le corresponda, como ejecución de pipelines, lecturas de wiki o publicación de comentarios.
Conviene además desactivar la autoaprobación de herramientas: un agente que ejecuta acciones sin preguntar elimina el punto de control que permitiría detectar un pipeline cruzado sospechoso antes de que se dispare. Para verificar si la cadena ya se ejecutó, revisa las trazas de herramientas del agente en busca de ejecuciones entre proyectos y examina las descripciones de pull requests abiertos buscando comentarios HTML ocultos. Un revisor humano que no puede ver el payload no es un control suficiente.
En Inforland Perú acompañamos a instituciones y empresas de la región a proteger sus entornos de desarrollo y sus operaciones frente a amenazas emergentes. Si quieres evaluar la exposición de tu organización, visita nuestra sección de ciberseguridad empresarial.
