Ihr Agent hat einen Mittelsmann, den Sie nicht geprüft haben

Forscher kauften 28 kostenpflichtige LLM API Router von Taobao, Xianyu und Shopify-gehosteten Storefronts und sammelten 400 weitere aus öffentlichen Communities. Sie instrumentierten Anfragen mit platzierten Zugangsdaten und testeten jeden Router, um zu sehen, was er mit dem Datenverkehr anstellte.¹

Siebzehn dieser Router griffen auf AWS-Canary-Zugangsdaten zu, die in den Anfragen platziert worden waren. Einer leerte ETH von einem privaten Schlüssel, der als Köder ausgelegt worden war. Ein geleakter OpenAI-Schlüssel, den das Team als Honeypot eingerichtet hatte, erzeugte 100M GPT-5.4 Token und, laut Abstract, „mehr als sieben Codex-Sitzungen”, bevor sie ihn zurückzogen.¹ Separate schwach konfigurierte Lockvögel lieferten 2B abgerechnete Token, 99 Zugangsdaten über 440 Codex-Sitzungen hinweg und 401 Sitzungen, die bereits im autonomen YOLO-Modus liefen.¹

Der LLM API Router ist die neue Angriffsfläche. Niemand auditiert ihn.

TL;DR

Drittanbieter-LLM-API-Router sind Proxys auf Anwendungsebene mit vollem Klartextzugriff auf jede JSON-Payload, die zwischen Ihrem Agenten und dem vorgelagerten Modell übertragen wird. Kein Anbieter erzwingt kryptografische Integrität zwischen Client und Upstream. Eine neue Arxiv-Arbeit von Liu, Shou, Wen, Chen und Fang präsentiert die erste systematische Studie dieser Angriffsfläche, und die Felddaten sind hässlich: 1 von 28 kostenpflichtigen Routern und 8 von 400 kostenlosen Routern injizierten aktiv Schadcode in Antworten, 2 setzten adaptive Ausweichauslöser ein, 17 griffen auf platzierte AWS-Canary-Zugangsdaten zu, und 1 leerte ETH von einem platzierten privaten Schlüssel.¹ Die Autoren formalisieren zwei Kern-Angriffsklassen plus zwei adaptive Ausweichvarianten, bauen dann einen Forschungs-Proxy namens Mine, der „alle vier Angriffsklassen” (ihre Formulierung) gegen vier öffentliche Agenten-Frameworks implementiert, und evaluieren drei einsetzbare clientseitige Verteidigungen.¹ Wenn Ihr Agent einen Router verwendet, den Sie nicht selbst gebaut haben, haben Sie eine Vertrauensgrenze, die Sie nie auditiert haben.

Wichtigste Erkenntnisse

• Agenten-Betreiber: Jeder LLM API Router zwischen Ihrem Client und dem vorgelagerten Modell ist ein Proxy auf Anwendungsebene mit Klartextzugriff auf jede Anfrage und Antwort. Es wird keine kryptografische Integrität erzwungen. Wenn Sie einen Router verwenden, den Sie von einem Marktplatz gekauft oder aus einer öffentlichen Community-Liste bezogen haben, behandeln Sie ihn als feindlichen Vermittler, bis das Gegenteil bewiesen ist.
• Harness-Entwickler: Ihre PreToolUse-Hooks laufen vor der Tool-Ausführung, aber ein bösartiger Router modifiziert die Modellantwort nach der Generierung und bevor sie Ihren Hook erreicht. Fügen Sie Ihrem Hook-Stack eine antwortseitige Validierung hinzu und ziehen Sie Fail-Closed-Policy-Gates für anomale Antwortstrukturen in Betracht.
• Alle, die den YOLO-Modus nutzen: Vierhunderteins Sitzungen im Honeypot der Forscher liefen bereits im autonomen YOLO-Modus.¹ Ein Router, der Tool-Aufrufe in einer autonomen Sitzung modifiziert, hat einen viel größeren Schadensradius als ein Router, der eine Antwort modifiziert, die Sie lesen werden. Betreiben Sie den YOLO-Modus nicht über einen Router, den Sie nicht kontrollieren.

Was genau ist ein Router?

Im Kontext dieser Arbeit ist ein LLM API Router ein Drittanbieter-Dienst, der zwischen Ihrem Client und einem oder mehreren vorgelagerten Modellanbietern sitzt. Sie senden Anfragen an den Router über eine OpenAI-kompatible API. Der Router leitet diese Anfragen an den Upstream weiter, den er auswählt — GPT-5, Claude, Gemini, ein Open-Weights-Modell, einen Pool aus allen — und gibt die Antwort in derselben Form an Sie zurück.¹

Router existieren, weil das LLM-Ökosystem unübersichtlich ist. Die Leute wollen einen API-Schlüssel, der gegen jedes Modell funktioniert. Sie wollen Preisarbitrage — Token in großen Mengen einkaufen und billiger weiterverkaufen. Sie wollen geografische Umgehungslösungen für Regionen, in denen der direkte Anbieterzugriff eingeschränkt ist. Sie wollen mehrere Modelle mit einem einzigen Client testen. All das sind legitime Gründe, und ein gesunder Router-Markt bedient sie alle.

Das Problem ist, dass ein Router ein Proxy auf Anwendungsebene ist. Er leitet nicht einfach nur Bytes weiter. Er liest die Anfrage-JSON, wählt einen Upstream, schreibt die Anfrage optional um, leitet sie weiter, liest die Antwort, schreibt die Antwort optional um und gibt sie zurück. Jeder Schritt dieser Pipeline findet im Klartext auf der Infrastruktur des Routers statt.¹

Ein TLS-Äquivalent gibt es hier nicht. TLS schützt Bytes von Ihrem Client zum Router und vom Router zum vorgelagerten Modell. Es tut nichts, um die Payload vor dem Router zu schützen. Kein Anbieter erzwingt kryptografische Integrität zwischen dem ursprünglichen Client und dem endgültigen Modell — es gibt keine signierte Zusicherung, dass die Anfrage, die das Modell empfangen hat, mit der Anfrage übereinstimmt, die der Client gesendet hat, und keine signierte Zusicherung, dass die Antwort, die der Client empfangen hat, mit der Antwort übereinstimmt, die das Modell generiert hat.¹

Diese Abwesenheit ist die Angriffsfläche.

Die Felddaten

Die Forscher kauften 28 kostenpflichtige Router von drei Marktplätzen (Taobao, Xianyu, Shopify-gehostete Storefronts) und sammelten 400 kostenlose Router aus öffentlichen Communities. Sie ließen jeden Router eine Reihe von Probes mit instrumentierten Anfragen durchlaufen, die platzierte Zugangsdaten, bekannte Payloads und Marker-Strings enthielten.¹

Hier ist, was sie fanden:

Der Befund zur adaptiven Ausweichstrategie ist derjenige, der Sie nachts wach halten sollte. Ein adaptiver Ausweichauslöser bedeutet, dass der Router sich die meiste Zeit normal verhält und unter bestimmten Bedingungen in Angriffsverhalten umschaltet — einer bestimmten Anfragestruktur, einem bestimmten Client-Fingerabdruck, einer bestimmten Frequenz. Sie können ihn nicht durch zufälliges Sampling von Anfragen ertappen, weil der Router weiß, wann er gesampelt wird, und sich dann brav verhält.

Canary-Zugangsdaten sind Stolperdrähte: Sie werden ausgelöst, wenn jemand versucht, sie zu verwenden. Siebzehn Router, die sie „berührten”, bedeutet, dass mindestens siebzehn Router die Zugangsdaten aus den Payloads während der Übertragung extrahierten und versuchten, sie gegen AWS zu verwenden.¹ Das Abstract beschreibt nicht den genauen Mechanismus pro Router, aber das Stolperdraht-Design bedeutet: Berührung = Verwendung.

Der eine Router, der ETH von einem forscherseitig platzierten privaten Schlüssel abzog, ist ein stärkeres Ergebnis. Ein privater Schlüssel in einem Prompt ist kein Zugangsdaten-Stolperdraht — er ist ein Köder, der nur dann einen Kompromittierungsbeweis liefert, wenn der Router das Wallet tatsächlich leert. Ein Router tat genau das.¹

Die zwei Vergiftungsstudien

Die Forscher führten zwei zusätzliche Studien durch, um zu zeigen, dass scheinbar gutartige Router durch Drittanbieter-Exposition in dieselbe Angriffsfläche hineingezogen werden können.

Studie 1: Geleakter OpenAI-Schlüssel. Die Forscher leakten einen funktionierenden OpenAI-API-Schlüssel, als wäre er durch einen Entwicklerfehler offengelegt worden. Während des Beobachtungsfensters erzeugte dieser einzelne geleakte Schlüssel — laut Abstract — 100M GPT-5.4 Token und „mehr als sieben Codex-Sitzungen” über Router, die ihn aufgegriffen hatten.¹ Jemand — oder viele jemande — fand den Schlüssel, leitete Anfragen damit über Community-Router und verbrannte 100M Token an Rechenleistung. Der Router war eine Waschebene für einen gestohlenen Schlüssel.

Studie 2: Schwach konfigurierte Lockvögel. Die Forscher stellten schwach konfigurierte Lockvogel-Endpunkte bereit. Die Lockvögel lieferten 2B abgerechnete Token, 99 Zugangsdaten über 440 Codex-Sitzungen hinweg und — dies ist die entscheidende Zeile — 401 Sitzungen, die bereits im autonomen YOLO-Modus liefen.¹

Vierhunderteins autonome Sitzungen, die bereits über eine einzige Gruppe von Lockvögeln geleitet wurden. Jede einzelne dieser Sitzungen war eine aktive Angriffsfläche, auf der ein bösartiger Vermittler Tool-Aufrufe injizieren, Geheimnisse exfiltrieren oder die Ausgabe des Modells modifizieren konnte, und der Agent würde ohne Mensch im Loop auf alles reagieren, was zurückkam. Die Zahl 401 ist das, was ein Forschungs-Lockvogel fing — die operative Population, die über unkontrollierte Vermittler läuft, ist notwendigerweise größer.

Zwei Kern-Angriffsklassen und zwei adaptive Varianten

Die Arbeit formalisiert zwei Kern-Angriffsklassen und zwei adaptive Ausweichvarianten. Das Abstract ist in Bezug auf die Taxonomie explizit: AC-1 und AC-2 sind die Kernklassen; AC-1.a und AC-1.b sind Varianten von AC-1. Der Forschungs-Proxy Mine implementiert „alle vier Angriffsklassen” (Formulierung des Abstracts) gegen vier öffentliche Agenten-Frameworks.¹

AC-1: Payload-Injektion (Kernklasse). Der Router modifiziert die Antwort, um zusätzliche Anweisungen, Tool-Aufrufe oder Inhalte einzufügen, auf die der Client-Agent reagiert. Der Agent denkt, er liest Ausgabe vom Modell; tatsächlich liest er Ausgabe von demjenigen, dem der Router gehört.

AC-2: Geheimnis-Exfiltration (Kernklasse). Der Router liest Geheimnisse aus Anfragen und Antworten während der Übertragung heraus — API-Schlüssel, Token, private Schlüssel, alles, was wie ein Zugangsdatum aussieht — und verschickt sie an die Infrastruktur des Angreifers.

AC-1.a: Abhängigkeits-gezielte Injektion (adaptive Variante von AC-1). Die Injektion wird nur ausgelöst, wenn die Anfrage mit einer bestimmten Abhängigkeit oder einem bestimmten Kontext übereinstimmt — zum Beispiel nur, wenn die Anfrage eine bestimmte Bibliothek betrifft, nur wenn eine bestimmte Funktion referenziert wird, nur wenn bestimmte Dateipfade im Prompt vorkommen. Dadurch wird der Angriff bei Zufallstests unsichtbar.

AC-1.b: Bedingte Auslieferung (adaptive Variante von AC-1). Die bösartige Payload wird unter bestimmten Bedingungen ausgeliefert (Tageszeit, Anfragefrequenz, Client-Fingerabdruck). Dieselbe Logik zur Erkennungsumgehung.

Jede dieser Angriffsklassen ist sowohl für den Client als auch für das vorgelagerte Modell unsichtbar, weil beide Enden dem Router vertrauen. Der Client sieht eine normale Antwortstruktur. Das Modell sieht eine normale Anfragestruktur. Dem Router steht es frei, in der Mitte zu tun, was er will, und keine der beiden Parteien verfügt über einen kryptografischen Weg, Manipulationen zu erkennen.¹

Das Kompositionsmuster, eine Ebene tiefer

Ich schreibe immer wieder über denselben strukturellen Fehler: einzeln autorisierte Komponenten, die sich zu nicht autorisiertem Verhalten zusammensetzen. Trivy-zu-LiteLLM war Komposition auf Paketebene. Silent Egress war Komposition auf der Tool-Beschreibungsebene. MCP Tool Poisoning war Komposition auf Protokollebene. Die Kompromittierung des axios-Maintainers war Komposition auf der Human-Maintainer-Ebene.

Der Router-Angriff ist Komposition auf der Netzwerkebene. Ihr Client ist autorisiert, den Router aufzurufen. Der Router ist autorisiert, das vorgelagerte Modell aufzurufen. Das vorgelagerte Modell ist autorisiert zu antworten. Jeder einzelne Hop ist autorisiert. Die Komposition dieser autorisierten Hops produziert Payload-Injektion und Geheimnis-Exfiltration in großem Maßstab, weil die Komposition eine Vertrauensgrenze überschreitet, die niemand kryptografisch versiegelt hat.¹

Sie können das nicht auf einer einzelnen Ebene reparieren. Sie reparieren es auf der Kompositionsebene, was bedeutet, dass der Client den Router als feindlich behandeln muss, bis er unabhängig verifiziert hat, dass die Antwortstruktur, die Tool-Aufrufe und der Inhalt alle mit etwas übereinstimmen, das das vorgelagerte Modell plausibel produzieren würde.

Drei Verteidigungen, die die Arbeit evaluiert

Die Arbeit evaluiert drei clientseitige Verteidigungen gegen die Angriffsklassen.¹

1. Fail-closed Policy-Gate. Der Client erzwingt eine Richtlinie für Antwortstrukturen, erlaubte Tool-Aufrufe, erlaubte URLs, erlaubte Befehle. Alles außerhalb der Richtlinie schlägt geschlossen fehl — die Anfrage wird abgelehnt statt zugelassen.

2. Antwortseitige Anomalie-Prüfung. Der Client achtet auf Anomalien in der Antwortstruktur, ungewöhnliche Token-Muster oder Ausgaben, die bekannte Angriffsmarker enthalten (URLs zu unbekannten Hosts, verdächtige Zugangsdaten-Muster, ungewöhnliche Tool-Aufrufstrukturen).

3. Append-only Transparenz-Logging. Der Client schreibt jede Anfrage und Antwort in ein Append-only-Log, das rückwirkend nicht modifiziert werden kann. Das verhindert keine Angriffe, aber es macht sie forensisch nachvollziehbar.

Keine dieser Verteidigungen ist ein Allheilmittel. Meine Einschätzung: Das Fail-closed Policy-Gate ist die stärkste der drei, weil es sich nicht auf die Erkennung eines Angriffs verlässt — es weist alles außerhalb einer expliziten Allowlist zurück —, aber das Abstract bewertet die Verteidigungen nicht, betrachten Sie dies also als meine Meinung, nicht als Befund der Arbeit. Anomalie-Prüfung verpasst Angriffe, die normal aussehen, und die adaptiven Ausweichvarianten (AC-1.a und AC-1.b) sind speziell darauf ausgelegt, unter Testbedingungen normal auszusehen. Policy-Gates sind nur so gut wie die Richtlinie, und eine vollständige Richtlinie zu schreiben, „wie eine Modellantwort aussehen sollte”, ist schwer.

Was Sie tatsächlich tun sollten

Wenn Sie einen Agenten betreiben, der LLM APIs über einen Router aufruft, den Sie nicht selbst gebaut haben:

1. Verwenden Sie keine Router mehr, die Sie gekauft oder aus öffentlichen Communities bezogen haben, es sei denn, Sie vertrauen dem Betreiber. „Vertrauen” bedeutet hier, dass Sie eine externe Grundlage haben — ein bekanntes Team, einen unterzeichneten Vertrag, eine rechtliche Zuständigkeit, gegen die Sie vorgehen können — nicht „er hat gute Bewertungen auf einem Marktplatz”.

2. Fügen Sie Ihrem Harness ein Fail-closed Policy-Gate hinzu. In Claude Code bedeutet das PreToolUse-Hooks, die Tool-Aufrufe außerhalb einer expliziten Allowlist ablehnen, und PostToolUse-Hooks, die Antwortstrukturen validieren, bevor sie an den nächsten Modell-Turn weitergegeben werden. Der Hook-Stack ist Ihre Fail-closed Policy-Ebene.

3. Betreiben Sie den YOLO-Modus niemals über einen Router, den Sie nicht kontrollieren. Die 401 autonomen Sitzungen im Honeypot sind der Präzedenzfall. Wenn der Router feindlich ist und Ihre Sitzung autonom, dann betreibt der Router Ihre Maschine.

4. Loggen Sie alles. Append-only Transparenz-Logging ist das, was es Ihnen erlaubt, einen Vorfall zu rekonstruieren. Jede Anfrage. Jede Antwort. Jeden Tool-Aufruf. Speichern Sie sie an einem Ort, den der Router nicht erreichen kann.

5. Wenn Sie eine Agenten-Infrastruktur betreiben, erzwingen Sie kryptografische Integrität. Wenn Sie den Client und den Upstream betreiben, signieren Sie die Anfrage auf dem Client und verifizieren Sie die Signatur auf dem Upstream. Das ist die einzige echte Lösung. Der Router kann immer noch Klartext sehen, aber er kann nichts modifizieren, ohne die Signatur ungültig zu machen.

Die unangenehme Implikation

Die Router-Angriffsfläche ist ein klares Beispiel dafür, dass das Agenten-Ökosystem Infrastruktur schneller ausliefert, als es sie absichert. Die Leute wollen einen API-Schlüssel für jedes Modell. Sie wollen Preisarbitrage. Sie wollen regionalen Zugang. Router liefern all das. Der Markt belohnt sie. Der Sicherheits-Audit hat nicht stattgefunden.

Die MCP-Angriffsfläche hat 50 dokumentierte Schwachstellen. Die Supply-Chain-Angriffsfläche hat eine TeamPCP-Kampagne, die in einer Woche fünf Ökosysteme durchquert hat. Die Silent-Egress-Angriffsfläche hat Clinejection und den MCPTox-Benchmark. Fügen Sie nun die Router-Angriffsfläche hinzu: 428 untersuchte Router, 9 injizieren aktiv Schadcode, 17 berühren platzierte Zugangsdaten, 1 leert ETH, 401 autonome Sitzungen bereits live auf feindlicher Infrastruktur.¹

Das Muster ist jedes Mal dasselbe. Wir bauen eine neue Ebene des Agenten-Stacks. Die neue Ebene wird übernommen, bevor sie auditiert wird. Die Angreifer tauchen auf. Die Forscher tauchen auf. Die Community schreibt die Erkenntnisse auf. Die Betreiber, die aufmerksam waren, patchen ihre Deployments. Die Betreiber, die nicht aufmerksam waren, erfahren es auf die harte Tour.

Die Router-Angriffsfläche befindet sich in der Phase „Forscher haben es gerade aufgeschrieben”. Sie haben Zeit, Ihr Deployment zu patchen. Nutzen Sie sie.

FAQ

Was ist ein LLM API Router in diesem Kontext?

Ein Drittanbieter-Dienst, der zwischen Ihrem Client und vorgelagerten Modellanbietern sitzt, eine OpenAI-kompatible API bereitstellt und Ihre Anfragen an ein oder mehrere vorgelagerte Modelle weiterleitet. Er ist ein Proxy auf Anwendungsebene mit Klartextzugriff auf jede Anfrage und Antwort.¹

Warum ist das anders als ein CDN oder ein regulärer HTTP-Proxy?

Ein CDN leitet Bytes weiter, ohne die Anwendungs-Payload zu lesen. Ein LLM API Router liest die JSON, wählt einen Upstream, schreibt die Anfrage optional um, leitet sie weiter, liest die Antwort und schreibt die Antwort optional um. Er führt Verarbeitung auf Anwendungsebene an Ihren Daten durch, nicht nur Transport.¹

Schützt TLS mich vor einem bösartigen Router?

Nein. TLS schützt die Bytes von Ihrem Client zum Router und vom Router zum vorgelagerten Modell. Der Router terminiert TLS, liest den Klartext und verschlüsselt auf der anderen Seite neu. TLS tut nichts, um Ihre Payload vor dem Router zu schützen.¹

Wie würde ich einen Router erkennen, der aktiv Antworten injiziert?

Zuverlässig würden Sie das nicht, wenn der Router adaptive Ausweichstrategien einsetzt. Die Angriffsklassen AC-1.a und AC-1.b der Arbeit zielen speziell auf Erkennungsumgehung ab, indem sie nur unter operativen Bedingungen zünden.¹ Ihre beste Wahl ist ein Fail-closed Policy-Gate — alles außerhalb einer expliziten Allowlist abzulehnen — statt zu versuchen, Angriffe im Nachhinein zu erkennen.

Ich verwende Claude Code direkt gegen api.anthropic.com. Bin ich betroffen?

Nicht von der in dieser Arbeit beschriebenen Router-Angriffsklasse, weil Sie Anthropic direkt ohne Zwischenstation aufrufen. Die Angriffsfläche sind speziell Drittanbieter-Router. Wenn Sie Claude Code aus irgendeinem Grund über einen Proxy leiten — Corporate Gateway, Rate-Limit-Umgehung, Modell-Aggregator —, sollten Sie diesen Proxy auditieren.

Was ist mit OpenRouter, LiteLLM oder anderen bekannten Aggregatoren?

Die Arbeit untersucht 28 kostenpflichtige Router, die von bestimmten Marktplätzen (Taobao, Xianyu, Shopify-gehostete Storefronts) gekauft wurden, und 400 kostenlose Router aus öffentlichen Community-Listen.¹ Sie veröffentlicht keine konkrete Liste benannter Produkte. Der Punkt der Arbeit ist struktureller Natur: Jeder Router ist ein nicht vertrauenswürdiger Vermittler, es sei denn, Sie haben eine separate Vertrauensbasis. Bekannte Aggregatoren sind nicht automatisch sicherer — sie sind lediglich sichtbarer, was eine andere Eigenschaft ist.

Was sollte ich bezüglich der 401 autonomen Sitzungen tun, die die Forscher gefunden haben?

Diese Sitzungen gehören zu anderen Betreibern, die ihren Datenverkehr über die Lockvögel der Forscher geleitet haben. Wenn Sie autonome Agenten-Sitzungen über irgendeinen Router betreiben, den Sie nicht selbst gebaut haben, ist der erste Schritt anzuhalten. Der zweite Schritt ist, jedes Zugangsdatum zu rotieren, das durch diesen Router gereist ist. Der dritte Schritt ist, Ihre Sitzungs-Logs auf anomale Tool-Aufrufe oder Ausgaben zu auditieren.

Referenzen