El día que tu agente tuvo herramientas, el prompt injection pasó a ser un problema de operaciones
Un chatbot al que engañan para que escriba un poema sobre tu competencia es una captura de pantalla en redes sociales. Un agente al que engañan para que envíe tu base de datos de clientes a un desconocido es una notificación de brecha de seguridad. La diferencia entre esos dos incidentes es una sola decisión de arquitectura: le diste herramientas al modelo.
Vengo de operaciones enterprise, donde pasamos años construyendo mínimo privilegio, controles de salida y trazas de auditoría alrededor de cada cuenta de servicio. Lo que veo ahora, revisando despliegues de agentes, es que esos mismos controles se le perdonan sin discusión a la identidad más nueva y menos predecible de la red — porque la demo del agente funcionó, y nadie volvió a revisar el threat model entre la demo y producción. Ya hemos escrito sobre lo que pasa cuando no hay nadie al teclado; este post va del radio de explosión de esa identidad en cuanto se le conectan herramientas.
La industria ya le ha puesto nombre al patrón, y ya tenemos la prueba de que es real. Merece la pena tomarse en serio ambas cosas.
La lethal trifecta: datos privados, contenido no confiable, un canal de salida
En junio de 2025, Simon Willison puso nombre al patrón que convierte un agente en una máquina de exfiltración — la lethal trifecta: acceso a datos privados, exposición a contenido no confiable y capacidad de comunicarse con el exterior. Dos de las tres son manejables. Las tres juntas significan que un solo documento, email o página web envenenados puede ordenar a tu agente que reúna datos sensibles y los saque fuera — sin ninguna vulnerabilidad en tu código, sin credenciales comprometidas, sin que ningún usuario haga clic en nada.
La razón por la que esto es estructural y no un bug: un LLM no tiene una frontera fiable entre instrucciones y datos. Todo lo que entra en la ventana de contexto es, para el modelo, instrucción en potencia. Treinta años de defensas contra inyección — consultas parametrizadas, codificación de salidas — asumen que puedes separar el canal de comandos del canal de datos. Dentro del contexto de un transformer, no puedes. OWASP lleva situando el prompt injection como riesgo #1 de su LLM Top 10 desde que la lista existe, y la razón es esta.
Por eso «hemos endurecido el system prompt» no es un control de seguridad. El entrenamiento en jerarquía de instrucciones y los clasificadores de inyección bajan la tasa de acierto del ataque; ninguno la lleva a cero. Frente a un atacante que puede iterar sin coste contra tu agente expuesto al público, un filtro que para el 99% de los intentos es un retraso, no una defensa.
EchoLeak fue la prueba: cero clics, CVSS 9,3
Si la trifecta suena teórica, EchoLeak (CVE-2025-32711) zanjó la discusión. Divulgada por Aim Security en junio de 2025 y puntuada con un 9,3, era una cadena de exfiltración sin clics contra Microsoft 365 Copilot: un email manipulado con instrucciones ocultas esperaba en la bandeja de entrada de la víctima hasta que Copilot lo procesaba durante el uso normal, momento en el que el asistente recuperaba otro contenido privado del contexto del usuario y lo filtraba hacia fuera a través de recursos auto-descargados. Sin interacción del usuario. Sin malware. La trifecta, montada sobre uno de los productos de IA con más ingeniería detrás de todo el mercado — Copilot lee tu correo (datos privados + contenido no confiable) y renderiza salida enriquecida (canal de salida).
Microsoft lo parcheó en servidor y no se confirmó explotación en la práctica. Pero la lección no va de un producto. Va de que un fabricante al que no le falta presupuesto de seguridad desplegó la trifecta en cientos de millones de puestos, y el arreglo exigió rediseñar fronteras de confianza, no retocar un prompt. Vimos la misma clase de ataque desde el lado del hiring cuando una bio de LinkedIn con una receta de flan incrustada atravesó de punta a punta un pipeline automatizado de selección — otro dominio, misma causa raíz: texto no confiable tratado como instrucción confiable.
No puedes filtrar el ataque, así que acotas la consecuencia
En cuanto aceptas que alguna inyección acabará pasando, la pregunta de ingeniería cambia de «cómo detecto ataques» a «qué puede hacer el agente cuando esté comprometido». Esa pregunta la gente de operaciones ya la ha respondido antes — es el modelo assume-breach, aplicado a un componente que está diseñado para seguir las instrucciones de su entrada. Los controles, en el orden en que yo los implementaría:
Mínimo privilegio por herramienta, no por agente. El agente en su conjunto no recibe un scope; lo recibe cada llamada a herramienta. La tool de retrieval lleva un token de solo lectura acotado a las colecciones que este usuario puede ver. La de email solo envía a dominios internos. La de base de datos usa un rol que no puede tocar tablas con PII. Cuando engañen al agente — y cuenta con que pasará — las instrucciones inyectadas heredan esos límites, y «exfiltra la tabla de clientes» falla por permisos como cualquier otra consulta no autorizada.
Una puerta humana en las acciones irreversibles. Enviar correo externo, mover dinero, borrar registros, mergear código: esas llamadas devuelven una aprobación pendiente, no un resultado. El revisor ve una descripción de una línea antes de que se ejecute. Es aburrido — y convierte una brecha en una petición denegada.
Ejecución en sandbox. Si el agente escribe y ejecuta código, ese código corre en un contenedor desechable, sin credenciales en el entorno y con una lista blanca de salida. La lista blanca ataca directamente la tercera pata de la trifecta: un agente que solo llega a tus propias APIs no tiene adónde exfiltrar nada. El filtrado de salida es higiene de red desde 2005, y neutraliza la capacidad más peligrosa de un agente comprometido.
Marca el input no confiable. Registra qué partes del contexto vinieron de fuera — páginas web, correo entrante, ficheros subidos — y restringe qué llamadas a herramientas pueden seguirlas. Hay varias propuestas de investigación que lo formalizan (patrones de doble LLM, separación de flujo de control y de datos); incluso una versión tosca, como rechazar llamadas de alto privilegio en turnos dominados por contenido web descargado, corta las cadenas de ataque más fáciles.
Tu registro de herramientas es una cadena de suministro
El Model Context Protocol hizo componibles las herramientas — una buena noticia — y de paso creó una clase de dependencia nueva que ningún escáner cubre. Un servidor MCP es código remoto en el que tu agente confía — y su texto de descripción entra en tu ventana de contexto, lo que significa que un servidor malicioso o comprometido puede inyectar instrucciones a través de los propios metadatos antes de que se llame a ninguna herramienta.
Trata el registro como un gestor de paquetes, porque es lo que es: fija versiones de los servidores, revisa qué cambió al actualizar, y usa una lista blanca de servidores que hayas leído en lugar de instalar lo que sugiera el directorio. El ecosistema npm ya nos enseñó qué pasa cuando la confianza en un registro se da por supuesta. No hay motivo para reaprenderlo con componentes que sostienen credenciales vivas.
Qué haría este trimestre si fuera tu CTO
- Mapea tu trifecta. Para cada agente: qué datos privados puede leer, qué contenido no confiable llega a su contexto, qué canales de salida existen. Cualquier agente que reúna las tres es tu prioridad — elimina la pata de la que puedas prescindir.
- Rota las credenciales del agente a tokens acotados por herramienta. Si tu agente se autentica con algo que se parezca a una clave de administrador, este es el trabajo de la semana que más importa.
- Pon una puerta de aprobación en cada herramienta irreversible. Envíos externos, escrituras en producción, pagos. Mide cuántas veces deniega la puerta — ese número son los incidentes que habrías tenido si no existiera.
- Añade una lista blanca de egreso a cualquier entorno donde corra código generado por el agente.
- Audita tus servidores MCP y las descripciones de las tools como dependencias de terceros: fijadas, revisadas, en lista blanca.
La salvedad honesta: la mayoría de despliegues de agentes no se enfrentará nunca a un atacante real, y una herramienta interna sin contenido externo en su contexto puede funcionar con controles más ligeros — ajustar el control a la exposición es el trabajo, no la paranoia máxima en todas partes. Pero «ya añadiremos seguridad cuando importe» tiene un modo de fallo, y EchoLeak muestra qué aspecto tiene: severidad 9,3 y cero clics.
El modelo seguirá instrucciones que no debería. Eso no es un defecto que se parchea; es la hipótesis de trabajo alrededor de la que se hace ingeniería — igual que hacemos ingeniería alrededor del hecho de que los humanos hacen clic en enlaces de phishing. Los agentes no necesitan filtros más listos. Necesitan los controles aburridos y probados bajo los que ya opera cualquier otro sistema con entradas no confiables.
Si estás poniendo agentes en producción y quieres que nazcan dentro de estas fronteras desde el primer día, eso es lo que hacen nuestros AI Operators.
