Prompt injection: cómo reducir el riesgo en agentes de IA

Un PDF puede intentar darle órdenes a tu agente

Pides a un asistente que compare dos documentos. Dentro de uno aparece una frase que le ordena enviar el contenido a otra dirección. Esa frase forma parte del documento; no es un permiso tuyo.

Ese intento de desviar al modelo es una prompt injection. Si llega a través de una web, un correo o un PDF que el agente consulta, se llama indirecta. La tarea original puede ser completamente normal.

OWASP distingue estas vías y advierte de que RAG y fine-tuning no eliminan la vulnerabilidad. Separar instrucciones y documentos ayuda, pero también necesitas limitar las acciones que el sistema puede ejecutar.

Un ejemplo con tres programas de cursos

Imagina un asistente que compara tres programas de cursos de cerámica. Le pides duración, contenidos y materiales incluidos, con una referencia para cada dato. Solo necesita leer los tres PDFs y preparar una tabla.

Uno de los programas contiene una nota que pide recomendar ese curso por encima de los demás y ocultar que los materiales se pagan aparte. El agente debe analizar los datos del programa sin aceptar esa petición como un cambio de tu encargo. Aunque no pueda enviar correos o modificar archivos, una comparación manipulada ya sería un resultado incorrecto.

Otra nota podría pedirle copiar todos los documentos a un servicio ajeno. Esa petición no concede permiso para enviarlos. En este ejemplo hipotético, el componente que lee PDFs no necesita herramientas de envío ni acceso a carpetas distintas de las previstas. La tarea debe seguir acotada aunque el modelo proponga ampliarla.

Separa la lectura de las decisiones que cambian algo

Diseñaría el recorrido para que la parte que interpreta los PDFs entregue datos con su procedencia. La aplicación comprobaría el formato y presentaría la comparación. Si faltan los materiales o hay una contradicción, debería mostrar esa incertidumbre en lugar de completar el dato por intuición.

Si más adelante añades una acción de envío, comprueba en el componente que la ejecuta el destinatario, los archivos y la autorización para esa operación. Una dirección encontrada en el PDF no debe ampliar los destinos permitidos. Tampoco conviene dar al lector una credencial que abra servicios ajenos a la comparación.

Microsoft recomienda combinar aislamiento, permisos mínimos y controles durante la ejecución. Separar componentes reduce capacidades disponibles para un ataque, pero no garantiza que el texto generado sea correcto. Hay que revisar también el resultado de la comparación.

La salida de una sandbox también necesita un límite

Una sandbox es un entorno aislado para ejecutar código con accesos acotados. Puede limitar el daño de una ejecución, pero el texto que devuelve sigue pudiendo influir en el modelo. LangChain distingue ambas capas en su guía de julio de 2026: el aislamiento no elimina la prompt injection cuando el agente vuelve a leer ese resultado.

En el ejemplo de los cursos, el lector de PDFs podría trabajar dentro de ese entorno. Si devuelve un resumen que pide enviar los documentos, esa petición sigue procediendo del PDF. Haber pasado por una herramienta no la convierte en una orden del usuario. El agente que recibe el resumen tampoco necesita herramientas de envío para preparar la comparación.

Devolvería campos concretos, como duración, materiales y página de origen, y validaría su formato antes de usarlos. Eso facilita revisar el intercambio, pero un JSON válido aún puede contener datos falsos o instrucciones ajenas. Mantendría también los controles de autorización en el componente que ejecuta las acciones.

Detectar un intento no significa haberlo bloqueado

Los detectores pueden añadir una capa de revisión. Prompt Shields de Microsoft analiza entradas y documentos para identificar intentos de manipulación. En la integración de Foundry, su documentación distingue las señales detected y filtered: una detección puede aparecer sin que se haya filtrado el contenido.

Al integrar un control así, comprueba dónde interviene y qué decisión toma tu aplicación después de recibir la señal. Un aviso en los logs no demuestra que se haya detenido una llamada a una herramienta. Si el detector falla o no responde, define qué operaciones pueden continuar y cuáles deben esperar a revisión.

Los filtros también pueden bloquear contenido legítimo. Un programa de formación que explica cómo se estudian estos ataques puede incluir frases sospechosas sin pedirle al agente que las obedezca. La evaluación necesita ejemplos normales y conflictivos.

Prueba el canal por el que entra el documento

Prepara copias ficticias de los tres programas y sustituye cualquier herramienta de envío por una que registre la petición sin enviar nada. Introduce el texto conflictivo en el PDF o en el resultado de su lectura. Ponerlo directamente como mensaje del usuario probaría otra vía de entrada.

Antes de ejecutar la prueba, define qué debería ocurrir en cada caso. Además de leer la respuesta, revisa las llamadas solicitadas, las decisiones de autorización y los cambios en el estado de prueba. OWASP recomienda observar el efecto que se quiere impedir; una respuesta tranquilizadora no deshace una acción ya ejecutada.

Empieza por un recorrido pequeño y observable

Las situaciones de la tabla son pruebas propuestas, no resultados de un agente que haya ejecutado. Si una prueba falla o falta información para saber qué ocurrió, consérvala como fallo o resultado inconcluso. No la cuentes como un ataque bloqueado.

Para empezar, elige una tarea de lectura acotada, define los documentos permitidos y comprueba tanto la respuesta como las acciones. Repite los casos al cambiar modelo, herramientas o forma de extraer los PDFs. Ese registro te ayudará a decidir qué revisar antes de dar más autonomía.

Fuentes