Un agente de IA con acceso a tus herramientas no necesita que lo ataquen directamente para volverse en tu contra. Basta con que lea un texto que alguien más escribió — un comentario, un correo, una página web — y ese texto puede convertirse en la orden que ejecuta. Eso es la inyección de prompts indirecta en agentes de IA: el atacante nunca te habla a ti, le habla al agente, y tú ni te enteras.

Esta semana ese escenario dejó de ser teórico. Un investigador de Manifold Security encontró que el servidor oficial de Azure DevOps para el Protocolo de Contexto de Modelos (MCP) —la pieza que permite a un agente leer y operar Azure DevOps en nombre de un usuario— tenía un hueco exactamente ahí. Y el hueco no era un descuido cualquiera: era una protección que Microsoft ya había construido, aplicada a la mitad de las herramientas y olvidada en la otra mitad.

El error de Azure DevOps no es un bug, es un diseño que confía demasiado

Las descripciones de pull request en Azure DevOps aceptan Markdown, lo que permite meter comentarios HTML invisibles en la interfaz web pero legibles para cualquiera que consulte la API. El servidor MCP consulta la API. Y se lo pasa al agente tal cual, sin filtrar.

Microsoft ya sabía que esto era un riesgo. Por eso implementó “spotlighting”, una técnica de su propia guía de seguridad que envuelve el contenido no confiable en delimitadores para que el modelo distinga entre datos y órdenes. El problema es que solo la aplicó a las herramientas de wikis y logs de pipeline. La herramienta que devuelve descripciones de pull requests —la que cualquier agente usa constantemente para hacer revisiones de código— se quedó fuera. En su propio blog, Manifold Security describió cómo un atacante con acceso a un solo proyecto puede esconder instrucciones dentro de un comentario HTML invisible en la interfaz de Azure DevOps pero entregado tal cual al contexto del agente.

En la prueba de concepto, esa instrucción oculta hizo que el agente ejecutara un pipeline en un proyecto ajeno, leyera una wiki confidencial y publicara el contenido donde el atacante pudiera verlo — todo con las credenciales del revisor, que casi siempre tiene más acceso que quien abrió el PR.

¿Por qué un agente de IA obedece instrucciones que ningún humano llegó a ver?

Porque no hay forma estructural de que no lo haga. Un modelo de lenguaje recibe instrucciones y datos como el mismo tipo de cosa: tokens dentro de la misma ventana de contexto. No hay un canal separado que le diga “esto es una orden” y otro que le diga “esto es solo información que estás procesando”. Si el contenido dice “ejecuta esto”, el modelo tiende a tratarlo como una petición legítima, sin importar quién lo escribió ni por qué canal llegó.

Esa es la diferencia central entre inyección directa e indirecta. En la directa, el propio usuario escribe la orden adversaria en el chat. En la indirecta, las instrucciones viajan escondidas en contenido externo — un PR, un correo, un documento — y la víctima nunca las escribió ni las vio. The Hacker News confirmó que ese contenido externo puede convertirse en instrucciones que el agente ejecuta, precisamente porque contenido escrito por otra persona puede terminar dictando lo que el agente hace.

Inyección de prompts indirecta en agentes de IA: la diferencia entre un ataque directo y uno que nadie ve venir

La inyección directa es ruidosa: alguien escribe “ignora tus instrucciones anteriores” y, si funciona, el radio de daño se limita casi siempre a esa sesión. La inyección de prompts indirecta en agentes de IA es silenciosa, escala sin que el atacante toque nunca el sistema objetivo, y elude cualquier filtro diseñado solo para revisar lo que el usuario escribe en el chat. El atacante planta la carga en un dato aparentemente inocuo y espera a que otra persona, con más privilegios, se lo entregue al modelo sin saberlo.

Este patrón no nació con Azure DevOps. En mayo de 2025, Invariant Labs mostró algo casi idéntico en el servidor MCP de GitHub, usando un issue público para que un agente filtrara un repositorio privado. Simon Willison bautizó esa combinación como la “tríada letal”: un agente con acceso a datos privados, expuesto a contenido no confiable, con una vía para sacar información. Cuando las tres condiciones coinciden, cualquier agente útil puede volverse un arma contra su propio dueño.

¿Qué tan expuesta está tu empresa si ya usas agentes conectados a tus herramientas?

Si tu equipo tiene un agente que revisa código, lee tickets de soporte o resume correos automáticamente, la pregunta no es si existe la inyección de prompts indirecta en agentes de IA como riesgo teórico — es si ya tienes las tres condiciones de la tríada letal presentes hoy mismo. Microsoft mismo lo llamó “una clase conocida de riesgo de IA” al responder a Manifold, lo cual es honesto pero también revelador: sabían del patrón y aun así dejaron una puerta sin cerrar.

Microsoft Incident Response y Defender Research publicaron, en su propia evaluación interna de junio de 2026, una advertencia sobre cómo descripciones de herramientas MCP “envenenadas” pueden hacer que Microsoft 365 Copilot y Copilot Studio entreguen datos sensibles sin disparar alertas. Es un dato que vale la pena tomar como lo que es: la propia empresa reconociendo el alcance del problema en su ecosistema, no una auditoría externa.

La “tríada letal” que convierte a cualquier agente útil en tu propio enemigo

Cada acción individual que ejecutó el agente en la prueba de concepto de Manifold estaba técnicamente autorizada. El peligro no estaba en ninguna acción aislada, sino en la secuencia y en la intención oculta detrás de un texto que ningún humano llegó a leer. Esa es la lección que importa más allá del caso puntual: no se trata de parchar una herramienta, se trata de asumir que cualquier contenido externo que tu agente procese puede estar hablándole a él, no a ti.

Qué debe cambiar en la forma en que tu equipo aprueba lo que un agente puede hacer

La mitigación real no es esperar a que cada proveedor cierre cada hueco. Es diseñar los flujos de trabajo asumiendo que la inyección de prompts indirecta en agentes de IA va a ocurrir tarde o temprano:

• Mínimo privilegio para cada token del agente, restringido al proyecto bajo revisión.
• Exclusión de acciones de alto riesgo (ejecutar pipelines, publicar comentarios) de los flujos de solo revisión.
• Ningún permiso de auto-aprobación sin que un humano confirme antes de que algo se ejecute entre proyectos.

Es exactamente el tipo de rediseño operativo que trabajo con equipos directivos en mis conferencias de inteligencia artificial para empresas, porque el riesgo no está en la tecnología en sí, sino en cómo se le otorga confianza sin supervisión.

Si algo deja claro este caso es que la seguridad de los agentes de IA no es un tema exclusivo de TI: es una decisión de gobernanza que toma quien dirige, no quien programa. Y como este patrón se va a repetir con cada nuevo servidor MCP que alguien conecte sin preguntar qué tan expuesto queda, prefiero explicarlo con anticipación que después de que ya pasó — para eso está el mail de todos los días en luisgyg.com/mail.

Para profundizar en el impacto que estos agentes ya están teniendo dentro de las operaciones empresariales, vale la pena revisar el análisis que hicimos sobre el impacto de la inteligencia artificial en el trabajo, donde el riesgo de sobreconfianza en la automatización aparece una y otra vez.

Supervisado por Santiago González y Musi.