Por qué los agentes de IA son vulnerables a la inyección de prompts y cómo protegerlos a nivel de arquitectura

En el software tradicional, arquitectura y seguridad están claramente separadas: existe un perímetro, autenticación, validación de entradas. En los sistemas de IA, esta frontera se difumina hasta el punto de que los enfoques clásicos dejan de funcionar.

El problema clave: los agentes de IA fusionan algo que siempre había estado separado: el plano de control (control plane) y el plano de datos (data plane). En una aplicación normal, un comando del usuario es procesado por código determinista, y los datos no pueden reescribir la lógica. En un sistema LLM, cualquier texto presente en la ventana de contexto puede influir potencialmente en el comportamiento del modelo.

OWASP lo formula así: «Todas las entradas tienen el mismo peso de confianza, y el modelo no puede distinguir internamente las instrucciones confiables de los datos no confiables». Se trata de un cambio arquitectónico que exige integrar la seguridad en el sistema desde cero, en lugar de añadirla como un filtro superpuesto.

Principio 1:

La separación de confianza como primitiva arquitectónica

Muchos arquitectos colocan contenido no confiable, datos internos e instrucciones del sistema en la misma ventana de contexto, asumiendo que el modelo lo resolverá por sí solo. Es un error. La solución consiste en introducir un nivel de confianza explícito para cada fragmento, con una separación de capas forzada.

El sistema no trabaja con cadenas de prompt concatenadas, sino con bloques de contexto tipados. Cada bloque recibe metadatos de procedencia (provenance) y un nivel de confianza: las instrucciones del sistema son trusted, los datos de la base de datos interna son internal, y el contenido externo y los documentos RAG son untrusted. Las herramientas verifican estas etiquetas antes de ejecutar nada.

OWASP llama a esto «segregation of trust» y, en 2026, subraya que ya no se trata solo de una buena práctica, sino de un requisito arquitectónico.

Principio 2: Aislamiento de herramientas y privilegio mínimo

Un error arquitectónico peligroso es otorgar a un LLM acceso a herramientas con permisos excesivos. Puede tratarse de una herramienta de "lectura" capaz en realidad de borrar documentos, o de una conexión a base de datos con privilegios de administrador cuando solo se necesita un SELECT. La solución: asignar a cada herramienta el conjunto mínimo necesario de permisos y un contexto de ejecución aislado.

En lugar de entregar al modelo consultas SQL directas, el sistema recibe parámetros estructurados (tabla, filtros, límite) y construye él mismo la consulta parametrizada. Esto elimina toda una clase de ataques de inyección. Evita funcionalidades abiertas como la ejecución de comandos de shell o peticiones a URLs arbitrarias. Usa herramientas granulares con restricciones: herramientas de archivos que escriben solo en un directorio concreto y con una extensión determinada, herramientas de correo que envían solo a direcciones de una lista blanca aprobada.

Principio 3: Control de la memoria y del corpus RAG

El corpus RAG forma parte de la superficie de ataque, y a menudo resulta más peligroso que el propio prompt. La investigación WARP demostró que es posible inyectar documentos "envenenados" en un corpus de búsqueda, de modo que, al activarse el disparador, el sistema RAG recupere precisamente esos documentos. El estudio AgentPoison tuvo éxito en el 82% de los casos con una tasa de envenenamiento inferior al 0.1%: un solo documento malicioso por cada mil puede ser suficiente.

La defensa implica tres capas: control de procedencia de cada documento, con metadatos y hashes de contenido; aislamiento de los resultados de búsqueda, marcados como untrusted; y monitoreo de desviación (drift), es decir, detectar si la búsqueda empieza a devolver documentos que antes nunca devolvía.

Principio 4:

El human-in-the-loop como componente arquitectónico

No se trata de una función de interfaz con un botón de confirmación, sino de un componente integrado en el runtime. Las acciones se clasifican por nivel de riesgo: LOW (solo lectura, datos internos), MEDIUM (escritura en sandbox, notificaciones internas), HIGH (eliminar, llamadas a APIs externas, operaciones financieras). Las acciones de riesgo HIGH requieren confirmación, y el agente no puede eludirla.

Incidentes reales confirman esta necesidad: CVE-2025-32711 (EchoLeak), una inyección de prompt en Microsoft Copilot con exfiltración de datos zero-click; y CVE-2025-54135 y CVE-2025-54136, ejecución remota de código mediante inyección de prompt en la implementación MCP de Cursor IDE. Todos ellos fueron consecuencia de errores arquitectónicos, no de carencias del modelo.

Esto no trata de hacer que el modelo sea seguro. Se trata de diseñar la seguridad a nivel de la arquitectura del sistema.