La passerelle IA d'Alibaba Cloud bloque les attaques par injection de prompt avec un 200, pas un 403

Les questions de sécurité apparaissent avant même que la performance du modèle ne soit mentionnée. Presque tous les projets qui intègrent un LLM à un service réel se heurtent aux mêmes questions lors de la revue d'architecture ou de sécurité : qui peut appeler l'endpoint, que se passe-t-il si quelqu'un tente de le jailbreaker, et si les données personnelles parviennent jamais au modèle sous forme brute.

La réponse d'Alibaba Cloud consiste à ne plus résoudre ces problèmes dans chaque application et à les déplacer dans l'infrastructure. Son AI Gateway se place devant le modèle et exécute l'authentification, le filtrage des injections de prompt et le masquage des données comme un seul pipeline. Intégrez la même logique de sécurité dans chaque application, et chaque changement de politique implique de les modifier toutes. Placez-la dans la passerelle et la politique vit en un seul endroit, sans logique de sécurité côté client ni côté modèle.

Le technical account manager Hosung Kim a documenté une version fonctionnelle de cette configuration dans la région ap-southeast-1 (la version coréenne de la démonstration est en ligne). Le backend est Model Studio (Bailian) exécutant qwen-flash via un endpoint compatible OpenAI. Ce qui est remarquable n'est pas que les composants existent, mais ce que les tests renvoient réellement.

Une clarification d'emblée : le blocage des injections de prompt est géré par AI Guardrails (AI Fence), un service distinct de sécurité de contenu, et non par la passerelle elle-même. La passerelle est la porte qui branche les capacités de sécurité sur le chemin d'appel du modèle. Alibaba Cloud fusionne le développement de l'IA et la sécurité de l'IA dans une même feuille de route, où le même backend qui indexe le code d'un développeur peut aussi inspecter le trafic que ce code génère.

Pourquoi la couche de sécurité appartient à la passerelle, pas à l'application

Les requêtes traversent le pipeline dans un ordre fixe : authentification, Guardrails, masquage. Une clé manquante ou incorrecte est rejetée avec un 401 avant même que Guardrails ou le masquage ne s'exécutent, ce qui permet d'économiser les coûts d'invocation et la latence. La politique de sécurité vit en un seul endroit, la passerelle, si bien qu'une revue de sécurité n'a qu'une seule chose à expliquer et à auditer.

L'AI Gateway est disponible en versions Serverless et Dedicated avec des supports de plugins différents. La version Serverless n'accepte que certains plugins fournis par la plateforme et aucun plugin personnalisé ; sur l'instance testée par Kim, ai-data-masking n'a pas pu être installé, la version Dedicated est donc le choix sûr. La version Dedicated exige également au moins deux zones de disponibilité pour une haute disponibilité.

Authentification et l'interrupteur qui la désactive silencieusement

Avec l'authentification activée sur la Model API, seuls les consommateurs enregistrés (clés API) peuvent l'appeler, et les clés peuvent être créées avec generateMode: Custom afin que vous les fournissiez vous-même. Le piège se trouve dans la console : l'onglet Consumer Authentication comporte un interrupteur Status qui doit être basculé sur Enabled pour que l'application soit réellement effective. S'il reste désactivé, les requêtes passent même sans clé valide. Le conseil de la démonstration est direct : « Vérifiez-le. »

Guardrails : les prompts bloqués reviennent toujours avec un HTTP 200

La sécurité IA (AI Fence) est activée sous Policies and Plugins sur la Model API, avec l'endpoint du service Guardrails pré-rempli. La partie ajustable est la politique de blocage. Au niveau de protection Low, le filtre a attrapé une injection évidente (« ignore previous instructions ») mais a manqué un jailbreak de style DAN. Au niveau Medium, il a attrapé les deux. L'équilibre entre la puissance de détection et les faux positifs est laissé à l'opérateur.

Voici le détail qui casse les clients naïfs : les requêtes bloquées renvoient toujours un HTTP 200. Le message de blocage arrive au format de réponse compatible OpenAI, avec le champ model défini sur « from-security-guard », un objet x_higress_guardrail.blockedDetails classant le blocage comme promptAttack au niveau medium, et zéro jeton consommé. Un code client qui ne vérifie que le code de statut traitera un jailbreak bloqué comme un appel réussi au modèle. La règle est de juger sur le corps, pas sur le code de statut. Le deny_code du plugin de masquage est configurable séparément (Kim l'a défini sur 403 ici), mais comme Guardrails s'exécute en premier, ses blocages de type 200 prennent le pas en pratique.

Masquage des données personnelles coréennes et compromis de la restauration

Le plugin ai-data-masking remplace les valeurs sensibles avant qu'elles n'atteignent le modèle et peut restaurer les valeurs d'origine sur le chemin de réponse. Le piège pour les équipes hors de Chine : les modèles d'exemple intégrés, comme %{MOBILE} et %{IDCARD}, correspondent aux formats chinois, aux numéros de mobile chinois et aux cartes d'identité nationales chinoises. Un service coréen a besoin de ses propres règles, et la configuration finale de la démonstration couvre cinq types :

• La carte d'identité nationale coréenne (987654-1234567) devient ******-******* et n'est jamais restaurée.
• Les numéros de mobile coréens (010-1234-5678) deviennent 010-****-5678, restaurés dans les réponses.
• Les lignes fixes coréennes (02-765-4321) deviennent 02-****-4321, restaurées.
• Les e-mails deviennent ****@domaine, restaurés.
• Les adresses IP deviennent ***.***.***.***, restaurées.

La carte d'identité nationale n'est volontairement pas restaurée : elle ne devrait jamais atteindre le modèle, et il n'y a aucune raison que l'original circule dans les réponses non plus. Restore: true est lui-même un compromis de sécurité, car les valeurs restaurées reviennent au client et peuvent se retrouver dans les logs de la passerelle et du client. Le masquage cache l'original au modèle ; il ne l'élimine pas. Dans un environnement réglementaire qui contrôle également les logs et le stockage, la question de savoir s'il faut restaurer ou non est une décision délibérée.

Deux détails de configuration comptent. Le dictionnaire intégré de mots sensibles (system_deny) provient de houbb/sensitive-word et est centré sur le chinois, les mots interdits coréens doivent donc être ajoutés via deny_words. Et les règles s'appliquent dans l'ordre indiqué, chaque règle correspondant au résultat de la précédente, ce qui signifie que les modèles qui se chevauchent nécessitent que les plus spécifiques soient placés en premier.

L'étiquetage compte aussi. Lorsque la note de test utilisait « RRN » au lieu de « ID », la dimension sensitiveData de Guardrails a bloqué toute la requête au niveau S2 avant même que le plugin de masquage ne la voie. C'est un comportement correct, mais cela signifie que vous ne pouvez pas observer le masquage lorsque Guardrails tue la requête en premier.

Cinq scénarios, vérifiés de bout en bout

La démonstration envoie cinq scénarios à travers la passerelle et enregistre les résultats.

Scénario	Résultat
Question normale avec clé API	Passée, HTTP 200, réponse normale de qwen-flash
Injection de prompt	Bloquée, promptAttack / medium
Jailbreak de style DAN	Bloqué, promptAttack / medium
Requête contenant des PII	Carte d'identité nationale masquée en permanence ; mobile et e-mail masqués au modèle, restaurés dans la réponse
Requête sans clé API	Rejetée avec 401 avant Guardrails ou masquage

La preuve la plus solide que le masquage a fonctionné est une question de suivi. Après le test PII, Kim a demandé au modèle d'indiquer les chiffres exacts après le trait d'union dans l'ID du client. Le modèle a répondu que l'ID s'affiche comme ******-******* et qu'il ne peut pas révéler les chiffres, car son entrée n'a jamais contenu que la forme masquée.

Protéger la porte d'entrée du modèle

Le gain est opérationnel. Une politique, un point de gestion à expliquer et à auditer, c'est exactement ce que demande une revue de sécurité. Cela tombe aussi là où la demande existe déjà : une enquête commandée par Alibaba auprès d'entreprises asiatiques a révélé un enthousiasme quasi universel pour l'adoption de l'IA, mais des demandes constantes de solutions sécurisées de bout en bout, et les modèles Qwen sont cités comme particulièrement populaires au Japon et en Corée du Sud pour leurs performances en langue locale. Un fabricant de véhicules à énergie nouvelle aurait utilisé les fonctions de masquage des données et de conformité transfrontalière de la plateforme pour réussir des audits GDPR, selon notre couverture précédente de l'offensive sécuritaire d'Alibaba.

Le masquage basé sur des règles ne garantit pas une couverture à 100 % des variantes qui ne correspondent pas aux règles, et le comportement de restauration signifie que les données masquées peuvent encore apparaître dans les logs. Pour les équipes qui mettent un LLM en production, le conseil final de la démonstration est le bon étalon : accorder à la porte d'entrée du modèle le même soin de conception qu'au choix du modèle lui-même.