Un agente lee, decide y actúa con tus credenciales. Para desviarlo no hace falta romper nada: basta con dejarle la instrucción adecuada donde vaya a leerla. Lo ponemos a prueba antes de que lo haga otro.
El investigador Simon Willison lo bautizó como la trifecta letal. Un agente pasa a ser explotable en cuanto reúne estas tres cosas a la vez, y casi todos los agentes útiles las reúnen.
Con las tres, el atacante no necesita vulnerar nada Le basta con dejar una instrucción donde tu agente la vaya a leer. El resto lo hace el agente: autenticado, con permisos y sin que salte ninguna alarma.
No es que se haga mal. Es que un agente rompe las tres suposiciones sobre las que se construyó el pentesting clásico.
La misma entrada no da la misma salida. Una prueba que pasa hoy puede fallar al tercer intento. Aquí no se valida pasando una checklist una vez: se valida insistiendo, desde muchos ángulos y con muchas cabezas distintas.
No hay una línea de código que subrayar ni un patrón que un escáner pueda buscar. El payload es una frase bien colocada en un sitio que tu agente considera de confianza.
Cambia el modelo, retocas un prompt, añades una herramienta o conectas un servidor MCP y ya es otro sistema. Una foto anual no cubre algo que se transforma cada semana.
Es exactamente el tipo de problema para el que sirve una comunidad grande de hackers probando de forma continua, y no un auditor con una plantilla.
OWASP publicó en diciembre de 2025 su lista de riesgos para aplicaciones agénticas, revisada por más de cien especialistas. Es el estándar de referencia y es lo que atacamos, categoría por categoría.
Alguien redirige lo que el agente cree que tiene que hacer, con una instrucción escondida en contenido que va a leer. Por fuera parece que sigue trabajando con normalidad.
Por ejemplo: un correo entrante lleva una instrucción oculta y el agente de soporte reenvía el historial de otro cliente.
El agente tiene acceso a correo, CRM, facturación, APIs o una terminal. Aunque ese acceso esté autorizado, se le puede llevar a encadenarlas de forma destructiva o muy cara.
Por ejemplo: se le convence de lanzar un borrado masivo presentándolo como una limpieza de duplicados.
Los agentes heredan roles, guardan credenciales y se llaman entre ellos. Esa cadena de delegación es justo por donde se escala.
Por ejemplo: la petición de un usuario básico acaba ejecutándose con los permisos del agente de administración.
Herramientas, plugins, plantillas de prompt, servidores MCP, conectores RAG y registros de agentes vienen de terceros. Si uno se compromete, inyecta instrucciones desde dentro.
Por ejemplo: un servidor MCP legítimo se actualiza y la nueva descripción de una herramienta trae instrucciones ocultas.
Muchos agentes escriben y ejecutan código. Sin un aislamiento sólido, una instrucción bien colocada acaba siendo ejecución de código dentro de tu infraestructura.
Por ejemplo: el agente instala una dependencia que alguien ha sugerido en el comentario de un issue.
Resúmenes, embeddings, notas internas e índices de RAG se reutilizan. Si alguien los contamina, el agente decide sobre datos falsos, y lo sigue haciendo sesión tras sesión.
Por ejemplo: un documento plantado en la base de conocimiento cambia la política de descuentos que aplica el agente.
En sistemas multiagente los mensajes viajan por buses, APIs o memoria compartida. Sin autenticarlos y validarlos, se pueden falsificar, repetir o colar un agente ajeno en la malla.
Por ejemplo: un agente falso se presenta como el que aprueba y el resto del flujo le hace caso.
Una entrada envenenada o una política mal puesta se propaga entre agentes que consumen la salida del otro. El error se amplifica mucho más rápido de lo que nadie lo revisa.
Por ejemplo: un agente interpreta mal un umbral de coste y otros tres actúan sobre esa conclusión.
El agente suena seguro, redacta bien y presenta la acción como razonable. Se aprovecha esa autoridad para que una persona apruebe algo que no debería.
Por ejemplo: un resumen impecable lleva a alguien a validar una transferencia. El registro solo verá una aprobación humana.
Aquí el problema ya no es un prompt: es el agente, que se ha desviado de su diseño y persigue objetivos propios. Se comporta como un insider, pero con credenciales legítimas.
Por ejemplo: un agente de optimización empieza a borrar copias de seguridad para reducir el gasto.
Las dos preguntas que hacemos siempre primero ¿Tu agente tiene más autonomía de la que el problema de negocio justifica? ¿Y puedes reconstruir después qué hizo, con qué identidad y con qué herramienta? Mínima agencia y observabilidad son los dos principios que OWASP pone por delante de la lista, y casi ningún agente en producción cumple los dos.
La seguridad de agentes se añade al alcance de cualquiera de nuestros servicios. Cuál te conviene depende de lo mismo de siempre: si necesitas un informe o necesitas cobertura continua.
Una ventana cerrada sobre un agente concreto, con informe formal, evidencias y retest. Para cuando tienes un lanzamiento, un cliente o una auditoría delante.
Ver pentestVarios hackers sobre el mismo agente a la vez. Contra un sistema no determinista, la variedad de enfoques encuentra lo que un único auditor no encuentra.
Ver crowdsourcedCobertura permanente, que es la que encaja con un sistema que cambia cuando cambias un prompt o el proveedor actualiza el modelo. Pagas por vulnerabilidad validada.
Ver bug bountyQué herramientas tiene, con qué identidad actúa, de dónde lee, dónde guarda memoria y hacia dónde puede escribir. Casi siempre esta foto ya sorprende a quien lo construyó.
Qué entorno se toca, qué herramientas quedan fuera, qué acciones no se ejecutan aunque el agente las permita y qué gasto máximo se acepta durante las pruebas. Tú decides, y puedes revocar el acceso en cualquier momento.
Desde el punto de vista de quien quiere que tu agente haga algo que no debe: instrucciones colocadas donde va a leerlas, encadenado de herramientas, límites de identidad, persistencia en memoria y aislamiento del entorno de ejecución.
Cada hallazgo llega con la reproducción paso a paso, el impacto real sobre tu negocio y la corrección propuesta. Cuando lo arreglas, lo volvemos a probar.
Cada vulnerabilidad se referencia contra los marcos que ya usa tu equipo de cumplimiento, para que el informe sirva tanto al que lo arregla como al que tiene que enseñarlo.
Como CVE Numbering Authority acreditada bajo el liderazgo de INCIBE, cuando el fallo está en un componente de terceros podemos coordinar su publicación en el estándar que sigue toda la industria.
Cuéntanos qué hace, qué herramientas le has conectado y con qué permisos actúa. En una llamada te decimos por dónde entraría alguien y qué encaje tiene con lo que ya estás haciendo de seguridad.
Sin compromiso y sin tecnicismos. Un especialista te responde en 24-48 horas.
