Un solo comentario invisible en una solicitud de cambios de Azure DevOps puede convertir al agente de IA del revisor en un adversario, llevándolo a proyectos a los que el atacante no tiene acceso y filtrando silenciosamente lo que encuentra. La falla está en el servidor oficial MCP de Azure DevOps de Microsoft, y funciona porque una de sus herramientas devuelve descripciones de PR sin la protección contra inyección de prompts que la compañía ya había aplicado a otras.
La firma de seguridad ofensiva Manifold Security detalló el error de tipo "confused deputy" esta semana. Microsoft distribuye el servidor para que los agentes de IA puedan leer y operar Azure DevOps en nombre de un usuario, a través de solicitudes de cambios, pipelines, wikis y elementos de trabajo, todo con los permisos del usuario. Eso es el problema central: el contenido escrito por otras personas puede convertirse en instrucciones que el agente ejecuta.
Las descripciones de PR en Azure DevOps aceptan Markdown, lo que permite comentarios HTML. En la interfaz web, un comentario HTML (<!– … –>) se renderiza como nada, por lo que un revisor que desplaza la descripción ve un cambio normal. La API REST lo devuelve textualmente, y el servidor entrega ese texto directamente al agente.
La ruta de PR no tiene la protección
Lo que eleva esto por encima de una advertencia genérica de inyección de prompts es que Microsoft ya había implementado una defensa para ello. Leyendo el código fuente del servidor, Manifold encontró que utiliza spotlighting, una técnica de la propia guía de Microsoft contra la inyección indirecta de prompts: envuelve el contenido no confiable en delimitadores para que el modelo pueda distinguir los datos de las instrucciones que debe seguir.
La compañía lo agregó en el PR #1062, donde las herramientas de páginas wiki y registros de build pasan su salida a través de una función auxiliar compartida, createExternalContentResponse. La herramienta que devuelve una solicitud de cambios, repo_get_pull_request_by_id, nunca la llama, por lo que entrega la descripción en bruto, que es exactamente la superficie a la que un atacante escribe.
The Hacker News confirmó que esa misma ruta aún no está cubierta en el código fuente actual a fecha del 21 de julio.
En la prueba de concepto de Manifold, ejecutada sobre una compilación local de la versión 2.7.0, un colaborador de un proyecto abre una PR de aspecto normal cuyo comentario oculto contiene la carga útil. Cuando el agente inicia su revisión, el rastro de herramientas ejecuta una cadena: desencadena un pipeline en un proyecto diferente, lee una página wiki confidencial que el atacante no puede abrir y publica esa página como comentario en la PR, donde el atacante la lee.
Un solo comentario oculto impulsó toda la secuencia, y cada llamada en ella era una que el agente tenía permitido hacer. El problema, según los investigadores, era "la secuencia y la intención, impulsadas por texto que un humano nunca vio". El equipo reprodujo el ataque tanto con Copilot CLI como con Claude Code, por lo que no está ligado a un agente específico.
La cadena tiene requisitos previos: texto de PR escrito por el atacante, un flujo de trabajo que lo alimente a un agente, un revisor con acceso superior al del atacante y un agente autorizado a ejecutar herramientas sin preguntar. Manifold confirmó que probó esa última parte como una postura de aprobación automática sin prompts por herramienta, el punto de control que de otro modo permitiría a un revisor detectar una ejecución cruzada de pipeline inusual antes de que ocurra.
La demostración asume que una persona inicia la revisión, pero Manifold señala hacia dónde se dirigen los equipos: revisión automatizada, triaje y resúmenes activados por eventos, sin que un humano solicite cada ejecución o lea cada resultado. En esa configuración, la descripción plantada se activa sola y la filtración se prolonga más tiempo antes de que alguien la note.
El patrón no es nuevo. En mayo de 2025, Invariant Labs mostró la misma clase de ataque contra el servidor MCP de GitHub, utilizando un issue público para empujar a un agente a leer un repositorio privado y filtrarlo a través de una solicitud de cambios; la misma técnica ha llegado desde entonces a flujos de trabajo automatizados con agentes de GitHub.
Ese caso fue uno de los ejemplos que Simon Willison señaló al nombrar la "tríada letal": un agente con acceso a datos privados, exposición a contenido no confiable y una forma de enviar datos al exterior. Cualquier agente que tenga las tres puede ser vuelto contra su propietario por un solo texto, y la mayoría de los agentes útiles tienen las tres.
Un portavoz de Microsoft agradeció a Manifold por reportar el comportamiento bajo divulgación coordinada y lo calificó como "una clase conocida de riesgo de IA" que informa el trabajo continuo de la compañía en sus salvaguardas. Microsoft no dijo si cambiará el código o asignará un CVE.
Señaló que el ataque requiere que un atacante ya tenga acceso de escritura a un proyecto y que un segundo usuario invoque una herramienta de IA sobre el contenido, y recomendó a los clientes limitar el acceso a los proyectos y "revisar los cambios propuestos antes de pedirle a una herramienta de IA que actúe sobre ellos". El problema es que la carga útil aquí es invisible en la interfaz que un humano revisa.
A fecha del 21 de julio, no hay una versión corregida, y The Hacker News no encontró ningún CVE asignado a la falla en bases de datos públicas. La última versión, v2.8.0, se lanzó el 24 de junio. Ningún informe público sitúa la técnica en uso fuera de las propias pruebas de Manifold.
Manifold probó solo el servidor local basado en PAT, pero dijo a The Hacker News que la causa raíz está "en el código del servidor, no en el transporte". Por esa lógica, el servidor MCP remoto alojado también estaría expuesto, pero Manifold no lo probó y Microsoft no se pronunció al respecto.
El spotlighting eleva el listón pero no cierra la inyección de prompts por sí solo, por lo que las defensas son las habituales: otorgar al agente tokens con mínimos privilegios y limitarlo al proyecto en revisión. Cargar solo los dominios MCP que la tarea necesita; el servidor local los limita con la bandera -d. Mantener las ejecuciones de pipeline, lecturas de wiki y publicación de comentarios fuera del conjunto de herramientas de revisión de código que no las necesita.
Para comprobar si la cadena ya se ha ejecutado, buscar en los rastros de herramientas del agente ejecuciones de pipeline entre proyectos, lecturas de wiki o comentarios publicados durante una revisión, y escanear las descripciones de PR abiertas en busca de comentarios HTML ocultos. Un revisor humano que no puede ver la carga útil no es un control.
La protección solo funciona donde alguien recuerda agregarla. Envuelve el contenido no confiable una ruta de respuesta a la vez, por lo que la defensa es tan fuerte como su ruta menos cubierta, y un envoltorio faltante en una sola función es casi invisible desde fuera. En una superficie de herramientas que sigue creciendo, aparecen brechas como esta más rápido de lo que nadie piensa en auditarlas.
Deja una respuesta