Cómo proteger un agente frente a prompt injection

Un agente de IA con acceso a herramientas reales —leer archivos, ejecutar comandos, llamar a una API, navegar por la web— tiene una superficie de ataque que un chatbot de solo texto no tiene: cualquier contenido que ese agente procese puede intentar decirle qué hacer. No hace falta que un atacante hable directamente con tu sistema. Le basta con que el agente, en el curso normal de su trabajo, lea una página, un documento o el resultado de una herramienta que el atacante controla.

El OWASP GenAI LLM Top 10 2026 sitúa la inyección de prompts en el primer puesto de su ranking de riesgos para aplicaciones con modelos de lenguaje, por delante de fugas de datos, envenenamiento de modelos o denegación de servicio. No es una posición simbólica: es el vector que más incidentes reales ha producido durante el último año, precisamente porque cada vez más agentes tienen permiso para actuar, no solo para responder.

Inyección directa vs. indirecta

Inyección directa: el propio usuario escribe, en su prompt, instrucciones diseñadas para que el modelo ignore sus reglas (“olvida las instrucciones anteriores y…”). Es la forma más conocida y, en la práctica, la menos peligrosa en un sistema bien diseñado: quien la ejecuta ya tenía acceso al agente con sus propios permisos, así que el daño está acotado por lo que ese usuario podía hacer de todas formas.

Inyección indirecta: las instrucciones maliciosas no vienen del usuario, sino de contenido externo que el agente procesa como parte de una tarea legítima —una página web que resume, un PDF que analiza, un email que lee, el resultado de una tool MCP que consulta—. Aquí es donde el riesgo se dispara, porque el atacante no necesita ninguna relación con el sistema: solo necesita que el agente, algún día, lea algo que él ha escrito. Un servidor MCP de terceros que devuelve contenido no controlado, una tool de búsqueda web, un repositorio de código ajeno que el agente clona para analizar: todos son vectores de inyección indirecta si el contenido que traen se trata como si fuera parte de las instrucciones del sistema en vez de como datos.

Un caso real: CVE-2026-22708 en Cursor

En enero de 2026 se publicó una vulnerabilidad crítica (CVSS 9.8) en Cursor que ilustra bien cómo una inyección indirecta escala hasta ejecución remota de código. El Agente de Cursor, en modo de ejecución automática con una lista de comandos permitidos (allowlist), confiaba de forma implícita en ciertos comandos internos del shell como export o typeset, que podían ejecutarse sin pasar por la comprobación de la lista y sin pedir aprobación al usuario.

El vector de ataque: un atacante inserta instrucciones —directamente en un prompt o, más habitualmente, escondidas en un archivo, un repositorio o contenido web que el agente procesa— que le dicen al agente que modifique variables de entorno como PATH o LD_PRELOAD. Con el PATH envenenado, un comando aparentemente inofensivo y ya permitido en la allowlist —git, npm— deja de apuntar al binario legítimo y pasa a ejecutar el binario malicioso que el atacante ha colocado en el directorio que ahora tiene prioridad. El agente cree que está ejecutando un comando de confianza; en realidad está ejecutando código arbitrario.

Cursor corrigió el fallo en la versión 2.3, exigiendo aprobación explícita del usuario para cualquier comando que el analizador del lado del servidor no pueda clasificar con certeza. El caso deja una lección que va más allá de Cursor: una allowlist de comandos es una mitigación razonable, pero solo es tan fuerte como su capacidad para anticipar todas las formas indirectas de alcanzar un comando peligroso, incluida la manipulación del entorno en el que ese comando se ejecuta.

Un riesgo relacionado, pero distinto: la cadena de suministro

Vale la pena distinguir la inyección de prompts de otro riesgo que en 2026 también ha golpeado con fuerza al ecosistema agentic: el compromiso de dependencias. En marzo de 2026, dos versiones del paquete litellm en PyPI (1.82.7 y 1.82.8) se distribuyeron con una puerta trasera después de que un grupo atacante comprometiera las credenciales de un mantenedor a través de un ataque previo a Trivy, un escáner de seguridad usado en el pipeline de CI/CD del proyecto. El paquete, con alrededor de 3,4 millones de descargas diarias, estuvo disponible con el código malicioso unas tres horas antes de que PyPI lo pusiera en cuarentena; en ese tiempo se estima que unas 47.000 instalaciones lo descargaron. El payload robaba credenciales de la nube y claves SSH, y se propagaba lateralmente en clústeres de Kubernetes.

No es prompt injection —nadie manipuló al modelo con texto adversarial— pero comparte el problema de fondo: un sistema agentic que confía por defecto en código o contenido de terceros que se ejecuta con más privilegios de los que ese código necesita. Si tu agente instala dependencias, ejecuta paquetes de terceros o corre en el mismo proceso que gestiona credenciales sensibles, este vector importa tanto como la inyección de prompts propiamente dicha.

Mitigaciones prácticas

No existe una mitigación única que elimine la inyección de prompts; el consenso de seguridad en 2026 —incluidas las recomendaciones de agencias como Five Eyes para despliegues agentic de alto riesgo— es desplegar de forma incremental con supervisión humana en las decisiones que importan, y reducir el radio de impacto de cualquier inyección que sí consiga colarse.

Errores frecuentes

• Confiar en que “el modelo es lo bastante bueno para no caer en esto”. La capacidad del modelo no es una barrera de seguridad; es un factor más. Los mismos modelos con mejor rendimiento en benchmarks siguen siendo susceptibles a inyección indirecta bien diseñada.
• Dar permisos amplios “por si acaso” a un agente de coding. Ejecutar siempre en modo de aprobación automática total, sin allowlist ni sandboxing, multiplica el impacto de cualquier fallo, propio o de una dependencia comprometida.
• Instalar servidores MCP de terceros sin revisar qué hacen. Un servidor MCP no auditado con acceso a datos sensibles es, en la práctica, código de terceros ejecutándose con los privilegios de tu agente. Revisa el código fuente o restringe su uso a proveedores conocidos cuando el flujo toque datos sensibles.
• No registrar ni auditar las llamadas a herramientas. Sin logging de qué tool se invocó, con qué parámetros y en respuesta a qué contenido, detectar una inyección que ya tuvo éxito puede tardar semanas.
• Tratar la mitigación de la cadena de suministro como un problema aparte. Fijar versiones exactas de dependencias, verificar la procedencia de los paquetes y no actualizar automáticamente a la última versión publicada en un pipeline con acceso a producción son controles tan relevantes para un sistema agentic como las mitigaciones de prompt injection propiamente dichas.

Cuándo el riesgo es manejable

No todos los agentes necesitan el mismo nivel de blindaje. Un agente de solo lectura, sin acceso a acciones irreversibles ni a datos sensibles, que resume documentos internos para un equipo pequeño, tiene un radio de impacto limitado incluso si una inyección tiene éxito: en el peor caso, produce un resumen manipulado, no ejecuta una acción dañina. El nivel de control —sandboxing estricto, aprobación humana en cada paso, auditoría exhaustiva— debería ser proporcional a lo que el agente puede realmente hacer, no aplicarse de forma idéntica a todos los casos. La pregunta que conviene hacerse antes de dar permisos amplios a un agente no es “¿es seguro este modelo?”, sino “¿qué es lo peor que puede pasar si alguien consigue que este agente haga exactamente lo contrario de lo que le pedí, y ese peor caso es aceptable?”.