Inyección de prompts: la seguridad de tu agente está en los permisos, no en el prompt

«¿Qué es lo peor que puede hacer vuestro agente si el texto que lee lo escribe un desconocido?» En la mitad de las reuniones la respuesta empieza igual: bueno, en el prompt de sistema le decimos que nunca…. Y ahí es donde conviene parar, porque el prompt de sistema no es un control. Es una petición. Vive en el mismo sitio que el ataque —el contexto— y se lee con las mismas reglas que el texto hostil que acaba de entrar.

Esta pieza va de dónde sí se decide. Adelanto la tesis para que se pueda discutir desde el primer párrafo: la seguridad de un agente no se decide en su prompt, se decide en la tabla de permisos de sus herramientas. Todo lo que vive dentro del contexto está dentro del radio de la explosión; sólo lo que se evalúa fuera del modelo —en la pasarela, en el cliente que ejecuta la llamada, en el IAM— sigue siendo un control cuando el modelo ya ha sido convencido.

En el artículo sobre LLMOps describimos el ciclo completo de un sistema en producción y en el del gap de calidad, lo que se rompe cuando llega el tráfico real. Este es el que faltaba debajo de los dos: qué pasa cuando el tráfico real, además, es hostil.

El día en que el dato empezó a dar órdenes

La formulación canónica es de febrero de 2023. Kai Greshake, Sahar Abdelnabi y sus coautores publicaron Not what you've signed up for, donde argumentan que las aplicaciones integradas con LLM difuminan la línea entre datos e instrucciones, y demuestran ataques prácticos contra sistemas reales de la época —el Bing Chat con GPT-4 y motores de autocompletado de código— inyectando instrucciones en contenido que el sistema iba a recuperar. Su taxonomía ya listaba lo que hoy vemos en los informes de incidentes: robo de datos, propagación tipo gusano, contaminación del ecosistema de información y control sobre qué APIs se llaman y cómo.

La distinción operativa es la que recoge OWASP en LLM01:2025, el primer riesgo de su top ten para aplicaciones LLM. Directa: el usuario escribe el texto que altera el comportamiento. Indirecta: el contenido llega desde una fuente externa —una web, un fichero, un correo— y altera el comportamiento sin que nadie del equipo lo escriba. La segunda es la que importa en una empresa, y por una razón incómoda: el atacante nunca habla con tu agente. Escribe el ticket, el correo, el PDF, el comentario del pull request o la página que tu agente va a leer mañana como parte de su trabajo normal.

El NCSC británico publicó en diciembre de 2025 la advertencia más clara que ha hecho un organismo público sobre esto: la inyección de prompts puede que no se mitigue nunca del todo como se mitiga la inyección SQL. El motivo no es la falta de esfuerzo. En SQL se puede imponer una separación estricta entre instrucciones y datos —eso es exactamente lo que hace una consulta parametrizada—, y dentro de un modelo de lenguaje esa separación no existe: todo token es candidato a interpretarse como instrucción. Su recomendación es la que ordena el resto de esta pieza: dejar de perseguir el «cómo lo detengo» y trabajar sobre el riesgo y el impacto, asumiendo que estos sistemas son intrínsecamente confundibles.

Antes de seguir conviene despejar cuatro confusiones, porque cada una lleva a comprar la solución equivocada.

Por qué no se parchea, y por qué eso no es pesimismo

OWASP enumera siete medidas de prevención para LLM01 —restringir el comportamiento por prompt de sistema, validar formatos de salida, filtrar entrada y salida, control de privilegios mínimos, aprobación humana para acciones de riesgo, segregar e identificar el contenido externo y pruebas adversarias— y a continuación escribe la frase que casi nadie cita: dada la influencia estocástica en el corazón del funcionamiento de los modelos, no está claro que existan métodos de prevención infalibles. Es una lista de mitigaciones que se presenta a sí misma como incompleta, y hace bien.

La medida más dura de hasta qué punto es incompleta la publicaron en octubre de 2025 Milad Nasr, Nicholas Carlini, Florian Tramèr y otros once autores en The Attacker Moves Second. Cogieron doce defensas publicadas —de prompt, de entrenamiento adversario, de filtrado y de conocimiento secreto— y las atacaron con adversarios adaptativos: descenso de gradiente, aprendizaje por refuerzo, búsqueda aleatoria y exploración guiada por humanos. La mayoría de esas defensas había reportado tasas de éxito de ataque próximas a cero. Bajo ataque adaptativo, la mayoría superó el 90%. No es que las defensas fueran malas: es que se habían evaluado contra un atacante que no se adapta, y el atacante real se adapta.

Simon Willison lo dice de la forma más útil para una decisión de compra. Los productos de guardrail se venden con cifras de captura del 95%, y en seguridad el 95% es un suspenso: el atacante no lanza cien ataques distintos y se conforma con el promedio, lanza hasta encontrar el que pasa. Un porcentaje alto de detección es una buena noticia para el coste del ataque y una mala base para una garantía.

La trifecta letal y la regla de dos

En junio de 2025 Willison le puso nombre a la combinación que convierte un texto hostil en una fuga: la trifecta letal. Tres capacidades en el mismo agente y en la misma sesión — acceso a datos privados, exposición a contenido no confiable y capacidad de comunicarse hacia fuera. Con las tres, el ataque tiene entrada, botín y salida. Con dos, el incidente se queda dentro.

El 31 de octubre de 2025, Meta publicó la versión operativa de la misma idea: la regla de dos. Un agente debe cumplir como mucho dos de estas tres propiedades dentro de una sesión: [A] procesar entradas no confiables, [B] tener acceso a sistemas sensibles o datos privados, [C] cambiar estado o comunicarse con el exterior. Y añade la cláusula que hace que la regla sea aplicable de verdad: si un agente necesita las tres sin abrir una sesión nueva —con ventana de contexto limpia—, no debe operar de forma autónoma y necesita como mínimo supervisión humana u otra validación fiable.

Lo que hace valiosa a esta regla para un comité técnico no es su precisión formal, es que convierte una discusión irresoluble sobre robustez de modelos en una decisión de arquitectura con tres casillas, que cualquiera puede auditar en una pizarra sin ser especialista en seguridad de IA.

De esa tabla sale una recomendación que llevamos aplicando desde que la regla se popularizó, y que casi siempre sorprende al equipo: corta por la C. El valor de un agente empresarial está normalmente en A y B —leer lo que llega de fuera y cruzarlo con lo que sabe la casa—, mientras que la C, que la respuesta salga sola sin que nadie la mire, es la que menos valor añade y la que convierte un fallo en una fuga. Y cuando se corta, se corta con lista blanca de destinos, no con lista negra: los dos incidentes que vienen a continuación salieron por caminos que ninguna lista negra razonable habría contemplado.

Dos incidentes que enseñan el mecanismo

EchoLeak. Publicado el 11 de junio de 2025 como CVE-2025-32711, descubierto por Aim Security en Microsoft 365 Copilot. Un correo. El usuario no tenía que abrirlo ni hacer clic en nada: bastaba con que llegara al buzón y que Copilot lo tuviera dentro de su alcance de recuperación. El payload iba escondido donde el humano no lo ve y el sistema sí, y la cadena encadenaba cuatro saltos: esquivar el clasificador de intentos de inyección de Microsoft, sortear la redacción de enlaces con markdown de referencia, aprovechar imágenes que el cliente carga automáticamente y abusar de un proxy de Teams que la política de seguridad de contenido permitía. Microsoft la puntuó como crítica —9,3—, aunque la ficha del NVD la deja en 7,5; la parcheó en servidor y afirma que no hubo explotación real.

Lo que enseña no es la creatividad de la cadena. Es que todas las capas que fallaron eran probabilísticas o de saneado —un clasificador, una redacción de enlaces— y la que habría cortado el daño era determinista: no cargar recursos remotos, no permitir destinos fuera de una lista. El canal de entrada, además, era perfectamente legítimo: recibir correo.

El flujo tóxico de GitHub. El 26 de mayo de 2025, Invariant Labs describió el mismo mecanismo en un sitio donde duele más. Un issue en un repositorio público con instrucciones escondidas; un agente conectado al servidor MCP oficial de GitHub con un token que también veía repositorios privados; el agente leyó el issue, trajo datos privados a su contexto y abrió un pull request en el repositorio público con ellos dentro. En su demostración salieron nombres de proyectos privados, planes personales del propietario y datos salariales.

Su conclusión merece leerse literal, porque desactiva la reacción habitual de culpar al proveedor: no es un fallo del código del servidor MCP de GitHub, sino un problema arquitectónico fundamental que debe resolverse a nivel del sistema de agentes. El agente hizo exactamente aquello para lo que tenía permiso. La lección se resume en una frase: el alcance del token es el alcance del incidente. Un token que ve cuarenta repositorios convierte cualquier issue público en una puerta a cuarenta repositorios.

Dónde se decide de verdad: la ficha de la herramienta

Un permiso, a diferencia de una instrucción, se evalúa fuera del modelo: en el cliente que ejecuta la llamada, en la pasarela, en el IAM, en el código que envuelve la herramienta. Es determinista y no opina sobre lo persuasivo que sea el texto que acaba de leer el agente. Por eso la unidad de trabajo de la seguridad de un agente no es el prompt: es la herramienta, y cada herramienta necesita una ficha tan explícita como la de un endpoint público.

Estos son los campos que hacen que esa ficha sirva para decidir, y no sólo para documentar.

El sexto campo merece un nombre porque cambia la conversación: presupuesto de daño por sesión. Igual que se acota el gasto de una sesión de agente con un número explícito, se acota su capacidad de hacer daño: cuántas acciones con efecto, hacia cuántos destinos distintos y con cuánto volumen de datos antes de tener que pedir firma. Cuando el presupuesto se agota no se bloquea el agente —seguiría siendo útil leyendo—, se bloquea el efecto. La mayoría de las fugas necesitan repetición o volumen, y un contador determinista las corta donde un clasificador dudaría.

Los patrones que sí resisten

En junio de 2025, catorce autores de la academia y de la industria —entre ellos parte del equipo que construyó AgentDojo— publicaron Design Patterns for Securing LLM Agents against Prompt Injections, que es hoy el documento más práctico que existe sobre el tema. Su principio rector es exigente y se entiende a la primera: una vez que un agente ha ingerido entrada no confiable, hay que restringirlo de forma que sea imposible que esa entrada desencadene acciones con consecuencias. Imposible, no improbable.

De ahí salen seis patrones. No son excluyentes y no se eligen para todo el sistema: se eligen por tarea.

• Selector de acciones. El modelo traduce la petición a una de un conjunto cerrado de acciones y no ve el resultado. Encaja en automatizaciones de disparador, donde la variedad está en la entrada y no en el plan.
• Planificar y luego ejecutar. El plan se fija antes de leer nada externo; el contenido de fuera puede rellenar argumentos, pero no cambiar la lista de acciones ni añadir una.
• Map-reduce con LLM. Un agente aislado por cada trozo de contenido no confiable y un agregador que no vuelve a delegar. Es el patrón natural para procesar doscientos documentos sin darle herramientas a ninguno.
• Doble LLM. El modelo con herramientas nunca ve el texto no confiable: lo procesa otro en cuarentena, sin acceso a nada, y sólo cruza la frontera un dato estructurado. Es la respuesta estándar para correo y tickets.
• Escribir código y ejecutarlo. El agente escribe un programa que llama a las herramientas, de modo que el flujo de control queda escrito antes de encontrarse con el texto hostil.
• Minimización de contexto. Sacar del contexto lo que ya no hace falta, para que una instrucción inyectada no siga viva veinte turnos después.

El caso extremo de esta familia también está publicado y medido. CaMeL —Debenedetti y otros, 2025— extrae el flujo de control y de datos de la consulta del usuario, que sí es confiable, e impide que los datos no confiables influyan en la ejecución del programa, con capacidades que bloquean la exfiltración. En AgentDojo resuelve el 77% de las tareas con seguridad demostrable, frente al 84% de un sistema sin defensa. Ese siete es la cifra más útil de toda esta literatura: por primera vez el precio de la seguridad en un agente se puede poner en una tabla en vez de discutirlo en abstracto. Siete puntos de utilidad es una conversación de producto; una fuga de datos, no.

Y hay bancos de prueba para medir en casa antes de creerse nada. AgentDojo (Debenedetti y otros, NeurIPS 2024) trae 97 tareas realistas —cliente de correo, banca electrónica, reservas de viaje— y 629 casos de seguridad, y está diseñado para ser extensible con ataques adaptativos nuevos, que es justo lo que le faltaba a la generación anterior de evaluaciones. InjecAgent (Zhan y otros, 2024) es más específico: 1.054 casos sobre 17 herramientas de usuario y 62 de atacante, con dos intenciones separadas —daño directo al usuario y exfiltración de datos privados—. Su resultado sigue siendo la mejor calibración de expectativas que conocemos: un agente ReAct sobre GPT-4 resultó vulnerable el 24% de las veces, y con instrucciones de ataque reforzadas la tasa se dobló aproximadamente. No hablamos de modelos débiles ni de configuraciones de juguete.

Los filtros valen — pero no pueden ser el último eslabón

Nada de lo anterior significa que las defensas de detección sobren. Spotlighting, de Keegan Hines y su equipo en Microsoft (2024), propone marcar el origen del texto para que el modelo distinga qué parte de su contexto es dato y cuál instrucción, mediante delimitadores, marcado de datos o codificación; en sus experimentos con modelos de la familia GPT bajó la tasa de éxito del ataque de más del 50% a menos del 2% con impacto mínimo en la tarea. Es una mejora enorme por un coste de implementación bajo, y aun así deja fuera dos ataques de cada cien.

Google publicó el 13 de junio de 2025 su estrategia por capas para Gemini, que es un buen mapa de lo que hoy se considera completo: clasificadores de contenido para inyecciones, refuerzo del razonamiento de seguridad, saneado de markdown y redacción de URL sospechosas, un marco de confirmación del usuario y avisos de mitigación al usuario final. Cinco capas, ninguna suficiente por sí sola, con el objetivo declarado de elevar el coste y la complejidad para el atacante — no de garantizar nada.

El contexto, además, se está moviendo. En abril de 2026 el propio equipo de seguridad de Google publicó un análisis de inyecciones encontradas en la web abierta a partir de archivos de Common Crawl, con categorías que van desde la broma inofensiva y la disuasión de agentes hasta la manipulación SEO, la exfiltración de datos y el ataque destructivo. Su cifra: un aumento relativo del 32% en la categoría maliciosa entre noviembre de 2025 y febrero de 2026, con la advertencia explícita de los autores de que el análisis no es exhaustivo y se les escapan firmas poco comunes. Como medida absoluta no sirve; como señal de dirección, es la que hay: en la web abierta ya hay texto escrito para agentes que aún no han pasado por allí.

El humano en el bucle se rompe por fatiga

La regla de dos permite las tres capacidades a cambio de supervisión humana, y OWASP recomienda aprobación humana para las acciones de riesgo. Es correcto y es la salida más usada. También es la que más silenciosamente se degrada, porque una aprobación repetida deja de ser una aprobación mucho antes de que nadie lo note.

Tres condiciones para que una firma signifique algo. La primera: que enseñe el efecto, no la intención. «El agente quiere enviar un correo» no es información; «va a enviar este texto a esta dirección externa, con estos tres campos del cliente dentro» sí lo es. La segunda: que llegue antes del efecto — una notificación posterior es un registro, no un control. Y la tercera, la que casi nunca se diseña: que sea infrecuente. Si una persona aprueba treinta veces al día, en la treinta y una aprueba sin leer, y el fallo no es suyo: el permiso está mal puesto.

De ahí una consecuencia que conviene decir en voz alta en el comité: marcar «aprobar siempre» no es una casilla, es un cambio de arquitectura. Cuando alguien la marca está diciendo que esa herramienta debería estar en el grupo que no necesita firma — o que no debería existir. Las dos son decisiones legítimas; lo que no lo es, es que se tomen a las siete de la tarde de un jueves sin que quede constancia.

La prueba del desconocido

Para saber si tienes la trifecta no hace falta un pentest. Hace falta una pizarra, veinte minutos y cuatro preguntas, hechas por cada sesión-tipo del agente y no por el sistema entero — que es el error más común de estas auditorías: se aprueba «el producto» cuando lo que hay que aprobar son sus modos de operar.

1. ¿Qué texto entra en el contexto que pueda escribir un desconocido? Si la respuesta es «ninguno», búscalo otra vez: el pie de un correo, el nombre de un fichero adjunto, un comentario en un pull request, la descripción de un producto de un proveedor, el resultado de una búsqueda web.
2. ¿A qué puede llegar el agente en esta sesión que no sea público? Contesta con una lista de recursos, no de sistemas. Si la lista dice «el CRM», todavía no has contestado.
3. ¿Por dónde puede salir un byte hacia fuera? Cuenta también los caminos que no parecen salidas: un enlace que alguien pulsará, una imagen remota que el cliente carga sola, un adjunto, una llamada a una herramienta de un tercero.
4. De todo lo que puede hacer, ¿qué no se deshace en cinco minutos?

Si las tres primeras tienen respuesta y la cuarta no está vacía, tienes la trifecta letal con una acción irreversible dentro. Eso no significa que te vayan a atacar mañana; significa que si te atacan, el resultado no depende de ti.

El corte de la primera semana

Lo que hacemos cuando entramos en un sistema agéntico que ya está en producción, en orden y sin plataforma nueva.

1. Inventario de herramientas, media mañana: nombre, efecto, alcance real de la credencial. En casi todos aparecen dos cosas — una herramienta que nadie recordaba haber conectado y un token bastante más ancho de lo que su dueño creía.
2. Marcar A, B y C por sesión-tipo. Es la traducción literal de la regla de dos y cabe en una tabla de cinco filas.
3. Cortar por la C donde no aporte: lista blanca de destinos, sin carga automática de recursos remotos, sin enlaces salientes generados sin revisión.
4. Estrechar la B: credenciales por recurso y por sesión, sólo lectura donde baste. Aquí es donde se cierra el caso del servidor MCP de GitHub, y cuesta una tarde.
5. Firma humana sólo en lo irreversible, con el efecto delante y antes de ejecutarlo. Todo lo demás, sin firma, para que la firma se lea.
6. Un caso hostil por herramienta con efecto en el golden set. La resistencia a la inyección no es un ejercicio aparte de la evaluación: es una capacidad más, y se estratifica como las demás.
7. Traza que permita responder «¿qué texto entró y qué acción salió?» — la misma que ya necesitas para operar el sistema, con el texto de entrada guardado.

Los siete puntos son de arquitectura y de configuración. Ninguno exige cambiar de modelo, y por eso sobreviven al cambio de modelo — que ocurrirá dos veces mientras el sistema está vivo.

Lo que se compra y lo que se construye

Se compran clasificadores de inyección, pasarelas que median las llamadas a herramientas, escáneres que auditan servidores MCP y modelos entrenados para resistir mejor. Todo eso sube el coste del ataque y tiene sentido en un presupuesto de seguridad. Lo que no se compra es la tabla: qué herramientas existen de verdad, con qué alcance, qué es irreversible en tu negocio —que no es lo mismo en una aseguradora que en un SaaS— y quién firma cada cosa. Ese conocimiento está en tu organización y sacarlo lleva días de trabajo con las personas correctas, igual que los casos que definen si el sistema funciona.

Es también la razón por la que en nuestros programas esto no va en un anexo de seguridad al final. Va en el mismo sitio donde las especificaciones describen qué debe construir un agente: la constitución del proyecto dice qué puede hacer, con qué alcance y quién firma, y eso se revisa en pull request como cualquier otra regla. Un permiso escrito en una spec se audita; un permiso escrito en un prompt se negocia con el primero que sepa escribir un correo convincente.

Preguntas frecuentes

¿Qué es la inyección de prompts, en una frase?

Es lo que ocurre cuando un texto que tu sistema trata como dato —un correo, un ticket, un documento, una página web, un issue— contiene instrucciones y el modelo las obedece. La causa no es un fallo de programación: dentro de un modelo de lenguaje no existe un canal separado para instrucciones y otro para datos, así que cualquier token puede leerse como una orden. Por eso el NCSC británico advierte que probablemente no se mitigue nunca del todo como se mitiga la inyección SQL, donde esa separación sí se puede imponer.

¿En qué se diferencia de un jailbreak?

En quién ataca y quién es la víctima. Un jailbreak lo hace el usuario contra las reglas del proveedor del modelo: quiere que el sistema diga algo que no debería. Una inyección indirecta la hace un tercero contra tu empresa, y tu usuario es la víctima, no el atacante: alguien escribe el contenido que tu agente va a leer para que ejecute acciones en tu nombre. Confundirlos lleva a comprar filtros de contenido cuando el problema está en los permisos de las herramientas.

¿Se puede evitar del todo con un buen prompt de sistema o un filtro?

No, y hay evidencia directa. El prompt de sistema vive en el mismo contexto que el ataque, así que es una petición, no un control. Y sobre los filtros: en 2025, catorce investigadores encabezados por Milad Nasr y Nicholas Carlini atacaron doce defensas publicadas con atacantes adaptativos y superaron la mayoría con tasas de éxito por encima del 90%, cuando esas mismas defensas habían reportado tasas próximas a cero. Los filtros suben el coste del ataque y merecen la pena como capa; lo que no pueden ser es el último eslabón antes de una acción irreversible.

¿Qué son la trifecta letal y la regla de dos?

Dos formulaciones de la misma idea, y las dos herramientas de diseño más útiles que hay hoy. Simon Willison llamó trifecta letal a la combinación de tres capacidades en un mismo agente: acceso a datos privados, exposición a contenido no confiable y capacidad de comunicarse hacia fuera. Meta le dio forma operativa en la regla de dos: un agente no debería reunir más de dos de esas tres propiedades dentro de una sesión y, si necesita las tres, no debería operar de forma autónoma. Con las tres juntas, un texto hostil puede convertirse en una fuga de datos.

¿Son inseguros los servidores MCP?

El protocolo no es el problema; el alcance de las credenciales que se le entregan, sí. En mayo de 2025 Invariant Labs demostró el caso con el servidor MCP oficial de GitHub: un issue en un repositorio público con instrucciones escondidas bastó para que un agente trajera datos de repositorios privados y los publicara en un pull request. Su propia conclusión es que no es un fallo del código del servidor, sino un problema arquitectónico que se resuelve en el sistema de agentes: credenciales por recurso y por sesión, no un token que lo ve todo.

¿Por dónde empiezo si mi agente ya está en producción?

Por el inventario de herramientas, no por el modelo. Media mañana: cada herramienta con su efecto (lee, escribe o comunica), el alcance real de su credencial y si lo que hace se deshace en cinco minutos. Después, marcar por cada sesión-tipo cuáles de las tres capacidades de la regla de dos están activas y cortar la que menos valor aporte, que casi siempre es la salida: lista blanca de destinos en vez de lista negra. Firma humana sólo en lo irreversible, para que signifique algo.

Fuentes citadas

• Greshake, Abdelnabi, Mishra, Endres, Holz, Fritz — Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection (2023; la línea entre datos e instrucciones y la taxonomía de impactos)
• OWASP — LLM01:2025 Prompt Injection (directa vs. indirecta, siete mitigaciones y la ausencia de métodos infalibles)
• NCSC (Reino Unido) — Mistaking AI vulnerability could lead to large-scale breaches (10 de diciembre de 2025; por qué no es una inyección SQL y qué hacer en su lugar)
• Nasr, Carlini, Sitawarin, Schulhoff y otros — The Attacker Moves Second: Stronger Adaptive Attacks Bypass Defenses Against LLM Jailbreaks and Prompt Injections (2025; doce defensas, tasas de éxito por encima del 90%)
• Willison, S. — The lethal trifecta for AI agents (16 de junio de 2025; y por qué el 95% es un suspenso en seguridad)
• Meta — Agents Rule of Two: A Practical Approach to AI Agent Security (31 de octubre de 2025)
• Beurer-Kellner, Buesser, Creţu, Debenedetti y otros — Design Patterns for Securing LLM Agents against Prompt Injections (2025; los seis patrones y el principio del «imposible»)
• Debenedetti, Shumailov, Fan, Hayes, Carlini y otros — Defeating Prompt Injections by Design (CaMeL; 77% de tareas con seguridad demostrable frente al 84% sin defensa en AgentDojo)
• Debenedetti, Zhang, Balunović, Beurer-Kellner, Fischer, Tramèr — AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents (NeurIPS 2024; 97 tareas y 629 casos de seguridad)
• Zhan, Liang, Ying, Kang — InjecAgent: Benchmarking Indirect Prompt Injections in Tool-Integrated Large Language Model Agents (2024; 1.054 casos, GPT-4 con ReAct vulnerable el 24% de las veces)
• Hines, Lopez, Hall, Zarfati, Zunger, Kiciman — Defending Against Indirect Prompt Injection Attacks With Spotlighting (Microsoft, 2024; de más del 50% a menos del 2%)
• Google Security Blog — Mitigating prompt injection attacks with a layered defense strategy (13 de junio de 2025) y AI threats in the wild: the current state of prompt injections on the web (23 de abril de 2026)
• Aim Security — EchoLeak, CVE-2025-32711 en Microsoft 365 Copilot (11 de junio de 2025; análisis técnico de la cadena en Reddy y Gujral, 2025)
• Invariant Labs — GitHub MCP Exploited: Accessing private repositories via MCP (26 de mayo de 2025)