Perplexity erläutert die Funktionsweise von LLM-Gateways und die Risiken im Produktivbetrieb

Perplexity veröffentlichte am 27. Oktober 2026 einen praxisorientierten Leitfaden zu LLM-Gateways. Darin erklärt das Unternehmen Engineering-Teams, wie die zwischengeschaltete Ebene Modellaufrufe weiterleitet, authentifiziert, zwischenspeichert und protokolliert, und listet die Sicherheits- und Zuverlässigkeitsrisiken auf, die entstehen, wenn Zugangsdaten von Anbietern in einem einzigen Dienst gebündelt werden.

Definition und Taxonomie von Gateways

Der Leitfaden definiert ein LLM-Gateway als Reverse-Proxy für Modellaufrufe: Anwendungen senden Anfragen an das Gateway statt direkt an Anbieter wie OpenAI, Anthropic oder Google. Das Gateway leitet diese Anfragen weiter und wendet dabei die Regeln des Betreibers an. Die Kategorie wird als Antwort auf die unübersichtliche Vielzahl einzelner Zugänge dargestellt. Als Einstieg dient ein Reddit-Beitrag vom September 2026 im Subreddit r/LLMDevs, in dem ein Ingenieur einen Arbeitsplatz beschrieb, an dem alle eigene Schlüssel für Claude, OpenAI, AWS Bedrock und andere Inferenzanbieter hatten.

Die Vergleichstabelle des Leitfadens unterscheidet vier Gateway-Typen. Ein API-Gateway steht vor den Backend-Diensten und entscheidet, ob ein Client authentifiziert ist und sein Ratenlimit einhält. Ein LLM-Gateway steht vor den Modellanbietern und entscheidet, welches Modell eine Anfrage erhält, wer dafür bezahlt und ob eine Antwort zurückkommt. Ein MCP-Gateway entscheidet, ob ein Agent ein bestimmtes Tool mit bestimmten Argumenten aufrufen darf. Der Leitfaden verwendet den Begriff „KI-Gateway“ für Produkte von Anbietern, die eine beliebige Kombination dieser Funktionen bündeln.

Der Anfragezyklus in sechs Schritten

Der Leitfaden erläutert die Funktionsweise, indem er eine einzelne Anfrage vom Aufruf durch die Anwendung bis zum Modell und zurück verfolgt. Zunächst sendet die Anwendung eine Chat-Anfrage, häufig in einem OpenAI-kompatiblen Format, an den Endpunkt des Gateways. Das Gateway prüft die Zugangsdaten, oft einen virtuellen Schlüssel, der einem Team oder Produkt zugewiesen wurde. Sind Eingabeschutzmaßnahmen eingebunden, kann es außerdem Prompts auf sensible Daten oder Versuche überprüfen, die Anweisungen des Modells außer Kraft zu setzen. Ist die Zwischenspeicherung aktiviert, kann eine passende Anfrage, die die entsprechenden Bedingungen erfüllt, mit einer gespeicherten Antwort beantwortet werden. Einige Gateways bieten semantisches Caching, bei dem als ähnlich eingestufte statt identischer Anfragen zusammengeführt werden. Anschließend sucht das Gateway in seiner Konfiguration nach der passenden Route und kann auf einen Ersatzanbieter ausweichen, falls beim ersten Anbieter eine Zeitüberschreitung auftritt. Es wandelt die Anfrage in das Format des ausgewählten Anbieters um, authentifiziert den ausgehenden Aufruf und wandelt die Antwort für die Anwendung zurück. Bei aktivierter Protokollierung hält es fest, wer den Aufruf getätigt hat, welches Modell ihn bearbeitet hat, wie viele Tokens verwendet wurden, wie hoch die Latenz war und welche Kosten anfielen.

Sicherheits- und Zuverlässigkeitsrisiken

Die zentrale Warnung des Leitfadens lautet, dass das Gateway Zugangsdaten an einer Stelle bündelt. Das Sicherheitsteam von Microsoft hat aufgelistet, welche Daten eine LiteLLM-Bereitstellung enthalten oder abrufen kann: API-Schlüssel von Anbietern, den LiteLLM-Masterschlüssel, Datensätze zu virtuellen Schlüsseln, Datenbank-Verbindungszeichenfolgen, Routing-Konfigurationen und Mandantenrichtliniendaten. In diesem Beitrag vom 26. August 2026 beschrieb Microsoft einen beobachteten Kompromiss eines LiteLLM-Gateways, bei dem Angreifer Zugangsdaten aus der Laufzeitumgebung des Gateways abgriffen.

Am 13. Oktober 2026 gab Check Point Research zwei schwerwiegende Sicherheitslücken in LiteLLM bekannt: CVE-2026-35029, eine Schwachstelle in der Zugriffskontrolle, durch die authentifizierte Benutzer – auch solche mit Leseberechtigung – auf Verwaltungsfunktionen zugreifen und das Gateway übernehmen konnten, sowie CVE-2026-59823, eine serverseitige Anfragefälschung, durch die Benutzer Gateway-Anfragen an einen von Angreifern kontrollierten Server umleiten und API-Schlüssel von KI-Anbietern abfangen konnten. Beide Schwachstellen wurden in LiteLLM Version 1.83.9 behoben. Check Point zufolge verzeichnete LiteLLM 97 Millionen Downloads pro Monat und mehr als 59.000 GitHub-Stars. Außerdem teilte das Unternehmen mit, dass es die koordinierte Offenlegung gegenüber LiteLLM im Oktober 2025 eingeleitet hatte.

Der Leitfaden empfiehlt Teams außerdem, für Schutzmaßnahmen eine Fehlerbehandlungsrichtlinie festzulegen. Hooks werden als Punkte im Anfragepfad beschrieben, an denen das Gateway Inhalte zur Bewertung an einen externen Scanner übergibt. Der Leitfaden weist darauf hin, dass die Dokumentation von Portkey die Hooks before_request_hooks und after_request_hooks aufführt und TrueFoundry vier Hooks ausführt, indem es Prüfungen vor und nach MCP-Tool-Aufrufen ergänzt.

Zur Zuverlässigkeit verweist der Leitfaden auf dokumentierte Ausfälle. Cloudflares eigener Bericht über den Ausfall vom 12. Juni 2025 hält fest, dass die Fehlerrate bei AI Gateway auf bis zu 97 % der Anfragen anstieg, weil AI Gateway für Client- und interne Konfigurationen auf Workers KV angewiesen ist. Der Gesamtausfall dauerte 2 Stunden und 28 Minuten. Im Ausfallbericht von OpenRouter zu den Ausfällen vom 17. und 19. Februar 2026 heißt es, dass die Vorfälle nach dem Ausfall einer Caching-Abhängigkeit eines Drittanbieters 38 beziehungsweise 35 Minuten dauerten, zu 401-Fehlern mit der Meldung „Benutzer nicht gefunden“ führten und Abhilfemaßnahmen nach sich zogen. Dazu gehörten Circuit Breaker und die Rückgabe von 503- statt 401-Fehlern, wenn Infrastrukturprobleme die Prüfung von Berechtigungen verhindern.

Bereitstellungsoptionen, Preise und Besonderheiten der Anbieter

Der Leitfaden stellt vier Bereitstellungswege vor. Teams können ein einfaches Gateway selbst entwickeln – es nimmt Anfragen entgegen, prüft den Schlüssel des Aufrufers, ergänzt die Zugangsdaten des Anbieters, leitet den Aufruf weiter und protokolliert das Ergebnis – oder ein quelloffenes Gateway selbst hosten. Als Optionen werden LiteLLM, Bifrost und Helicone genannt. Zu den verwalteten Gateways zählen Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter und das gehostete Gateway von Portkey. Als vierter Weg lässt sich ein bereits im Unternehmen betriebenes API-Gateway erweitern; genannt werden Kong AI Gateway, die KI-Gateway-Richtlinien von Apigee und das KI-Gateway von Azure API Management.

Zu den Kosten erklärt der Leitfaden, dass LLM-Gateways von kostenloser Open-Source-Software bis hin zu kostenpflichtigen Tarifen reichen, die bei etwa 50 $ pro Monat beginnen und für Unternehmen individuell kalkuliert werden. Einige Anbieter berechnen stattdessen einen prozentualen Aufschlag: Beim Standard-Tarif von OpenRouter kommen laut Leitfaden 5,5 % auf Guthabenkäufe hinzu.

Zum Abschluss beantwortet der Leitfaden Fragen zu einzelnen Anbietern. Er erklärt, dass Amazon Bedrock AgentCore Gateway Modellaufrufe über sogenannte „Inferenzziele“ unterstützt, wie AWS sie bezeichnet. So können Anwendungen über einen einzigen Endpunkt Anbieter wie Amazon Bedrock, OpenAI und Anthropic erreichen. Außerdem heißt es, dass die Agent API von Perplexity die Schnittstelle der Responses API von OpenAI unterstützt. Teams können dadurch vorhandene OpenAI-Clientbibliotheken weiterverwenden. Über die Agent API können Nutzer zudem bis zu fünf Modelle in einer bevorzugten Reihenfolge auflisten, darunter auch Modelle verschiedener Anbieter. Der Leitfaden nennt auch Perplexitys quelloffenes Numbat, das über lokale Hooks eine Verbindung zu unterstützten Agenten herstellt und geplante Aktionen wie Shell-Befehle oder Schreibvorgänge in Dateien vor ihrer Ausführung prüfen kann. Eine Blockierung solcher Aktionen ist optional und standardmäßig deaktiviert.