El AI Gateway de Alibaba Cloud bloquea los ataques de prompt con un 200, no un 403

Las preguntas de seguridad aparecen antes de que se mencione el rendimiento del modelo. Casi todos los proyectos que conectan un LLM a un servicio real se topan con las mismas durante la revisión de arquitectura o de seguridad: quién puede llamar al endpoint, qué ocurre cuando alguien intenta hacer jailbreak, y si los datos personales llegan al modelo en su forma original.

La respuesta de Alibaba Cloud es dejar de resolver estos problemas dentro de cada aplicación y trasladarlos a la infraestructura. Su AI Gateway se sitúa delante del modelo y ejecuta la autenticación, el filtrado de inyección de prompts y el enmascaramiento de datos como un único pipeline. Si se construye la misma lógica de seguridad en cada aplicación, cada cambio de política implica tocar todas ellas. Si se pone en el gateway, la política vive en un solo lugar, sin lógica de seguridad ni en el cliente ni en el modelo.

El gestor técnico de cuentas Hosung Kim documentó una versión funcional de esta configuración en la región ap-southeast-1 (la versión coreana del recorrido está en línea). El backend es Model Studio (Bailian) ejecutando qwen-flash a través de un endpoint compatible con OpenAI. Lo notable no es que las piezas existan. Es lo que devuelven realmente las pruebas.

Una aclaración de entrada: el bloqueo de la inyección de prompts lo gestiona AI Guardrails (AI Fence), un servicio independiente de seguridad de contenidos, no el gateway en sí. El gateway es la puerta que conecta las capacidades de seguridad con la ruta de llamada al modelo. Alibaba Cloud ha estado fusionando el desarrollo de IA y la seguridad de la IA en una única hoja de ruta, donde el mismo backend que indexa el código de un desarrollador también puede inspeccionar el tráfico que ese código genera.

Por qué la capa de seguridad va en el gateway, no en la aplicación

Las solicitudes fluyen por el pipeline en un orden fijo: autenticación, Guardrails, enmascaramiento. Una clave ausente o incorrecta se rechaza con 401 antes de que se ejecuten Guardrails o el enmascaramiento, lo que ahorra coste de invocación y latencia. La política de seguridad vive en un solo lugar, el gateway, de modo que una revisión de seguridad tiene una sola cosa que explicar y auditar.

AI Gateway se ofrece en modalidades Serverless y Dedicated con distinto soporte de plugins. Serverless solo acepta algunos plugins proporcionados por la plataforma y ninguno personalizado; en la instancia que probó Kim, no se pudo instalar ai-data-masking, por lo que una instancia Dedicated es la opción segura. Dedicated también requiere al menos dos zonas de disponibilidad para alta disponibilidad.

Autenticación, y el interruptor que la desactiva silenciosamente

Con la autenticación habilitada en la API del Modelo, solo los consumidores registrados (claves API) pueden llamarla, y las claves pueden crearse con generateMode: Custom para que puedas proporcionarlas tú mismo. La trampa está en la consola: la pestaña Consumer Authentication tiene un interruptor de Estado que debe estar en Enabled (activado) para que la comprobación se aplique de verdad. Si permanece desactivado, las solicitudes pasan aunque la clave no sea válida. El consejo del recorrido es contundente: "verifícalo dos veces".

Guardrails: los prompts bloqueados aún devuelven HTTP 200

La seguridad de IA (AI Fence) se habilita en Policies and Plugins en la API del Modelo, con el endpoint del servicio Guardrails ya rellenado. La parte ajustable es la política de bloqueo. En el nivel de protección Low, el filtro detectó una inyección obvia ("ignora las instrucciones anteriores") pero no detectó un jailbreak estilo DAN. En Medium, detectó ambos. El equilibrio entre la fuerza de detección y los falsos positivos queda a criterio del operador.

Aquí está el detalle que rompe el código cliente ingenuo: las solicitudes bloqueadas devuelven HTTP 200. El mensaje de bloqueo llega en formato de respuesta compatible con OpenAI, con el campo model establecido en "from-security-guard", un objeto x_higress_guardrail.blockedDetails que clasifica el bloqueo como promptAttack a nivel medium, y cero tokens consumidos. El código cliente que solo comprueba el código de estado tratará un jailbreak bloqueado como una llamada al modelo exitosa. La regla es juzgar por el cuerpo, no por el código de estado. El deny_code del plugin de enmascaramiento se configura por separado (Kim lo estableció en 403), pero como Guardrails se ejecuta primero, sus bloqueos estilo 200 tienen prioridad en la práctica.

Enmascaramiento de PII coreano y la contrapartida de la restauración

El plugin ai-data-masking reemplaza los valores sensibles antes de que lleguen al modelo y puede restaurar los originales en la ruta de respuesta. La pega para equipos fuera de China: los patrones de ejemplo integrados, como %{MOBILE} y %{IDCARD}, coinciden con formatos chinos, números de móvil chinos y documentos de identidad nacionales chinos. Un servicio coreano necesita sus propias reglas, y la configuración final del recorrido cubre cinco tipos:

• El documento de identidad nacional coreano (987654-1234567) se convierte en ******-******* y nunca se restaura.
• Los números de móvil coreanos (010-1234-5678) se convierten en 010-****-5678 y se restauran en las respuestas.
• Los teléfonos fijos coreanos (02-765-4321) se convierten en 02-****-4321 y se restauran.
• Los correos electrónicos se convierten en ****@dominio y se restauran.
• Las direcciones IP se convierten en ***.***.***.*** y se restauran.

El documento de identidad nacional no se restaura a propósito: nunca debería llegar al modelo, y tampoco hay razón para que el original circule en las respuestas. Restore: true es en sí misma una contrapartida de seguridad, porque los valores restaurados vuelven al cliente y pueden acabar en los registros del gateway y del cliente. El enmascaramiento oculta el original al modelo; no lo elimina. En un entorno normativo que también controla registros y almacenamiento, si restaurar o no es una decisión deliberada.

Dos detalles de configuración importan. El diccionario integrado de palabras sensibles (system_deny) proviene de houbb/sensitive-word y está centrado en chino, por lo que las palabras coreanas prohibidas deben añadirse mediante deny_words. Y las reglas se aplican en el orden en que se enumeran, y cada regla compara con el resultado de la anterior, lo que significa que los patrones superpuestos necesitan primero los más específicos.

El etiquetado también importa. Cuando la nota de prueba usó "RRN" en lugar de "ID", la dimensión sensitiveData de Guardrails bloqueó toda la solicitud en el nivel S2 antes de que el plugin de enmascaramiento la viera. Ese es un comportamiento correcto, pero significa que no se puede observar el enmascaramiento cuando Guardrails mata la solicitud primero.

Cinco escenarios, verificados de principio a fin

El recorrido envía cinco escenarios a través del gateway y registra los resultados.

La prueba más contundente de que el enmascaramiento funcionó es una pregunta de seguimiento. Después de la prueba de PII, Kim pidió al modelo que indicara los dígitos exactos después del guion en el ID de cliente. El modelo respondió que el ID se muestra como ******-******* y que no puede revelar los dígitos, porque su entrada solo contenía la forma enmascarada.

Protegiendo la puerta de entrada del modelo

La recompensa es operativa. Una política, un punto de gestión que explicar y auditar, que es exactamente lo que pide una revisión de seguridad. Y aterriza donde ya existe la demanda: una encuesta de empresas asiáticas encargada por Alibaba encontró un entusiasmo casi universal por la adopción de IA, pero también llamados constantes a soluciones seguras de extremo a extremo, y los modelos Qwen se citan como especialmente populares en Japón y Corea del Sur por su rendimiento en el idioma local. Según nuestra cobertura anterior del impulso de seguridad de Alibaba, un fabricante de vehículos de nueva energía supuestamente utilizó las funciones de enmascaramiento de datos y cumplimiento transfronterizo de la plataforma para superar auditorías del GDPR.

El enmascaramiento basado en reglas no garantiza una cobertura del 100 % de las variantes que no coinciden con las reglas, y el comportamiento de restauración significa que los datos enmascarados aún pueden aparecer en los registros. Para los equipos que llevan un LLM a producción, el consejo final del recorrido es la vara de medir correcta: presta a la puerta de entrada del modelo el mismo cuidado de diseño que a la elección del modelo.