Despliegue seguro y salida del modelo
Qué puede hacer un modelo cuando una inyección llega a pasar. Mínimo privilegio, la trifecta letal con casos reales (Slack AI, EchoLeak, Cursor), manejo inseguro de la salida (LLM05) y diseños que dan garantías.
Aun con guardrails, algunos ataques pasarán. Los controles de despliegue hacen otra pregunta: cuando eso ocurra, ¿qué puede hacer el modelo con ello?
Los casos reales de inyección indirecta no triunfaron por ser ingeniosos, sino porque el sistema tenía acceso a mucho más de lo que cualquier tarea legítima necesitaba. Una inyección que cae en un despliegue muy acotado es una molestia; la misma inyección en uno con privilegios de sobra puede ser una filtración de datos o una ejecución de código.
Mínimo privilegio#
El mínimo privilegio es un principio de base: cada componente tiene solo los permisos que necesita. Aplicado a la inyección de prompt, determina el radio de impacto cuando el ataque funciona. Cada permiso que no concedes es una capacidad que el atacante no puede explotar, por buena que sea su inyección.
En la práctica:
- Herramientas con alcance mínimo (de solo lectura si basta, con parámetros acotados) y credenciales de vida corta.
- Recuperación (RAG) limitada a lo que el usuario que pregunta puede ver, no a todo el corpus. Así, un asistente no se convierte en un atajo para leer lo que otro usuario no tiene permiso de leer.
- La frontera entre «instrucciones» y «datos» no es solo un patrón de prompt: se impone en la arquitectura, en cómo se acota la recuperación, cómo entra el contenido externo y sobre qué se permite actuar. Ver identidad y autorización de agentes.
La trifecta letal#
Restringir permisos es necesario, pero no basta para casos como Slack AI, y conviene entender por qué. Ahí la víctima sí tenía acceso a su canal privado; el problema no fue que el asistente leyera más de lo permitido. Un agente es explotable en la práctica cuando reúne tres cosas a la vez, la llamada trifecta letalTrifecta letalCombinación peligrosa en un agente: acceso a datos privados, exposición a contenido no confiable y capacidad de comunicar hacia el exterior; con las tres, una inyección puede exfiltrar datos.:
- Lee datos privados.
- Lee contenido no confiable que controla un tercero.
- Puede comunicar hacia fuera (pintar un enlace o una imagen, enviar un correo, hacer una petición).
Paso 1 de 4① Datos privados
El asistente puede leer información sensible del usuario: canales privados, correos, ficheros. Es legítimo y es lo que lo hace útil. Hasta aquí no hay ataque.
Con las tres, el atacante no necesita acceso a nada: planta una instrucción y espera a que el asistente de otro la ejecute con los datos de esa persona. Quitar una pata corta la cadena.
Casos reales#
En agosto de 2024, PromptArmor demostró que un mensaje plantado en un canal público podía hacer que Slack AI, ante la consulta de otro usuario, construyera un enlace Markdown con datos de un canal privado (por ejemplo, una clave de API) en la URL. La cobertura de The Register cuenta que Slack respondió al principio que el comportamiento era «intencionado», porque los mensajes de canales públicos son buscables por diseño, y publicó un parche después.
Pata que se corta: la salida (no pintar enlaces con datos hacia dominios externos) o aislar el contenido ajeno del privado.
CVE-2025-32711, un fallo «zero-click» en Microsoft 365 Copilot con CVSS 9.3, corregido en el Patch Tuesday de junio de 2025. Un correo con instrucciones ocultas entra en el contexto de Copilot a través de Microsoft Graph cuando el usuario hace preguntas rutinarias; después los datos salen incrustados en enlaces o imágenes y esquivan la política de seguridad de contenido a través de un proxy de confianza de Teams (resumen). Microsoft no encontró evidencia de explotación real.
Pata que se corta: la salida (referencias externas y proxies de confianza) y el aislamiento del contenido no confiable.
CVE-2025-54135 («CurXecute»). Cursor se ejecuta con los privilegios del desarrollador; con un servidor MCP que trae datos no confiables, esos datos podían redirigir el control del agente. El mecanismo concreto fue que se podían escribir ficheros dentro del espacio de trabajo sin aprobación del usuario, y así crear un .cursor/mcp.json nuevo y lograr ejecución de comandos (Tenable, The Hacker News). Las puntuaciones CVSS difieren entre fuentes (8,5 a 9,8), y el aviso del vendedor es la referencia sobre la versión corregida.
Pata que se corta: la acción (aprobación humana para escrituras de configuración) y los privilegios del agente.
Manejo inseguro de la salida (LLM05:2025)#
Casi toda integración asume que la respuesta del modelo es el final del camino: generar, mostrar, listo. Pero esa salida va a alguna parte: se renderiza en un navegador, se pasa a una consulta, se entrega a una función, se incrusta en una plantilla de correo. Si llega sin sanear, la respuesta del modelo se vuelve ejecutable en el contexto que la recibe. El atacante no necesita romper tu infraestructura; le basta manipular al modelo para que genere una carga en la que tus sistemas confían. OWASP lo llama Improper Output Handling (LLM05:2025), y las consecuencias son vulnerabilidades clásicas por un camino nuevo:
| La salida del LLM acaba en… | Resultado |
|---|---|
| JavaScript renderizado en el navegador | XSS |
| SQL ejecutado sin parametrizar | Inyección SQL |
exec() o funciones de shell |
Ejecución remota de código |
| Una URL o imagen renderizada | Exfiltración de datos |
Es el trabajo de la capa de guardia de salida. En la práctica: trata la salida del modelo con la misma postura de confianza cero que la entrada de un usuario. Valida la estructura, sanea el contenido, codifica antes de renderizar, usa consultas parametrizadas y aplica esquemas estrictos a las llamadas a herramientas para rechazar lo inesperado antes de ejecutarlo.
Diseños que dan garantías#
Los controles anteriores reducen el riesgo de forma probabilística. Un camino distinto es diseñar para que la inyección no pueda afectar a lo importante. CaMeL (Google DeepMind y ETH Zúrich) separa el flujo de control de los datos: un modelo planifica a partir de la petición del usuario y otro, sin herramientas, procesa el contenido no confiable, de modo que ese contenido nunca altera el programa. Además hace cumplir políticas sobre las llamadas a herramientas. En AgentDojo resolvió el 77 % de las tareas con garantías de seguridad frente al 84 % de un sistema sin defensa, y en las pruebas con Claude 3.5 Sonnet ningún ataque de 949 tuvo éxito. Son resultados sobre ese conjunto de ataques, no una prueba de que ninguna inyección funcione, y cuestan algo de utilidad.
Es la misma idea de las notas anteriores llevada a la arquitectura: no confiar en que el modelo lo haga bien, sino quitarle la capacidad de hacerlo mal.
Resumen#
- Asume que algo pasará y limita lo que el modelo puede hacer.
- La trifecta letal (datos privados, contenido ajeno y salida al exterior) es la configuración explotable; quita una pata.
- Recuperación acotada al usuario evita el atajo entre usuarios; no sustituye a cortar la salida ni a aislar el contenido ajeno.
- La salida del modelo es entrada no confiable para el siguiente sistema (LLM05).
- Los diseños que separan control y datos (CaMeL) dan garantías que los filtros no dan.
Tu turno
Tu turno
Revisa un agente que conozcas y márcale las tres patas: ¿qué datos privados lee, qué contenido ajeno entra a su contexto y por qué canales puede enviar algo fuera (enlaces, imágenes, correo, HTTP, herramientas)? ¿Qué pata sería más barata de cortar?
Reto
Pista
▸Mostrar solución
Suele ser la salida: dejar de renderizar imágenes y enlaces a dominios no aprobados, o exigir confirmación humana antes de cualquier envío al exterior, cuesta poco y no afecta a la mayoría de las tareas legítimas.