Décidez quels clients peuvent atteindre vos modèles
Des règles d’accès par en-tête de requête qui autorisent ou refusent selon le User-Agent, l’origine ou tout en-tête — aux portées globale, groupe de clés ou clé unique.
Ce dont la communauté se plaint réellement
« Une clé qui fuit signifie que quiconque la détient peut brûler notre quota », « nous voulons autoriser les agents de codage de toute l’entreprise mais bloquer curl brut et les scrapers », « la console du fournisseur a une liste d’autorisation IP, mais notre trafic est dynamique et derrière un proxy, donc elle ne correspond jamais ».
L’application doit se faire là où la requête arrive — sur la passerelle — et non dans un réglage côté client qu’un développeur peut simplement désactiver.
Comment GateLLM procède
GateLLM évalue les règles d’admission à chaque requête par rapport aux en-têtes HTTP : six types de correspondance (exact / préfixe / regex / existe / absent / quelconque) et trois portées (globale / groupe de clés / clé), ordonnés par sort_order avec première correspondance gagnante.
Pour « uniquement les clients approuvés », utilisez le mode liste d’autorisation : définissez l’action par défaut du groupe sur refuser, puis ajoutez une seule règle d’autorisation correspondant à la signature du client — tout le reste est rejeté avant d’atteindre un modèle.
5 leviers qui portent réellement
- 6 types de correspondance : exact / préfixe / regex / existe / absent / quelconque — une règle peut exprimer « A ou B ou C » via une alternance regex
- 3 portées : globale, par groupe de clés, par clé — avec première correspondance gagnante et priorité globale à ordre égal
- Mode liste d’autorisation : refus par défaut + une autorisation explicite — les nouveaux clients inconnus sont rejetés par défaut
- Les règles couvrent aussi les routes de liste de modèles (/v1/models), donc un client refusé est verrouillé de bout en bout
- Moteur regex en temps linéaire sûr contre ReDoS — les motifs pathologiques sont rejetés au chargement, pas au moment de la requête