OWASP LLM Top 10 (2025): qué riesgos soluciona realmente una pasarela

Qué es realmente el OWASP LLM Top 10

El OWASP Top 10 para aplicaciones de modelos de lenguaje de gran tamaño es una lista de consenso sobre los riesgos de seguridad más críticos en el software impulsado por LLM, mantenida por el proyecto OWASP GenAI Security. La versión actual es la lista de 2025 disponible en genai.owasp.org/llm-top-10. La lista v1.1 de 2023/24 todavía está archivada allí y se sigue citando ampliamente; por lo tanto, si una publicación menciona el robo de modelos (Model Theft) o la dependencia excesiva (Overreliance), está describiendo la versión retirada.

La lista de 2025 tal como la publica OWASP:

Los cambios reflejan dónde se ha desplazado la atención. System Prompt Leakage y Vector and Embedding Weaknesses son nuevos. Model Denial of Service ha pasado a ser el concepto más amplio de Unbounded Consumption. Insecure Plugin Design se ha integrado en la cadena de suministro y en la agencia excesiva a medida que la gestión de herramientas se ha estandarizado en torno a protocolos como MCP. Model Theft ha desaparecido por completo.

Dónde reside realmente cada control

Esta es la parte que la mayoría de los análisis omiten. El Top 10 enumera riesgos, y un riesgo no es una función de un producto. Cuatro pertenecen a la ruta de inferencia, donde se ubica una pasarela. Tres pertenecen al código de la aplicación. Tres pertenecen a canalizaciones que una pasarela nunca ve.

Cuatro están directamente dentro del alcance, tres de forma parcial y tres requieren un responsable en otra parte. Si su marco de seguridad de IA incluye una fila de pasarela para LLM04 y LLM08, esa fila es puramente decorativa.

Una pasarela cubre adecuadamente LLM01, LLM02, LLM06 y LLM10 porque los cuatro son problemas de la ruta de solicitud: ocurren en el momento en que se envía una instrucción o se activa una herramienta, que es el único momento que ve una pasarela. El resto se decidió semanas antes, en una ejecución de entrenamiento o en un trabajo de indexación.

Dónde se equivocan los equipos

Tratar la lista como una lista de verificación de cumplimiento. OWASP publica una taxonomía de riesgos con guías de mitigación, no una certificación. No existe una auditoría del OWASP LLM Top 10 ni un organismo que emita una aprobación. Una matriz que afirme que una sola herramienta "cubre" los diez puntos está diseñada para superar una reunión, no un ataque.

Colocar la validación de la salida en el lugar equivocado. LLM05 trata sobre lo que hace su aplicación con el resultado del modelo. Una pasarela puede detectar que una respuesta contiene os.system o una etiqueta de script sin escapar. No puede evitar que su servicio pase esa cadena a un intérprete de comandos (shell). El control pertenece al lugar donde se consume el resultado; la comprobación en la pasarela es defensa en profundidad.

Asumir que la detección de inyecciones equivale a su prevención. La detección es un clasificador, los clasificadores tienen falsos negativos y los atacantes iteran contra ellos. La mitigación duradera para LLM01 consiste en asumir que la inyección ocasionalmente tendrá éxito y hacer que el sistema sea capaz de sobrevivir a ello, lo cual es en realidad un problema de LLM06. Al reducir la superficie de herramientas disponibles, una inyección exitosa solo alcanza a un modelo que no tiene funciones peligrosas que ejecutar.

Ignorar el LLM10 como un mero asunto de facturación. Un agente atrapado en un bucle representa una denegación de servicio contra su propio presupuesto, y las consultas de alto volumen son el método utilizado para la extracción de modelos. Es la entrada más fácil de cerrar y la que con mayor frecuencia se deja abierta.

¿Desea comprobar cuáles de estos riesgos puede cerrar hoy mismo?

Asocie un grupo de guardrails a un solo modelo y observe cómo se ejecutan en Request Traces.

Empiece gratis

Cómo funciona esto en TrueFoundry

La pasarela de IA de TrueFoundry implementa estos controles como barreras de seguridad (guardrails) en los puntos de enlace (hooks) de la ruta de solicitud. Hay cuatro, y los riesgos que puede abordar dependen de en qué hook se encuentre.

Para solicitudes de LLM: input, antes de que el prompt llegue al modelo, y output, después de que responda.

Para llamadas a herramientas MCP: mcp_pre_tool, antes de que se ejecute la herramienta, y mcp_post_tool, después de que devuelva el resultado.

Esos hooks de MCP hacen abordable la cuestión de owasp mcp. Los guardrails se ejecutan en cada llamada a herramienta de forma independiente; cinco herramientas seguidas significan cinco conjuntos de comprobaciones. Un fallo en pre-tool evita que la herramienta se ejecute; un fallo en post-tool retiene el resultado.

Cada guardrail tiene un modo de operación (validate inspecciona y puede bloquear, mutate también reescribe) y una estrategia de aplicación (enforcement strategy) que cubre las infracciones y los errores del guardrail:

LLM01: Prompt Injection

El guardrail integrado de Prompt Injection funciona con la tecnología de Azure Prompt Shield y es gestionado por TrueFoundry, sin necesidad de claves de terceros. Analiza la instrucción del usuario y cualquier documento o contenido de contexto por separado, de modo que una inyección indirecta oculta en un documento recuperado se detecta junto con un intento directo de "ignorar todas las instrucciones anteriores". Solo en modo validate. Añádalo desde la sección Guardrails:

Se ejecuta en LLM Input y MCP Pre Tool, donde busca inyecciones dentro de los parámetros de las herramientas. Para utilizar sus propias credenciales de proveedor, AWS Bedrock Guardrails realiza la misma función: active Prompt Attack, establezca la acción en Block y regístrelo:

LLM02: Sensitive Information Disclosure

Dos componentes integrados cubren la mayor parte de este aspecto. PII / PHI Detection identifica nombres, direcciones, números de seguro social y números de expedientes médicos con categorías de entidades configurables. Secrets Detection detecta claves de AWS, claves de API de OpenAI y Anthropic, tokens de GitHub y GitLab, JWT, claves privadas, cadenas de conexión a bases de datos y cadenas de alta entropía cerca de palabras clave como api_key.

Secrets Detection es el control clave que conviene comprender: es el único componente integrado que se ejecuta en los cuatro hooks, y cada uno ataja un fallo diferente.

Se ejecuta dentro de la pasarela sin llamadas a API externas y, en modo mutate, reemplaza las coincidencias con texto configurable, ***REDACTED*** de forma predeterminada. Para PII en implementaciones autoalojadas, Azure PII con su propia clave, Presidio a través de un guardrail personalizado o el filtro de Bedrock son opciones válidas.

LLM06: Excessive Agency

Aquí es donde los hooks de MCP demuestran su valor. SQL Sanitizer detecta operaciones DROP, TRUNCATE, DELETE o UPDATE sin una cláusula WHERE, así como la interpolación de cadenas. Code Safety Linter marca el uso de eval, exec, os.system, llamadas a subprocess y comandos de shell peligrosos. Cedar y OPA aplican políticas granulares de denegación por defecto a las llamadas de herramientas MCP.

Por debajo se encuentra el modelo de acceso, que representa la parte más importante de LLM06: se pueden desactivar herramientas para que nunca aparezcan en tools/list, las llamadas sensibles pueden requerir un aprobador de servidor MCP (MCP Server Approver), y el uso de OAuth por usuario permite que el sistema ascendente evalúe los permisos reales del usuario en activo en lugar de depender de un token compartido. Nuestra publicación sobre control de acceso en MCP cubre esa capa en detalle.

LLM10: Unbounded Consumption

No se trata de un guardrail en absoluto: es la configuración de límites de tasa (rate limiting) y presupuesto, y representa la cobertura más completa de la lista. Las reglas coinciden por sujeto, modelo o metadatos y limitan las solicitudes o tokens por minuto, hora o día:

rate_limit_applies_per admite user, virtualaccount, model o metadata.* (hasta dos por regla), de modo que cada entidad obtiene su propio contador en lugar de competir por uno compartido. Su aplicación utiliza una ventana deslizante; si se supera un límite, se devuelve un código HTTP 429 con un encabezado x-tfy-applied-rules que indica la regla aplicada:

El resto

LLM09 Misinformation se puede abordar parcialmente a través de proveedores externos: Patronus AI y Fiddler ofrecen evaluadores de alucinación y fidelidad de respuesta en el hook de salida. Deben tratarse como señales, no como soluciones definitivas.

LLM05 Improper Output Handling dispone de Code Safety Linter y Secrets Detection en el hook de salida. Ninguno de los dos sustituye a la validación en su propio código.

LLM03, LLM04 y LLM08 quedan fuera de nuestro ámbito. La cadena de suministro es un problema de aprovisionamiento y canalización de compilación; la única contribución de la pasarela es controlar qué modelos y servidores MCP existen en su registro. El envenenamiento ocurre durante el entrenamiento. Las debilidades vectoriales residen en una canalización RAG en la que la pasarela no interviene. Si un proveedor afirma lo contrario, pregúntele en qué hook se ejecuta el control.

Un ejemplo práctico

Considere un agente de soporte que lee tickets de clientes y realiza consultas en una base de datos de producción a través de MCP. Cuatro de los diez riesgos están activos y requieren cuatro controles diferentes.

Paso uno: registrar los guardrails. Cree un grupo de guardrails y añada Prompt Injection, PII Detection y Secrets Detection. Si ninguno de los componentes integrados se adapta a sus necesidades, utilice un Custom Guardrail que apunte a su propio punto de enlace HTTPS:

Un guardrail personalizado recibe el requestBody con formato de OpenAI, un objeto config configurado en el formulario y un context que contiene el sujeto que realiza la llamada. Para los guardrails de herramientas MCP, context.metadata también incluye un objeto claims con las notificaciones verificadas del JWT del emisor de la llamada, lo que le permite autorizar por aplicación o por alcance:

Un detalle del contrato suele tomar por sorpresa a los usuarios: se debe devolver HTTP 2xx con verdict: false para denegar una solicitud. Un código 400 se interpreta como un error de ejecución y, bajo enforce_but_ignore_on_error, la solicitud se permitirá pasara.

Paso dos: escribir la política. Registrar un guardrail no lo aplica a ningún elemento automáticamente. En Policies → Guardrails, cree una regla que especifique qué guardrails se ejecutan en qué hooks, para qué modelos, servidores MCP, sujetos y metadatos.

Para este agente: Prompt Injection en LLM Input (LLM01); PII Detection en Input y Secrets Detection en Output (LLM02); SQL Sanitizer en MCP Pre-Invoke y Secrets Detection en Post-Invoke (LLM06). Una regla de límite de tasa con rate_limit_applies_per: ['user'] cubre LLM10.

Todas las reglas se evalúan por solicitud y las coincidencias se fusionan por hook, de modo que una regla base y una regla de producción más estricta se aplican conjuntamente. Un mensaje personalizado con Custom Error Message mediante {{failed_guardrails}} es preferible a la salida nativa del proveedor.

Paso tres: supervisar antes de confiar. Inicie cada guardrail en modo Audit. Cada uno aparecerá como su propio tramo (span) en Monitor → Request Traces, mostrando la latencia, el resultado, el alcance y las detecciones:

A continuación, cambie a Enforce But Ignore On Error, que bloquea las infracciones sin permitir que una caída del proveedor interrumpa su aplicación. Utilice el modo Enforce completo únicamente donde el cumplimiento normativo lo exija estrictamente.

¿Listo para solucionar los cuatro riesgos que pertenecen a la pasarela?

Asocie un grupo de guardrails y una regla de límite de tasa a su primer modelo en cuestión de minutos.

Empiece gratis en TrueFoundry

Detalles técnicos a tener en cuenta

Los guardrails de salida no se ejecutan en respuestas en transmisión (streaming). Cuando stream: true, se omiten por completo: evaluar una respuesta requiere el texto completo y el streaming entrega los tokens a medida que se generan. Esto afecta a la cobertura de LLM02 y LLM05, ya que la mayoría de las interfaces de chat utilizan streaming de forma predeterminada. Configure stream: false donde la verificación de la salida sea crítica, valide en el lado del cliente o acepte que los controles del hook de salida estarán inactivos en ese escenario. Los guardrails de entrada no se ven afectados.

Las instrucciones del sistema están excluidas de los guardrails por defecto. La pasarela las elimina antes de enviar el contenido a cualquier guardrail, por lo que nunca se inspeccionan, bloquean ni redactan. CrowdStrike AIDR es la única excepción: examina la instrucción del sistema pero nunca la modifica. Es importante tenerlo en cuenta para LLM07: la pasarela supervisa los intentos de exfiltración en la entrada y los secretos en la salida, no la instrucción en sí misma.

Dónde cuestan dinero los fallos de validación. La validación de entrada se ejecuta en paralelo con la solicitud al modelo; si falla, la pasarela cancela la llamada en curso para evitar costes. La validación de salida se ejecuta después de recibir la respuesta: el bloqueo protege al usuario, pero los tokens ya se han consumido.

Tres funciones integradas son exclusivas de SaaS. Content Moderation, PII / PHI Detection y Prompt Injection no están disponibles en implementaciones autoalojadas. Existen alternativas (Azure Prompt Shield o Palo Alto Prisma AIRS para inyecciones, Azure PII o CrowdStrike para PII, OpenAI Moderations o Bedrock Guardrails para moderación), pero requieren el uso de sus propias credenciales.

Lecturas relacionadas

• Creación de un marco de gobernanza de IA — la capa de políticas donde se integran estos controles
• Seguridad en MCP — análisis en profundidad del aspecto de las llamadas a herramientas en LLM06
• Control de acceso en MCP — permisos a nivel de herramientas y servidores en la práctica
• Qué es una pasarela MCP — dónde se sitúa el punto de aplicación de políticas
• Autenticación API y RBAC en la pasarela de IA — quién puede llamar a qué, antes de la ejecución de los guardrails

Conclusión

El OWASP LLM Top 10 es una excelente lista que a menudo se aplica de manera inadecuada. Como taxonomía, indica qué puede salir mal y en qué orden de prioridad abordarlo. Como lista de verificación para marcar mediante una sola compra, genera una matriz de controles que parece completa pero no ofrece protección real.

La pregunta relevante no es si un producto cubre el Top 10, sino cuáles de estos diez riesgos ocurren en la ruta de la solicitud y si hay algún control supervisando ese punto. Cuatro de ellos ocurren ahí. Una pasarela es el lugar adecuado para esos cuatro, y el único punto donde se pueden aplicar de forma unificada en todos los modelos, equipos y agentes, en lugar de requerir que diez equipos de aplicaciones lo implementen correctamente por separado.

Para los seis restantes, identifique al responsable correspondiente. La cadena de suministro corresponde a quien aprueba los modelos. El envenenamiento corresponde a quien ejecuta el entrenamiento. Las debilidades vectoriales corresponden a quien construyó el índice. Asigne los nombres correspondientes junto a cada riesgo. Ese documento tiene más valor que cualquier afirmación de cobertura de un proveedor, incluida la nuestra.

Ataje los cuatro riesgos que pertenecen a la pasarela

Empiece gratis en TrueFoundry