Red Teaming LLM - Confidentialité des Données en Europe avec OpenRouter

La célèbre plateforme OpenRouter, qui offre de nombreuses possibilités de routage vers différents modèles d’IA, permet de garantir un traitement confidentiel des informations envoyées à un modèle (et reçues de celui-ci), surtout lorsque des contraintes réglementaires européennes (RGPD, EU AI Act, etc…) s’appliquent.

De plus, outre sa fonction principale de routage vers différents modèles, OpenRouter offre d’autres fonctionnalités très intéressantes, telles que :

La résilience du traitement grâce à un système de fallback (en cas d’échec de votre modèle principal)
Un tableau de bord de comparaison des modèles (performance, coût, rapidité, etc.)
Son agent autonome, Ori, permettant de travailler avec vos modèles sur votre bureau, dans votre terminal ou sur Slack
Une grande sélection de modèles à des prix compétitifs

Voyons ce que cette plateforme nous permet de faire en termes de confidentialité des données.

Remarque : Dans le cas où vous souhaiteriez suggérer une amélioration ou simplement me contacter, vous pouvez le faire à contact@lionsec.lu.

Contexte

Vous êtes un Red Teamer et allez bientôt démarrer l’audit de sécurité d’un système d’IA. Vos outils, tels que Garak, PyRIT, Promptfoo ou encore DeepTeam, sont prêts à l’emploi. Votre clé d’API et votre modèle adversaire sont configurés, mais il reste encore un détail à régler, et pas des moindres : ce que vous et vos outils allez transmettre au modèle cible, et recevoir de lui, sera-t-il traité selon les normes en vigueur ?

Remarque : Si vous êtes une organisation qui s’apprête à réaliser un audit Red Team de son système d’IA, n’oubliez pas de vérifier que vos auditeurs, internes ou externes, garantissent la confidentialité de vos données !

En effet, il y a plusieurs éléments à prendre en compte :

Le routage des informations : par quels serveurs transitent vos requêtes ? Dans quelles zones ? Comment s’en assurer ?
Ce que vous envoyez : votre savoir-faire, les informations sensibles transmises par votre client avant l’audit, vos outils qui se servent d’un modèle adversaire (attaques multi-turn, encoders, scorers, etc…)
Ce que vous recevez : vos attaques ont-elles fait flancher un modèle et contourné ses garde-fous ? (Par exemple, un système RAG qui vous dévoile les identifiants de la base de données dont il tire ses informations, ou encore une extraction de PII.)
Ce que l’hébergeur du modèle fait réellement de vos données : les conserve-t-il ? Si oui, pendant combien de temps ? Les utilise-t-il pour entraîner ses modèles ?

Remarque : Comme indiqué dans sa documentation, OpenRouter ne conserve pas les prompts ni les réponses de ses utilisateurs, sauf si ceux-ci l’activent explicitement.

Toutes ces questions méritent des réponses afin de préserver la confidentialité des données de vos clients, et c’est ce que cet article va tenter d’éclaircir.

Confidentialité des données

Passons en revue chacun des éléments mentionnés ci-dessus et voyons comment y répondre.

Remarque : Le routage des données en zone UE nécessite les plans Business ou Enterprise d’OpenRouter, avec lesquels des frais s’appliquent lorsque vous ajoutez du crédit.

Le routage des données

Par défaut, OpenRouter route les requêtes via le domaine global https://openrouter.ai/api/v1/chat/completions. Pour que les requêtes passent uniquement par des routes situées en zone UE, vers des modèles hébergés dans cette même zone, il faut utiliser le domaine régional https://eu.openrouter.ai/api/v1/chat/completions (pour les États-Unis : https://us.openrouter.ai/api/v1/chat/completions).

Pour tester avec cURL en zone UE :

Bash

curl https://eu.openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer <OPENROUTER_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "anthropic/claude-sonnet-5",
    "messages": [{"role": "user", "content": "Hello"}]
  }'

Pour obtenir la liste complète des modèles disponibles dans l’UE : https://openrouter.ai/models?region=eu

Sans un plan approprié, vous devriez obtenir un message d’erreur.

Remarque : Lorsqu’aucun endpoint de la région n’est en capacité de répondre, OpenRouter retourne un message d’erreur plutôt que de tenter de router la requête hors de la région.

Forcer le routage en zone UE avec des garde-fous

Savoir utiliser la bonne URL d’OpenRouter est une chose, mais personne n’est à l’abri d’un oubli. Il est donc possible de forcer le routage à l’aide des guardrails (garde-fous) fournis par OpenRouter.

Pour ce faire, connectez-vous à la plateforme OpenRouter puis rendez-vous sur votre tableau de bord. Sélectionnez le menu Workspace -> Guardrails -> Workspace Guardrail, puis Model & Provider Access.

Ensuite, activez l’option Restrict data regions et décochez Global et United States :

Les requêtes envoyées via un autre domaine que https://eu.openrouter.ai sont alors rejetées.

Remarque : Vous pouvez également appliquer ce même garde-fou au niveau du compte entier (tous vos workspaces seront concernés), mais nous nous concentrons ici sur un seul workspace à titre d’exemple.

Le routage étant configuré, passons à la politique de rétention des fournisseurs de modèles.

Politique de rétention avec ZDR

Sur la même page, nous trouvons le menu Zero Data Retention. Cette fonctionnalité garantit qu’aucune donnée n’est conservée par le fournisseur du modèle après le traitement d’une requête. OpenRouter travaille directement avec les fournisseurs de modèles et s’assure que leurs politiques sont conformes à la ZDR.

Comme illustré ci-dessous, il suffit de sélectionner les groupes de modèles que vous souhaitez utiliser (ici, nous les sélectionnons tous à titre d’exemple), puis, lorsque c’est proposé, de choisir Zero retention only :

Il est également possible d’activer la ZDR requête par requête, dans le corps de la requête POST :

Json

{
  "model": "meta-llama/llama-3.3-70b-instruct",
  "messages": [{ "role": "user", "content": "Hello" }],
  "provider": {
    "zdr": true
  }
}

Remarque : Après avoir activé la ZDR pour tous les groupes, nous constatons en bas de page que le nombre de fournisseurs éligibles passe de 96 à 66, et celui des modèles de 656 à 359 (durant l’écriture de cet article). La sélection se réduit encore davantage une fois le routage UE activé.

Collecte des données

Toujours sur la même page, le menu Data Training permet de définir quels endpoints peuvent, ou non, entraîner leurs modèles avec vos données (voire publier vos prompts dans des datasets publics).

Pour une politique de garde-fous la plus stricte possible, désactivez les trois options, et en particulier Allow free endpoints that train on request data si vous utilisez vos outils de Red Team avec un modèle gratuit :

Comme pour la ZDR, la collecte des données peut être explicitement refusée dans le corps de la requête POST :

Json

{
  "provider": {
    "data_collection": "deny"
  }
}

À ce stade, vous disposez d’une politique de confidentialité des données en zone UE : vous savez comment vos données sont routées et ce que le fournisseur du modèle peut, ou ne peut pas, en faire.

Liste blanche des modèles

Un dernier point intéressant consiste à restreindre les modèles utilisables par vos outils via la clé d’API OpenRouter. Sur la même page, dans le menu Access Policy, il suffit d’ouvrir la liste Restriction Mode et de choisir Only Allow…. Ici, nous avons choisi le fournisseur Mistral et son modèle Mistral Large 4 :

Ce paramètre clôt la liste des réglages à définir pour garantir la confidentialité des données en zone UE. Encore une fois, ils sont applicables au niveau global de votre compte ou à un workspace en particulier.

Choisir un modèle adversaire

Une fois toutes ces options définies, nous constatons que la liste des fournisseurs et modèles éligibles, en bas de page, s’est… drastiquement réduite. Il reste néanmoins plusieurs choix intéressants (et si vous disposez de votre propre infrastructure, c’est encore mieux !). Un choix raisonnable consiste à trouver le bon compromis entre le coût des tokens et le niveau de garde-fous du modèle : certains modèles sont plus permissifs que d’autres, et il ne faudrait pas que vos prompts d’attaque soient bloqués !

Pour cela, plusieurs approches sont possibles :

Consulter des benchmarks tels que l’UGI Leaderboard sur Hugging Face
Faire des essais directement et comparer les résultats (encore une fois, plusieurs modèles peuvent être appelés avec la même clé d’API, c’est toute la magie d’OpenRouter !)
Jailbreaker un modèle vous-même
Demander conseil à la communauté ou en discuter avec vos pairs :)

Checklist avant l’audit

Pour résumer tout ce que nous venons de voir, voici les vérifications à effectuer avant l’audit :

Utiliser le domaine régional UE
Restreindre les régions autorisées avec un guardrail
Activer la ZDR
Refuser l’entraînement sur vos données
[Optionnel] - Restreindre les modèles autorisés
Attaquer !

Conclusion

Tout comme en cybersécurité traditionnelle, nous avons vu que la confidentialité des données est essentielle : avant d’utiliser les outils les plus populaires du moment, il faut vous assurer de savoir ce qu’il advient des données que vous traitez. La plateforme OpenRouter offre différentes possibilités pour contrôler les flux de données à plusieurs niveaux, et elles doivent être appliquées afin de respecter les exigences de vos clients.

Liens

Contact

Pour toute suggestion d’amélioration ou simplement me contacter : contact@lionsec.lu.