OWASP 2026 y agentes de IA: cómo convertir el Top 10 en controles empresariales reales

Los agentes de IA añaden una capa nueva a la seguridad de aplicaciones generativas. Ya no solo producen texto: pueden recuperar información, consultar sistemas, utilizar herramientas, recordar contexto y preparar o ejecutar acciones. OWASP actualizó en 2026 su Top 10 para aplicaciones LLM y publicó el Agent Control Standard, dos referencias útiles para revisar esta nueva superficie. El Top 10 incluye prompt injection, divulgación de información sensible, vulnerabilidades de cadena de suministro, envenenamiento de datos y modelos, manejo inadecuado de salidas, agencia excesiva, filtración de system prompts, debilidades de vectores y embeddings, desinformación y consumo sin límites. Para una empresa, el valor no está en memorizar la lista, sino en traducir cada riesgo relevante a una decisión de arquitectura, permisos, validación y observabilidad.

1. Prompt injection: el problema no termina en el cuadro de chat

Prompt injection puede llegar directamente desde un usuario o indirectamente desde contenido que el agente recupera: una web, un PDF, un correo, un ticket o un documento interno. Un atacante puede intentar introducir instrucciones que compitan con la política real del sistema. En un agente con herramientas, el riesgo aumenta porque una instrucción maliciosa puede intentar transformar una respuesta incorrecta en una acción.

La defensa debe asumir que el modelo puede ser persuadido. Por eso los límites críticos no deberían depender únicamente del texto del system prompt. El servidor puede verificar organización, usuario, herramienta, acción, recurso y nivel de riesgo antes de cada llamada. Las entradas recuperadas deberían separarse de instrucciones de sistema, y los resultados de herramientas deben volver al modelo como datos, no como autoridad. El objetivo no es prometer que la inyección desaparece, sino evitar que una inyección pueda elevar permisos.

• No confíes en contenido recuperado por ser interno o estar en un PDF.
• Nunca permitas que un documento cambie permisos de herramienta.
• Revalida autorización en cada acción sensible.

2. Información sensible: secretos fuera del prompt y salidas con redacción

Un agente necesita credenciales para acceder a sistemas, pero el modelo no necesita conocer esas credenciales. Las claves API, tokens y secretos deberían permanecer en una capa de servidor y ser resueltos por el runtime cuando una herramienta autorizada se ejecuta. Incluir secretos directamente en prompts o contexto aumenta la posibilidad de que aparezcan en logs, errores o respuestas.

La misma disciplina se aplica a los resultados. Una herramienta puede devolver más información de la necesaria, incluidos identificadores internos, datos personales o campos sensibles. Antes de entregar el resultado al modelo conviene limitar volumen, seleccionar campos permitidos y aplicar redacción cuando corresponda. Minimizar datos reduce exposición y también mejora el contexto útil del modelo.

3. Supply chain: modelos, conectores, plugins y librerías también forman parte del riesgo

Un agente moderno depende de muchas piezas: proveedor de modelo, SDK, librerías, embeddings, bases vectoriales, conectores SaaS, colas, herramientas internas y paquetes de terceros. Una debilidad en cualquiera de esas capas puede afectar al sistema aunque el prompt esté bien diseñado. El inventario de dependencias debe incluir versiones, responsables, procedencia y actualización.

Las herramientas del agente también son parte de la cadena de suministro. Un conector puede cambiar su API o ampliar su respuesta; una librería puede introducir una dependencia vulnerable; un proveedor puede modificar comportamiento. Versionar contratos, limitar campos aceptados y probar integraciones reduce el riesgo de que un cambio externo amplíe silenciosamente lo que el agente puede hacer.

4. Data/model poisoning: protege la fuente antes de confiar en el contexto

Cuando un agente utiliza RAG o conocimiento interno, la calidad de la respuesta depende de las fuentes que ingiere. Un documento manipulado, una nota errónea o una fuente comprometida puede introducir información persistente que después parece legítima porque proviene del repositorio corporativo. La ingestión debe conservar procedencia, propietario y estado para que una respuesta pueda rastrearse hasta su origen.

La corrección también debe ser posible. Si una fuente se elimina o se actualiza, el índice debe reflejar el cambio. Los equipos necesitan controles para reindexar, retirar contenido y evitar que documentos de una organización aparezcan en otra. La trazabilidad del conocimiento es una defensa práctica porque permite investigar por qué el agente creyó algo.

5. Improper output handling: una respuesta del modelo no es una instrucción de sistema

Un error común es tomar texto generado por el modelo y pasarlo directamente a un intérprete, consulta, plantilla o API. Aunque el contenido parezca estructurado, debe tratarse como entrada no confiable. Si una herramienta espera JSON, el sistema debería validar tipos, longitudes, enums y campos permitidos antes de usarlo. Si la salida se renderiza como HTML, se aplican controles propios de esa superficie.

El mismo principio evita que el modelo genere consultas arbitrarias, comandos de shell o código que se ejecute automáticamente. En lugar de dar acceso a una interfaz abierta, el agente debería llamar funciones estrechas y versionadas. Una herramienta para cambiar el estado de un ticket es más controlable que una herramienta genérica para ejecutar cualquier petición contra el backend.

6. Excessive agency: el agente solo debe tener la capacidad que necesita

La categoría de agencia excesiva encaja especialmente bien con sistemas que pueden actuar. Si un agente dispone de permisos de escritura cuando solo necesita lectura, o si una credencial permite administrar todo el sistema para una tarea muy concreta, el impacto de un fallo aumenta innecesariamente. Mínimo privilegio significa diseñar herramientas para el caso de uso, no reutilizar credenciales omnipotentes por comodidad.

READ, DRAFT y EXECUTE ayudan a hacer esa reducción explícita. Un flujo puede comenzar permitiendo lectura y borradores con aprobación. Después, si existe evidencia suficiente, una acción muy concreta puede pasar a EXECUTE. La decisión debe ser por herramienta y acción, no por agente completo. Así es posible automatizar una parte estable del proceso sin abrir todas las demás.

7. System prompt leakage: no uses el prompt como caja fuerte

Un system prompt puede contener instrucciones operativas, pero no debería almacenar secretos ni controles que solo funcionen mientras permanezcan ocultos. Si una regla es crítica, debe existir también como política de servidor. Si una clave es sensible, debe vivir en un gestor de secretos o referencia de credencial. Diseñar como si partes del prompt pudieran hacerse visibles reduce dependencia de la ocultación.

Esto no significa publicar instrucciones internas. Significa asumir que la confidencialidad del prompt no es una frontera suficiente. Las reglas de autorización, los límites de recursos y las listas de herramientas asignadas deben poder seguir protegiendo el sistema incluso si el modelo revela parte de sus instrucciones.

8. Vectores, embeddings y RAG necesitan aislamiento por organización

Los sistemas de recuperación añaden otra frontera: chunks, embeddings, índices y filtros. Un error de filtrado puede permitir que una consulta recupere contenido de otro tenant. Por eso el aislamiento debe aplicarse antes de que los resultados entren en el contexto del modelo. La organización, el usuario y las fuentes asignadas al agente forman parte de la consulta autorizada.

También conviene limitar número y tamaño de fragmentos y registrar qué fuentes se utilizaron. Cuando una respuesta importante cita conocimiento interno, el usuario debería poder rastrear su procedencia. La seguridad y la utilidad convergen: una respuesta con referencias verificables es más fácil de revisar y también más fácil de investigar si algo falla.

9. Misinformation y unbounded consumption: calidad y coste también son controles

Un agente puede responder con confianza aunque la información sea incorrecta. Para tareas con impacto, la arquitectura debería favorecer fuentes autorizadas, referencias, límites de confianza y escalado cuando faltan datos. Un flujo que permite a una persona revisar un borrador antes de enviarlo controla tanto riesgo operativo como desinformación.

El consumo sin límites también importa. Bucles de herramientas, contextos enormes, reintentos infinitos o consultas sin paginación pueden aumentar coste y carga de sistemas. Cada herramienta debería definir timeout, límites de resultado, paginación y tasa. Los runs del modelo necesitan límites de reintento y estados de fallo controlados. Un agente seguro también debe poder detenerse.

10. Agent Control Standard: convierte la gobernanza en runtime

El Agent Control Standard publicado por OWASP en septiembre de 2026 propone una base abierta para visibilidad y control de agentes. Su enfoque parte de que las organizaciones necesitan saber qué agentes existen, a qué pueden acceder, qué acciones realizaron y por qué. También plantea puntos de control donde las políticas pueden aplicarse durante la ejecución.

Para un equipo de producto, la traducción práctica es clara: herramientas registradas, versiones, esquemas, riesgo, roles, credenciales y auditoría deben ser datos del sistema, no conocimiento informal disperso. Cuando una política cambia, el runtime debe poder aplicarla sin reescribir cada prompt. Este enfoque hace que el gobierno del agente sea más mantenible y reduce dependencia del comportamiento probabilístico del modelo.