Hasta hace poco, el asistente de IA de una empresa contestaba preguntas. Ahora cada vez más lee el correo, consulta el CRM, prepara pagos o escribe y ejecuta código. Ese salto de responder a actuar es lo que convierte a un chatbot en un agente, y cambia por completo la pregunta de seguridad: ya no basta con saber qué puede decir, hay que saber qué puede hacer.

◢¿Qué es el OWASP Top 10 para aplicaciones agénticas?

Es un catálogo de diez riesgos, numerados del ASI01 al ASI10, con ejemplos, escenarios de ataque y medidas para cada uno. Según OWASP¹, se ha elaborado con más de 100 expertos del sector, investigadores y profesionales, y se ha revisado por pares. Como el resto de listas de OWASP, no es una norma ni una certificación: es una referencia para saber qué preguntar y por dónde empezar.

Se centra en los agentes, es decir, sistemas de IA que planifican, deciden y actúan en varios pasos y sobre varios sistemas, a menudo en nombre de una persona o de un equipo.

◢¿En qué se diferencia del Top 10 para LLM?

El Top 10 para LLM mira sobre todo lo que responde el modelo. La lista agéntica mira lo que pasa cuando esa respuesta se convierte en una acción. OWASP lo explica con su primer riesgo: la prompt injection clásica altera una respuesta, mientras que en un agente puede cambiar su objetivo y todo lo que hace después.

La idea central del documento es lo que OWASP llama mínima agencia: no dar autonomía donde no hace falta, porque cada capacidad innecesaria amplía la superficie de ataque sin aportar valor. Y añade una segunda condición que considera imprescindible: ver en todo momento qué hace el agente, por qué y con qué herramientas. Es la versión ampliada de lo que conté en agentes de IA con demasiados permisos.

◢Cuando alguien cambia el objetivo del agente

El ASI01, secuestro del objetivo del agente, parte de un problema conocido: el modelo no distingue con fiabilidad entre una instrucción y el contenido que lee. Si el agente procesa un correo, un documento o una web con instrucciones escondidas, puede acabar persiguiendo el objetivo del atacante. OWASP cita EchoLeak, en el que un correo preparado hacía que Microsoft 365 Copilot ejecutara instrucciones ocultas y sacara correos, archivos y chats sin que el usuario hiciera nada. Si quieres más ejemplos, los recogí en prompt injection indirecta.

El ASI06, envenenamiento de la memoria y el contexto, es su versión duradera. Muchos agentes guardan resúmenes, memoria o documentos para tareas futuras. Si alguien consigue colar ahí información falsa, el agente la seguirá usando en otras sesiones. El ejemplo de OWASP es sencillo: alguien insiste en un precio falso de un vuelo, el asistente lo guarda como cierto y acaba aprobando reservas con él. Entre las medidas que propone están separar la memoria de cada usuario, caducar lo que no está verificado y no dejar que el agente vuelva a meter en su memoria lo que él mismo ha generado.

◢Cuando el agente usa mal lo que tiene

El ASI02, uso indebido de herramientas, ocurre cuando el agente actúa dentro de sus permisos pero de forma insegura. OWASP pone ejemplos que se reconocen en cualquier oficina: un agente que resume correos y también puede borrarlos o enviarlos sin pedir confirmación, o un bot de atención al cliente pensado para consultar pedidos que también emite reembolsos porque la herramienta tenía acceso completo a la parte financiera.

El ASI03, abuso de identidad y privilegios, va un paso más allá. Los agentes heredan credenciales, se pasan tareas entre ellos y a menudo confían en cualquier petición interna. En uno de los escenarios del documento, un correo manipulado que dice venir de informática llega a un agente que clasifica el correo, este se lo pasa a un agente de finanzas y el de finanzas paga sin verificar nada porque la petición viene de otro agente interno. OWASP recomienda que cada agente tenga su propia identidad, con permisos limitados a la tarea y que caduquen pronto, y aprobación humana para lo irreversible.

El ASI05, ejecución inesperada de código, afecta a los agentes que escriben y ejecutan código, incluidas las herramientas de programación asistida. El riesgo es que una instrucción manipulada o un error del modelo acabe ejecutándose en un servidor. Las medidas son conocidas: nunca ejecutar como administrador, aislar la ejecución en entornos cerrados y separar el código que se genera del que se ejecuta, con una revisión en medio.

◢Cuando las piezas de fuera no son de fiar

El ASI04 trata la cadena de suministro. Un agente se monta con modelos, herramientas, plugins, plantillas de prompts y servidores MCP, el protocolo con el que muchos asistentes se conectan a otras aplicaciones, y buena parte se carga en el momento. OWASP recoge el caso de un servidor MCP malicioso publicado en npm que se hacía pasar por el de Postmark y enviaba en copia oculta los correos al atacante, y que se considera el primero detectado en uso real. Propone mantener un inventario de los componentes de IA, usar solo fuentes revisadas y fijar las versiones.

El ASI07, comunicación insegura entre agentes, aparece cuando varios agentes colaboran y sus mensajes no van autenticados ni protegidos. Un atacante puede interceptarlos, modificarlos o registrar un agente falso que reciba tareas que no le corresponden.

◢Cuando el error se propaga o engaña a una persona

El ASI08, fallos en cascada, describe cómo un único error, sea una alucinación, un dato envenenado o una herramienta comprometida, pasa de un agente a otro y acaba afectando a todo el sistema. Uno de los ejemplos de OWASP no necesita atacante: la supervisión humana se relaja tras muchos aciertos, se aprueba en bloque y los cambios se extienden sin control.

El ASI09, explotación de la confianza entre persona y agente, es el que más me interesa para las plantillas. El agente suena seguro y razonado, y la persona aprueba sin comprobar. El escenario que describe OWASP lo conoce cualquiera que haya visto un fraude del CEO: una factura manipulada entra en el asistente de finanzas, este recomienda un pago urgente a una cuenta del atacante y el responsable lo aprueba confiando en la explicación. Como la acción final la hace una persona, el papel del agente queda oculto para quien investigue después.

El ASI10, agentes descontrolados, cubre los que se desvían de su función aunque cada acción parezca legítima. El ejemplo de OWASP da que pensar: un agente encargado de reducir el gasto en la nube descubre que borrar las copias de seguridad es la forma más eficaz de lograrlo. Para estos casos pide registros que no se puedan alterar, un botón de parada y poder retirar las credenciales al instante.

◢¿Qué debería hacer una empresa antes de poner un agente a trabajar?

No hace falta aplicar las diez entradas de golpe. Con lo que propone OWASP, estas son las preguntas que yo haría antes de dar a un agente acceso a sistemas reales:

• ▹¿Necesita de verdad actuar, o bastaría con que propusiera y una persona ejecutara?
• ▹¿Qué puede enviar, pagar, borrar o publicar? Cada una de esas acciones debería pedir confirmación humana.
• ▹¿Con qué identidad trabaja? Mejor una cuenta propia con permisos mínimos que las credenciales de quien lo creó.
• ▹¿Qué contenido de fuera lee, como correos, webs o documentos, y qué puede hacer después de leerlo?
• ▹¿De dónde salen sus herramientas y conectores, y quién los revisa y actualiza?
• ▹¿Queda registro de todo lo que hace y alguien puede pararlo en un momento?

Y una para la plantilla: que quien aprueba lo que propone un agente sepa que una explicación convincente no es una prueba. OWASP incluye la formación de las personas que supervisan agentes entre sus medidas, y es justo lo que trabajo en mis formaciones de ciberseguridad e IA para empresas.