Imagina que tu asistente de IA resume cada mañana la bandeja de entrada de administración. Un día llega un correo de un desconocido. Tú ni lo abres, pero el asistente sí lo lee, y dentro hay unas líneas escritas para él, no para ti. Eso es la prompt injection indirecta, o inyección indirecta de prompts, y es la variante que más debería preocupar a una empresa que ya usa IA en el trabajo.

Ya expliqué qué es la prompt injection en general. Aquí me centro en la indirecta: de dónde sale, qué casos reales hay y qué se puede hacer para que no te pille con la guardia baja.

◢¿Qué es la prompt injection indirecta?

La diferencia con la directa es quién escribe. En la directa, el atacante teclea en el chat. En la indirecta, el atacante nunca habla con tu IA: deja el mensaje en un sitio donde sabe que tarde o temprano pasará.

◢Ejemplos reales de inyección indirecta

Lo importante no son los detalles técnicos, sino la lección: un producto de una de las mayores empresas del mundo, con filtros específicos contra este ataque, se pudo manipular con un correo.

El estudio de 2023 ya había demostrado ataques parecidos contra el chat de Bing basado en GPT-4 y contra herramientas de ayuda al código, con robo de datos y cambios en el comportamiento de la aplicación.

◢¿Por qué no se arregla con un parche?

Es la pregunta que más se hacen los equipos de TI. En un artículo de diciembre de 2025, el NCSC explica que comparar esto con la inyección SQL es engañoso: aquella se resolvió separando datos e instrucciones, y los modelos de lenguaje actuales no tienen una frontera de seguridad entre ambos. Su conclusión es que quizá nunca se elimine del todo y que hay que reducir su probabilidad y su impacto, no esperar a que desaparezca.

OWASP dice algo parecido: sus medidas reducen el impacto, pero no garantizan la prevención completa.

Tiene una consecuencia práctica. Si un proveedor te promete que su producto "detiene" la prompt injection, pregúntale cómo lo sabe. El NCSC recomienda ser prudente con esas promesas y buscar productos que la reduzcan.

◢¿Qué cambia cuando la IA tiene herramientas?

Todo. Un chatbot que solo responde puede, como mucho, decir algo equivocado. Un agente que lee tu correo, consulta tu CRM y puede enviar mensajes convierte un texto manipulado en una acción real. El NCSC lo resume así: si el modelo puede llamar a herramientas, la inyección tiene el mismo efecto que darle al atacante acceso directo a esas herramientas.

Por eso el riesgo no depende tanto de lo listo que sea el modelo como de lo que le dejas hacer. Es el mismo problema que cuento en agentes de IA con demasiados permisos.

◢¿Cómo se previene la inyección indirecta de prompts?

No hay una medida única. Estas son las que recomiendan OWASP y el NCSC, ordenadas como yo las aplicaría en una empresa:

1. ▹Mínimo privilegio. Un asistente que procesa correos externos no debería tener acceso a herramientas con privilegios. Si solo tiene que resumir, que no pueda enviar. El NCSC recoge una idea sencilla que se ha propuesto en el sector: cuando el asistente lee contenido de alguien, sus privilegios deberían bajar a los de esa persona.
2. ▹Aprobación humana en lo importante. Enviar, pagar, borrar o cambiar permisos requiere que una persona confirme viendo qué se va a hacer exactamente.
3. ▹Marcar y separar el contenido externo. Identificar qué texto viene de fuera ayuda a limitar su influencia, aunque no la elimina.
4. ▹Validar lo que sale. Si el asistente debe devolver un formato concreto, comprobarlo con código normal, no con otro modelo.
5. ▹Registrar todo. El NCSC aconseja guardar las entradas y salidas completas del modelo, el uso de herramientas y las llamadas a APIs. Un intento fallido de usar una herramienta puede ser un atacante afinando su ataque.
6. ▹Probarlo antes. OWASP recomienda tratar al modelo como un usuario no fiable en las pruebas de penetración y simular ataques con documentos preparados.

Una medida que no recomienda el NCSC: bloquear frases conocidas. Se pueden reformular sin fin.

◢Qué puede hacer la plantilla

Quien usa IA a diario también es una barrera. Antes de aceptar lo que propone el asistente, conviene leer qué va a enviar, compartir o borrar y a quién. Un resumen que insiste en algo raro o una acción que nadie pidió son motivo para parar y avisar, igual que con un correo de phishing. Si quieres repasar cómo se reconoce uno, lo expliqué en cómo saber si un correo es phishing.

◢Un riesgo de diseño, no de despiste

La inyección indirecta no la provoca un empleado descuidado. Ocurre aunque todos hagan su trabajo bien, porque el engaño viaja en el contenido que la IA lee. Por eso la defensa pasa por diseñar con la idea de que el asistente puede ser engañado y limitar el daño que pueda hacer.

Es uno de los temas que trabajo en mis formaciones de ciberseguridad e IA para empresas, pensadas para equipos que no son técnicos.