senn-techUpdate am Gateway vom 15. September: Was es über unsere KI-Strecke sagt
Am 15. September 2026 hat das LiteLLM-Projekt die Version 1.101.0 veröffentlicht, fünf Tage nach dem vorigen Stable-Release 1.100.1. Drei Änderungen darin lesen sich wie ein Prüfplan, den wir uns selbst hätten schreiben können: Uploads auf /v1/files und /upload/logo sind jetzt restringiert und werden validiert (#39379), Passwortrichtlinie und Login ausschließlich über SSO werden erzwungen (#39381), und ein S3-Vektor-Store konnte dem Router nicht mehr ausweichen (#34788). Wir betreiben ein Gateway dieser Software vor vier RTX 5090. Dieser Text ist deshalb kein Release-Kommentar, sondern der Blick auf die eigene Strecke.
Was das Update enthält
Fix in 1.101.0 | Was er bedeutet | Unser Prüfschritt |
|---|---|---|
#39379, Uploads auf /v1/files und /upload/logo | Die Dateiannahme war zu offen | Dateiliste mit dem Key eines anderen Teams aufrufen |
| #39381, Passwortrichtlinie und SSO-only-Login | Eigene Lokalnutzer unter der Verwaltungsoberfläche | UI-Route von einem Büro-Arbeitsplatz aus ansprechen |
| #34788, Router-Bypass im S3-Vektor-Store | Eine Vektor-Lane konnte dem Router entkommen | Vektor-Abfragen im Spend-Log suchen, wo keines steht |
Und dann der Teil, der uns am nächsten trifft, es aber nicht ist. In der Vorablinie von 1.102 steht die OAuth-Härtung für MCP: #38724 bindet die Zugangsdaten eines Nutzers an den tatsächlich authentifizierten Aufrufer, #39548 autorisiert jede Responses-API-ID, auch die, welche das Proxy nicht selbst ausgestellt hat. #40923 verlangt eine Zulassung für delegierten OAuth und ist inzwischen in der 1.103-Entwicklung notiert. Stand 17. September 2026 steckt nichts davon in einem Stable-Release. Wer daraus eine Handlungsanweisung baut, muss Vorablinie und Stable-Linie trennen können. Das ist die eigentliche Prüfung, nicht die Zahl im Tag.
Die unbequeme Lesart
Der erste Impuls bei so einem Release ist die Frage, ob wir betroffen sind. Die ehrlichere Frage lautet, warum diese drei Punkte nicht schon länger auf unserer eigenen Liste standen.
Wir haben über unsere KI-Strecke gemessen, was sich messen lässt: 18,3 Milliarden Tokens in einem Monat, 261 Euro eigene Kosten gegen 7.640 Euro API-Listenpreis, Cache-Trefferquoten, Dekodierungsraten. Wir haben Lanes definiert, damit kein Client mehr einen erfundenen Modellnamen schickt. Wir haben die Inferenz-Engine gegen ihre Advisories geprüft und den Cross-User-Leak öffentlich dokumentiert, samt der Warnung, dass eine Versionsnummer kein Befund ist.
Was in dieser Aufzählung fehlt: die Frage, wer im Gateway wessen Dateien auflisten darf.
Das Gateway ist die Station mit der höchsten Konzentration im Haus. Es hält jeden API-Schlüssel, jeden Prompt jedes Nutzers und jede hochgeladene Datei, und es gibt delegierte Zugänge an Systeme weiter, die außerhalb unserer Inferenz liegen: Frontends, Workflows, MCP-Server. Die Engine darunter rechnet. Das Gateway weiß.
Unsere Aufmerksamkeit ist bei der Engine gestartet, weil dort die messbaren Größen liegen: Tokens, Karten, Tempo, Strom. Sicherheitstechnik entsteht an der Stelle, die Weichen stellt, nicht an der, die zählt. Wer Uploads, Schlüssel und Dateilisten nicht im Messpanel hat, prüft sie später. 1.101.0 ist uns hier zuvorgekommen.
Sechs Schritte, sechs Befehle
Der Rest dieses Releases passt auf sechs Fragen. Er läuft bei uns diese Woche, als Befundaufnahme, nicht als Ergebnis. Jeder Schritt hat eine Antwort, die sich nicht schönreden lässt; die Rubriken dahinter sind unsere vier NIS2-Maßwörter, keine Paragrafen. Pro Schritt sind das eine halbe Stunde, die Reihenfolge können Sie übernehmen.
1. Welche Version läuft wirklich? Auf dem Host pip show litellm, dazu der Image-Tag und das Datum des letzten Neustarts. Schlechte Antwort: ein latest-Tag. Dann ist die Versionsfrage nicht veraltet, sondern unbeantwortbar, weil sie vom Zeitpunkt des letzten Startvorgangs abhängt. Die Images sind signiert, eine cosign-Prüfung gegen den festgeschriebenen Tag gehört zum Rollen. Rubrik: Protokollierung.
2. Wer sieht wessen Dateien? Ein Request gegen die Dateiliste mit dem Key eines anderen Teams. Schlechte Antwort: die Liste des anderen Teams, sauber nach Datum sortiert. Noch schlechter: ein HTTP-200 ohne jeden Key. Rubrik: Vertraulichkeit.
3. Teilen sich zwei Nutzer einen delegierten Token? Dieselbe MCP-Abfrage einmal als Person A, einmal als Person B, und den Server gefragt, welche Identität er sieht. Schlechte Antwort: beide landen im selben Postfach oder im selben Tool-Account. Genau diese Trennung adressiert die Vorablinie von 1.102 erst. Rubrik: Vertraulichkeit.
4. Ist die Verwaltungsoberfläche aus dem Büro erreichbar?
# Vom Arbeitsplatz im Büro-Netz, nicht vom Admin-Host
curl -s -o /dev/null -w "%{http_code}\n" https://<gateway>/ui/login
Schlechte Antwort: 200 plus Login-Formular, das Lokalnutzer akzeptiert, obwohl die API über SSO läuft. Wer einen Identity Provider im Haus hat, sollte ihn vor dieser Oberfläche sehen und nicht daneben. Rubrik: Zugriffskontrolle.
5. Was darf ein Key, und wann wurde er gedreht? Für jeden Key: Ablaufdatum, Spend-Limit, freigegebene Modelle, Datum der letzten Drehung. Schlechte Antwort: ein Schlüssel aus dem Einrichtungsjahr der Lane ohne Kappe und ohne Modellliste, daneben ein Spend-Log, das Verbrauch anzeigt, aber keine Obergrenze durchsetzt. Rubrik: Zugriffskontrolle und Protokollierung.
6. Bekommt ein Agent die ganze Lane? Eine Sitzung mit prallgefülltem Kontext starten, während eine zweite interaktiv dieselbe Lane benutzt, und deren Wartezeit messen. Schlechte Antwort: Die zweite hängt ohne Rückmeldung, weil kein Aufnahmeregime pro Key und Team greift. Ein Agent mit vollem Kontextfenster ist kein normaler Nutzer, sondern Spitzenlast. Rubrik: Kapazität.
Vier Rubriken, sechs Schritte, zweimal doppelt belegt. Die Begriffe sind unsere Führrubriken im NIS2-Status, kein Zitat und keine Normnummer.
Was der Warndienst im August lieferte
Für Warnungen auf derselben Ebene ist der Warndienst zuständig, über den auch die vLLM-Meldungen aus dem August bei uns ankamen: ein nicht authentisierter DoS mit Fix in 0.24.0, ein SSRF mit Lektüre lokaler Dateien mit Fix in 0.26.0, und der Leak über Nutnergrenzen hinweg mit Fix in 0.27.0. Drei Meldungen, drei Releases, jeweils ein Tag, den man zurückverfolgen kann. Wer den Warndienst nicht abonniert, erfährt von diesen dreien erst, wenn jemand anders sie findet.
Was der Selbstbetrieb kostet
Zwischen dem 1. und dem 15. September 2026 führt die Release-Liste fünf Stable-Tags: 1.99.0, 1.99.1, 1.100.0, 1.100.1 und 1.101.0. Dazwischen liegen die dev- und rc-Linien von 1.101 und 1.102. Kein Ausreißer, das ist der Rhythmus. Wer ein Open-Source-Gateway selbst betreibt, übernimmt mit dem Betrieb auch dessen Security-Response. Ab dem Tag ist die Frage, ob ein Problem bekannt und behoben ist, unsere, und nicht die eines Anbieters mit Supportnummer.
Die Kostenstelle heißt nicht Hardware. Sie heißt: ein fester Termin pro Woche für Release-Liste und Advisories, eine Entscheidung pro Version, ein Regressionstest nach jedem Rollen. Drei bis vier Stunden im Monat, gegen einen Posten, den die Token-Rechnung nicht kennt.
Unsere Wahl für diese Woche: Versionsstand im Image-Tag festgeschrieben, kein latest, Signaturprüfung beim Rollen, Advisory-Abo, fester Slot pro Woche. Ein Managed Control Plane ist die andere Antwort, dann liest jemand anders die Advisories und liegen die Schlüssel woanders. Beides ist vertretbar, sicherer ist nichts davon, es ist verschoben. Diese Wahl gilt, solange das Gateway ausschließlich eigene Mitarbeitende bedient und der wöchentliche Slot hält.
Kippen tut sie unter zwei Bedingungen. Sobald Mandanten oder Kundendaten über das Gateway laufen, ist ein Admin-Zugang kein Innenverhältnis mehr, und die Security-Response gehört vertraglich abgesichert. Und wenn der Slot zweimal hintereinander ausfällt, haben wir kein Advisory-Abo, sondern einen Rückstand. In beiden Fällen wechseln wir.
Weiterführende Quellen
Müssen wir auf 1.102 warten, weil die OAuth-Härtung dort steht?+
Nein. Die Upload- und die Login-Härtung stecken in 1.101.0 und damit in einem Stable-Release. Die drei OAuth-Punkte sind Stand 17. September 2026 ausschließlich in rc- und dev-Linien notiert. Eine Vorabversion als Security-Maßnahme zu rollen wäre der Tausch von einem Risiko gegen zwei.
Was heißt delegierter OAuth am Gateway konkret?+
Ein MCP-Server bekommt nicht unsere Hauszugangsdaten, sondern ein Token, das im Namen einer angemeldeten Person ausgestellt wurde. Trennt das Gateway die Nutzer nicht sauber, handeln alle Agenten mit dem Token der Person, die diesen Server einmal freigeschaltet hat. Das ist dann kein Konfigurationsdetail, sondern ein Identitätsproblem.
Ist ein selbst betriebenes Gateway gegen NIS2 schlechter aufgestellt als ein Managed-Dienst?+
Nach den vier Rubriken hier nicht: Vertraulichkeit, Zugriffskontrolle, Protokollierung und Kapazität sind in beiden Fällen prüfbar, beim Anbieter nur von außen. Der Unterschied ist, wer die Advisories liest und wem die Schlüssel gehören. Beide Fragen müssen beantwortbar sein, unabhängig davon, wo das Gateway läuft.