20  Seguridad

La seguridad es siempre un punto clave cuando hablamos de la puesta en producción de los agentes.

Y es un punto incómodo, porque el problema central de estos sistemas no es un fallo de implementación que se pueda parchear. Es una propiedad de cómo funcionan, y hay que diseñar asumiendo que va a seguir ahí.

20.1 El problema de fondo

Un modelo recibe un flujo de tokens. Dentro de ese flujo van nuestras instrucciones, la pregunta del usuario, los documentos recuperados y las respuestas de las herramientas. Todo junto, en el mismo canal, sin ninguna separación estructural entre lo que es una orden y lo que es un dato.

En un sistema clásico, esa separación existe: una consulta SQL parametrizada distingue el código de los valores, y por eso la inyección SQL es un problema resuelto. Aquí no hay parámetros. Hay texto.

flowchart LR
    sp["Instrucciones<br/>del sistema"] --> ctx["Un único flujo<br/>de tokens"]
    usr["Petición del<br/>usuario"] --> ctx
    doc["Documento<br/>recuperado"] --> ctx
    tool["Respuesta de<br/>herramienta"] --> ctx
    ctx --> m["Modelo"]

    classDef contexto fill:#d5e6f5,stroke:#3d7cb0,stroke-width:1.5px,color:#12354e
    classDef externo fill:#ececf0,stroke:#868d9c,stroke-width:1.5px,color:#2b2f3a
    classDef modelo fill:#e6ddf5,stroke:#7457bd,stroke-width:1.5px,color:#332757
    classDef riesgo fill:#f7d9d9,stroke:#b05252,stroke-width:1.5px,color:#5e1f1f
    class sp,ctx contexto
    class usr externo
    class doc,tool riesgo
    class m modelo

En rojo, lo que viene de fuera y puede contener instrucciones. Que es, en un sistema con recuperación y herramientas, casi todo.

20.2 Inyección de prompt

La consecuencia directa de lo anterior. Si un texto que el modelo va a leer contiene algo con forma de instrucción, hay una probabilidad no despreciable de que lo obedezca.

La variante peligrosa no es la directa (un usuario escribiendo “ignora tus instrucciones”, que como mucho se hace daño a sí mismo) sino la indirecta: la instrucción viaja escondida en contenido que el sistema procesa por su cuenta.

  • Un correo entrante que el agente lee para resumir.
  • Un documento del gestor documental que alguien subió.
  • Una página web que el agente consultó.
  • La descripción de una herramienta de un servidor MCP de terceros.
  • Texto blanco sobre fondo blanco en un PDF, o escondido en los píxeles de una imagen para un modelo multimodal.

El usuario legítimo no ve nada raro. El agente sí lo lee, y actúa.

ImportantePor qué no se arregla

Es tentador pensar que basta con un prompt de sistema más firme, o con un filtro que detecte instrucciones maliciosas. Ninguna de las dos cosas cierra el problema:

  • El prompt de sistema es texto en el mismo canal. Compite con la inyección, no la domina.
  • Los filtros son un juego del gato y el ratón que el atacante gana con paciencia: codificaciones, idiomas, sinónimos, instrucciones repartidas en varios documentos.

Los filtros suben el listón y merecen la pena, pero la mitigación real es arquitectónica: limitar lo que el sistema puede hacer aunque esté comprometido. De eso va el siguiente capítulo.

20.3 La trifecta letal

La formulación más útil que conozco para decidir si un diseño es peligroso se debe a Simon Willison (Willison 2025). Un agente es explotable cuando reúne tres propiedades a la vez:

  1. Acceso a datos privados (vuestros documentos, vuestra base de datos, el correo).
  2. Exposición a contenido no confiable (cualquier texto que no hayáis escrito vosotros).
  3. Capacidad de comunicarse hacia fuera (enviar un correo, llamar a una API, incluso cargar una imagen desde una URL).

flowchart TD
    a["Datos privados"] --> x["Exfiltración"]
    b["Contenido no confiable"] --> x
    c["Canal de salida"] --> x

    classDef riesgo fill:#f7d9d9,stroke:#b05252,stroke-width:1.5px,color:#5e1f1f
    classDef contexto fill:#d5e6f5,stroke:#3d7cb0,stroke-width:1.5px,color:#12354e
    class a contexto
    class b,c,x riesgo

Con las tres, una instrucción escondida en un documento puede hacer que el agente lea datos privados y los mande fuera. Y el canal de salida es más ancho de lo que parece: no hace falta una herramienta de envío de correo si el agente puede escribir una imagen en Markdown, porque la URL de esa imagen es un canal de exfiltración perfectamente funcional.

La regla práctica que se ha ido imponiendo es la regla de dos: un agente sin supervisión debería tener como mucho dos de las tres. Cuando el caso de uso necesita las tres, hace falta una persona aprobando la salida.