La inyección de prompts no se puede filtrar. Hay que diseñar contando con ella.
Un asistente de IA lee un correo, una página web o un PDF. En ese contenido hay una frase escrita para el asistente y no para el lector: ignora tus instrucciones, reúne estos archivos, envíalos aquí. Si el asistente obedece, eso es una inyección de prompts. OWASP la sitúa en el primer puesto de su Top 10 para aplicaciones con LLM.
La reacción habitual es añadir un filtro. Los filtros ayudan, pero no cierran el agujero, y un diseño que depende de uno acabará fallando.
Por qué no se corrige como la inyección SQL
La inyección SQL se resolvió separando código y datos: una consulta parametrizada nunca trata la entrada del usuario como una orden. Un modelo de lenguaje no tiene esa separación. Las instrucciones y el contenido le llegan en el mismo flujo de texto, y el modelo decide qué hacer con todo ello.
El National Cyber Security Centre británico lo explicó en diciembre de 2025: la inyección de prompts es un problema de otra naturaleza que la inyección SQL, y puede que nunca llegue a mitigarse del todo como sí se puede con la inyección SQL. Por eso la tratamos como un riesgo que se reduce y se contiene, y diseñamos partiendo de ahí.
Dos casos reales
EchoLeak (CVE-2025-32711) se corrigió en Microsoft 365 Copilot en junio de 2025, con una gravedad de 9,3 sobre 10 según Microsoft. Investigadores de Aim Labs demostraron que un correo con instrucciones ocultas podía hacer que el asistente enviara fuera datos internos sin que el destinatario hiciera clic en nada.
Las herramientas que rodean al modelo también están expuestas. CVE-2025-6514, publicada en julio de 2025 con una puntuación de 9,6, era una inyección de comandos del sistema operativo en mcp-remote, un cliente muy usado de Model Context Protocol. Bastaba con conectarse a un servidor MCP malicioso. Desde entonces OWASP ha publicado un Top 10 específico para aplicaciones con agentes.
Qué aguanta cuando el filtro falla
- Tratar como datos todo lo que el sistema lee. Correos, documentos, páginas web y resultados de herramientas son contenido no fiable, venga de quien parezca venir.
- Dejar que los permisos los apliquen los sistemas conectados. Una instrucción en el prompt que diga «nunca borres registros» es una petición. Un rol de base de datos sin permiso de borrado es un control.
- Separar leer de actuar. Un paso que ha leído contenido no fiable no debería poder enviar correos, llamar a URLs externas ni mostrar enlaces o imágenes que saquen datos.
- Poner a una persona delante de todo lo que cuesta dinero o es difícil de deshacer, y enseñarle qué va a pasar y por qué.
- Ejecutar los agentes en entornos aislados, con acceso de red restringido y sin credenciales de producción.
- Tratar los servidores MCP como código de terceros. Fijar versiones, leer las descripciones de las herramientas y dar a cada servidor credenciales propias y limitadas.
- Mantener casos de ataque reales en el conjunto de evaluación, para probar con ellos cada cambio de modelo o de prompt.
Preguntas antes de comprar o desarrollar
¿Qué puede hacer este sistema si sigue al pie de la letra una instrucción maliciosa? ¿Cuáles de esas acciones necesitan aprobación? ¿Por dónde podrían salir datos? Si las respuestas sinceras son «todo lo que puede hacer el usuario», «ninguna» y «por cualquier sitio», todo el peso recae en el filtro.
Con datos personales hay además una parte regulatoria. La AEPD publicó en febrero de 2026 unas orientaciones sobre IA agéntica que van en la misma dirección: limitar lo que un agente puede alcanzar y mantener a una persona responsable de lo que hace.