Entscheiden, welche Clients Ihre Modelle erreichen dürfen
Zugriffsregeln für Anfrage-Header, die nach User-Agent, Origin oder beliebigem Header erlauben oder verweigern — global, auf eine Key-Gruppe oder auf einen einzelnen Schlüssel begrenzt.
Worüber die Community tatsächlich klagt
„Ein geleakter Schlüssel bedeutet, dass jeder damit unser Kontingent verbrennen kann“, „wir wollen die Coding-Agenten des ganzen Unternehmens auf die Allowlist setzen, aber blankes curl und Scraper blockieren“, „die Anbieterkonsole hat eine IP-Allowlist, aber unser Datenverkehr ist dynamisch und proxy-gestützt, passt also nie“.
Die Durchsetzung muss dort erfolgen, wo die Anfrage ankommt — am Gateway —, nicht über eine Client-Einstellung, die ein Entwickler einfach ausschalten kann.
Wie GateLLM es macht
GateLLM bewertet Zulassungsregeln bei jeder Anfrage anhand von HTTP-Headern: sechs Match-Typen (exakt / Präfix / Regex / vorhanden / abwesend / beliebig) und drei Geltungsbereiche (global / Key-Gruppe / Schlüssel), geordnet nach sort_order mit First-Match-Wins.
Für „nur freigegebene Clients“ nutzen Sie den Allowlist-Modus: Setzen Sie die Standardaktion der Gruppe auf Verweigern und fügen Sie dann eine einzige Erlauben-Regel hinzu, die die Client-Signatur trifft — alles andere wird zurückgewiesen, bevor es ein Modell erreicht.
5 Hebel, die tatsächlich wirken
- 6 Match-Typen: exakt / Präfix / Regex / vorhanden / abwesend / beliebig — eine Regel kann „A oder B oder C“ per Regex-Alternation ausdrücken
- 3 Geltungsbereiche: global, pro Key-Gruppe, pro Schlüssel — mit First-Match-Wins und globaler Priorität bei gleicher Reihenfolge
- Allowlist-Modus: Standard-Verweigern + ein explizites Erlauben — neue unbekannte Clients werden standardmäßig abgewiesen
- Regeln decken auch Modelllisten-Routen (/v1/models) ab, sodass ein verweigerter Client durchgängig ausgesperrt ist
- ReDoS-sichere Regex-Engine mit linearer Laufzeit — pathologische Muster werden beim Laden abgewiesen, nicht zur Anfragezeit