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 versahen Anfragen mit platzierten Credentials und prüften jeden Router darauf, was er mit dem Datenverkehr machte.¹

Siebzehn dieser Router griffen auf AWS-Canary-Credentials zu, die in den Anfragen platziert waren. Einer leerte ETH von einem als Köder hinterlegten Private Key. Ein durchgesickerter OpenAI-Schlüssel, den das Team als Honeypot eingerichtet hatte, generierte 100 Mio. GPT-5.4-Tokens und laut Abstract „mehr als sieben Codex-Sitzungen”, bevor sie ihn zurückzogen.¹ Separate, schwach konfigurierte Köder lieferten 2 Mrd. abgerechnete Tokens, 99 Credentials über 440 Codex-Sitzungen und 401 Sitzungen, die bereits im autonomen YOLO-Modus liefen.¹

Der LLM API-Router ist die neue Angriffsfläche. Niemand prüft ihn.

MCP-Vertrauensketten sind die Reihe von Zwischeninstanzen (API-Router, Proxys und Tool-Server), die zwischen Ihrem KI-Agenten und dem nachgelagerten Modell sitzen, jeweils mit vollem Klartextzugriff auf jede Anfrage und jede Antwort. Kein Anbieter erzwingt kryptografische Integrität von Ende zu Ende, was bedeutet, dass jede Zwischeninstanz Daten während der Übertragung lesen, ändern oder exfiltrieren kann. Feldforschung ergab, dass 17 von 28 kostenpflichtigen Routern auf platzierte AWS-Credentials zugriffen und einer ETH von einem Private Key leerte, was zeigt, dass ungeprüfte Glieder der Vertrauenskette aktive Angriffsflächen sind.

TL;DR

Drittanbieter-LLM API-Router sind Proxys auf Anwendungsebene mit vollem Klartextzugriff auf jede JSON-Payload, die zwischen Ihrem Agenten und dem nachgelagerten Modell unterwegs ist. Kein Anbieter erzwingt kryptografische Integrität zwischen Client und Upstream. Eine neue arxiv-Veröffentlichung von Liu, Shou, Wen, Chen und Fang präsentiert die erste systematische Studie zu dieser Angriffsfläche, und die Felddaten sind hässlich: 1 von 28 kostenpflichtigen Routern und 8 von 400 kostenlosen Routern injizierten aktiv bösartigen Code in Antworten, 2 setzten adaptive Umgehungs-Trigger ein, 17 griffen auf platzierte AWS-Canary-Credentials zu, und 1 leerte ETH von einem platzierten Private Key.¹ Die Autoren formalisieren zwei zentrale Angriffsklassen plus zwei adaptive Umgehungsvarianten und entwickeln 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 geprüft haben.

Wichtigste Erkenntnisse

• Agenten-Betreiber: Jeder LLM API-Router zwischen Ihrem Client und dem nachgelagerten Modell ist ein Proxy auf Anwendungsebene mit Klartextzugriff auf jede Anfrage und jede Antwort. Kein Anbieter erzwingt kryptografische Integrität. Wenn Sie einen Router auf einem Marktplatz gekauft oder aus einer öffentlichen Community-Liste gezogen haben, behandeln Sie ihn als feindselige Zwischeninstanz, bis Sie ihn unabhängig verifiziert haben.
• 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 antwortseitige Validierung zu Ihrem Hook-Stack hinzu und ziehen Sie Fail-Closed-Policy-Gates für anomale Antwortformen in Betracht.
• Alle, die im YOLO-Modus arbeiten: 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 Wirkungsradius 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 ist eigentlich ein Router?

Im Kontext dieser Veröffentlichung ist ein LLM API-Router ein Drittanbieter-Service, der zwischen Ihrem Client und einem oder mehreren nachgelagerten Modell-Anbietern sitzt. Sie senden Anfragen an den Router über eine OpenAI-kompatible API. Der Router leitet diese Anfragen an den von ihm gewählten Upstream weiter (GPT-5, Claude, Gemini, ein Open-Weights-Modell, einen Pool aus all diesen) und gibt die Antwort in derselben Form an Sie zurück.¹

Router existieren, weil das LLM-Ökosystem unübersichtlich ist. Die Leute wollen einen einzigen API-Schlüssel, der gegen jedes Modell funktioniert. Die Leute wollen Preisarbitrage: Tokens in großen Mengen kaufen und sie billiger weiterverkaufen. Die Leute wollen geografische Workarounds für Regionen, in denen der direkte Anbieterzugang eingeschränkt ist. Die Leute 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 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 geschieht im Klartext auf der Infrastruktur des Routers.¹

Es gibt hier kein TLS-Äquivalent. TLS schützt Bytes von Ihrem Client zum Router und vom Router zum nachgelagerten 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 letztlich angesprochenen Modell. Es existiert keine signierte Zusicherung, dass die Anfrage, die das Modell erhalten hat, dieselbe ist wie die vom Client gesendete, und keine signierte Zusicherung, dass die Antwort, die der Client erhalten hat, dieselbe ist wie die vom Modell generierte.¹

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 Sondierungen mit instrumentierten Anfragen durchlaufen, die platzierte Credentials, bekannte Payloads und Marker-Strings enthielten.¹

Hier ist, was sie fanden:

Der Befund zur adaptiven Umgehung ist derjenige, der Sie wachhalten sollte. Ein adaptiver Umgehungs-Trigger bedeutet, dass sich der Router die meiste Zeit normal verhält und unter bestimmten Bedingungen in Angriffsverhalten umschaltet: bei einer bestimmten Anfrageform, einem bestimmten Client-Fingerprint, einer bestimmten Kadenz. Sie können ihn nicht durch das Sampling zufälliger Anfragen erwischen, weil der Router weiß, wann er beprobt wird, und sich dann unauffällig verhält.

Canary-Credentials sind Stolperdrähte: Sie lösen aus, wenn jemand versucht, sie zu verwenden. Wenn siebzehn Router sie „berührten”, bedeutet das, dass mindestens siebzehn Router die Credentials aus laufenden Payloads extrahiert und versucht haben, sie gegen AWS einzusetzen.¹ Das Abstract beschreibt nicht den genauen Mechanismus pro Router, aber das Stolperdraht-Design bedeutet: Berührung = Verwendung.

Der eine Router, der ETH von einem forschereigenen Private Key leerte, ist ein noch stärkerer Befund. Ein Private Key in einem Prompt ist kein Credential-Stolperdraht; er ist ein Köder, der nur dann Beweise für eine Kompromittierung liefert, wenn der Router das Wallet tatsächlich leert. Ein Router tat es.¹

Die zwei Vergiftungs-Studien

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

Studie 1: Durchgesickerter OpenAI-Schlüssel. Die Forscher ließen einen funktionierenden OpenAI-API-Schlüssel durchsickern, als wäre er durch einen Entwicklerfehler offengelegt worden. Während des Beobachtungszeitraums generierte dieser einzelne durchgesickerte Schlüssel laut Abstract 100 Mio. GPT-5.4-Tokens und „mehr als sieben Codex-Sitzungen” über Router, die ihn aufnahmen.¹ Jemand (oder viele Personen) fand den Schlüssel, leitete Anfragen damit über Community-Router und verbrannte 100 Mio. Tokens an Rechenleistung. Der Router war eine Geldwäsche-Schicht für einen gestohlenen Schlüssel.

Studie 2: Schwach konfigurierte Köder. Die Forscher richteten schwach konfigurierte Köder-Endpunkte ein. Die Köder lieferten 2 Mrd. abgerechnete Tokens, 99 Credentials über 440 Codex-Sitzungen und, kritisch, 401 Sitzungen, die bereits im autonomen YOLO-Modus liefen.¹

Vierhunderteins autonome Sitzungen, die bereits über einen einzigen Satz von Ködern geleitet wurden. Jede dieser Sitzungen war eine aktive Angriffsfläche, auf der eine bösartige Zwischeninstanz Tool-Aufrufe injizieren, Geheimnisse exfiltrieren oder die Modellausgabe modifizieren konnte, und der Agent würde alles ausführen, was zurückkam, ohne dass ein Mensch in der Schleife wäre. Die Zahl 401 ist das, was ein Forschungsköder erfasst hat. Die operative Population, die durch unkontrollierte Zwischeninstanzen geleitet wird, ist zwangsläufig größer.

Zwei zentrale Angriffsklassen und zwei adaptive Varianten

Die Veröffentlichung formalisiert zwei zentrale Angriffsklassen und zwei adaptive Umgehungsvarianten. Das Abstract ist explizit zur Taxonomie: AC-1 und AC-2 sind die zentralen Klassen; 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 (zentrale Klasse). Der Router modifiziert die Antwort, um zusätzliche Anweisungen, Tool-Aufrufe oder Inhalte zu injizieren, auf die der Client-Agent reagiert. Der Agent denkt, er liest Output vom Modell; er liest Output von dem, der den Router besitzt.

AC-2: Geheimnis-Exfiltration (zentrale Klasse). Der Router liest Geheimnisse aus laufenden Anfragen und Antworten heraus (API-Schlüssel, Tokens, Private Keys, alles, was nach einem Credential aussieht) und schickt sie an die Infrastruktur des Angreifers.

AC-1.a: Abhängigkeitsgezielte Injektion (adaptive Variante von AC-1). Die Injektion löst nur aus, wenn die Anfrage einer bestimmten Abhängigkeit oder einem bestimmten Kontext entspricht: nur wenn die Anfrage eine bestimmte Bibliothek betrifft, nur wenn eine bestimmte Funktion referenziert wird, nur wenn bestimmte Dateipfade im Prompt erscheinen. Der selektive Auslöser macht den Angriff bei zufälligen Tests unsichtbar.

AC-1.b: Bedingte Auslieferung (adaptive Variante von AC-1). Der Router liefert die bösartige Payload nur unter bestimmten Bedingungen aus (Tageszeit, Anfrage-Kadenz, Client-Fingerprint). Dieselbe Erkennungsumgehungs-Logik.

Jede dieser Angriffsklassen ist für den Client und das nachgelagerte Modell unsichtbar, weil beide Enden dem Router vertrauen. Der Client sieht eine normale Antwortform. Das Modell sieht eine normale Anfrageform. Der Router kann in der Mitte tun, was er will, und keine der beiden Parteien hat eine kryptografische Möglichkeit, Manipulationen zu erkennen.¹

Das Kompositionsmuster, eine Schicht tiefer

Ich schreibe immer wieder über denselben strukturellen Bug: einzeln autorisierte Komponenten, die sich zu unautorisiertem Verhalten zusammensetzen. Trivy-zu-LiteLLM war Komposition auf Paket-Ebene. Silent Egress war Komposition auf der Tool-Beschreibungs-Ebene. MCP-Tool-Vergiftung war Komposition auf der Protokoll-Ebene. Die Kompromittierung des axios-Maintainers war Komposition auf der Ebene menschlicher Maintainer.

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

Sie können das auf keiner einzelnen Schicht beheben. Sie beheben es auf der Kompositionsschicht, was bedeutet, dass der Client den Router als feindselig behandeln muss, bis er unabhängig verifiziert hat, dass die Antwortform, die Tool-Aufrufe und die Inhalte alle konsistent mit etwas sind, das das nachgelagerte Modell plausibel produzieren würde.

Drei Verteidigungen, die die Veröffentlichung evaluiert

Die Veröffentlichung evaluiert drei clientseitige Verteidigungen gegen die Angriffsklassen.¹

1. Fail-Closed-Policy-Gate. Der Client erzwingt eine Policy für Antwortformen, erlaubte Tool-Aufrufe, erlaubte URLs und erlaubte Befehle. Alles außerhalb der Policy schlägt geschlossen fehl: Der Client lehnt die Anfrage ab, statt sie zuzulassen.

2. Antwortseitiges Anomalie-Screening. Der Client überwacht Anomalien in der Antwortform, ungewöhnliche Token-Muster oder Output, der bekannte Angriffs-Marker enthält (URLs zu unbekannten Hosts, verdächtige Credential-Muster, ungewöhnliche Tool-Aufruf-Strukturen).

3. Append-only-Transparenz-Logging. Der Client schreibt jede Anfrage und jede Antwort in ein Append-only-Log, das niemand nachträglich modifizieren kann. Logging verhindert keine Angriffe, macht sie aber forensisch nachvollziehbar.

Keine davon ist eine Wunderwaffe. Meine Lesart: Das Fail-Closed-Policy-Gate ist die stärkste der drei, weil es alles außerhalb einer expliziten Allowlist ablehnt, statt zu versuchen, einen Angriff zu erkennen, aber das Abstract bewertet die Verteidigungen nicht, also behandeln Sie das als meine Meinung, nicht als Befund der Veröffentlichung. Anomalie-Screening übersieht Angriffe, die normal aussehen, und die adaptiven Umgehungsvarianten (AC-1.a und AC-1.b) imitieren gezielt normales Verhalten unter Testbedingungen. Policy-Gates sind nur so gut wie die Policy, und eine vollständige Policy dafür 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. Hören Sie auf, Router zu verwenden, die Sie auf Marktplätzen gekauft oder aus öffentlichen Communities gezogen haben, es sei denn, Sie vertrauen dem Betreiber. „Vertrauen” bedeutet hier, dass Sie eine externe Grundlage haben (ein bekanntes Team, einen unterzeichneten Vertrag, eine durchsetzbare Rechtsordnung), nicht „er hat gute Bewertungen auf einem Marktplatz”.

2. Fügen Sie ein Fail-Closed-Policy-Gate zu Ihrem Harness hinzu. In Claude Code bedeutet das PreToolUse-Hooks, die Tool-Aufrufe außerhalb einer expliziten Allowlist ablehnen, und PostToolUse-Hooks, die Antwortformen validieren, bevor sie an die nächste Modellrunde weitergegeben werden. Der Hook-Stack ist Ihre Fail-Closed-Policy-Schicht.

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 feindselig ist und Ihre Sitzung autonom, 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. Jeder 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 betreiben 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 unbequeme 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. Die Leute wollen Preisarbitrage. Die Leute wollen regionalen Zugang. Router liefern all das. Der Markt belohnt sie. Das Sicherheits-Audit hat nicht stattgefunden.

Die MCP-Angriffsfläche hat 50 dokumentierte Schwachstellen. Die Lieferketten-Angriffsfläche hat eine TeamPCP-Kampagne, die in einer Woche fünf Ökosysteme durchquerte. Die Silent-Egress-Angriffsfläche hat Clinejection und den MCPTox-Benchmark. Fügen Sie nun die Router-Angriffsfläche hinzu: 428 untersuchte Router, 9 mit aktiver Code-Injektion, 17 griffen auf platzierte Credentials zu, 1 leerte ETH, 401 autonome Sitzungen bereits aktiv auf feindseliger Infrastruktur.¹

Das Muster ist jedes Mal dasselbe. Wir bauen eine neue Schicht des Agenten-Stacks. Entwickler übernehmen die neue Schicht, bevor sie jemand prüft. Die Angreifer tauchen auf. Die Forscher tauchen auf. Die Community schreibt die Befunde auf. Die Betreiber, die aufgepasst haben, patchen ihre Deployments. Die Betreiber, die nicht aufgepasst haben, finden es auf die harte Tour heraus.

Die Router-Angriffsfläche ist im Stadium „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-Service, der zwischen Ihrem Client und nachgelagerten Modell-Anbietern sitzt, eine OpenAI-kompatible API bereitstellt und Ihre Anfragen an ein oder mehrere nachgelagerte Modelle weiterleitet. Es ist ein Proxy auf Anwendungsebene mit Klartextzugriff auf jede Anfrage und jede Antwort.¹

Warum unterscheidet sich das von einem CDN oder einem regulären 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 mit Ihren Daten durch, nicht nur Transport.¹

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

Nein. TLS schützt die Bytes von Ihrem Client zum Router und vom Router zum nachgelagerten 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?

Sie würden es nicht zuverlässig erkennen, wenn der Router adaptive Umgehung verwendet. Die Angriffsklassen AC-1.a und AC-1.b der Veröffentlichung zielen gezielt auf Erkennungsumgehung ab, indem sie nur unter operativen Bedingungen auslösen.¹ Ihre beste Option ist ein Fail-Closed-Policy-Gate, das alles außerhalb einer expliziten Allowlist ablehnt, statt zu versuchen, Angriffe nachträglich zu erkennen.

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

Nicht von der in dieser Veröffentlichung beschriebenen Router-Angriffsklasse, weil Sie Anthropic direkt ohne Zwischeninstanz aufrufen. Die Angriffsfläche sind speziell Drittanbieter-Router. Wenn Sie Claude Code aus irgendeinem Grund über einen Proxy leiten (Unternehmens-Gateway, Rate-Limit-Umgehung, Modell-Aggregator), sollten Sie diesen Proxy prüfen.

Was ist mit OpenRouter, LiteLLM oder anderen bekannten Aggregatoren?

Die Veröffentlichung 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 spezifische Liste namentlich genannter Produkte. Der Punkt der Veröffentlichung ist strukturell: Jeder Router ist eine nicht vertrauenswürdige Zwischeninstanz, es sei denn, Sie haben eine separate Vertrauensgrundlage. Bekannte Aggregatoren sind nicht automatisch sicherer; sie sind lediglich sichtbarer, was eine andere Eigenschaft ist.

Was sollte ich wegen der 401 autonomen Sitzungen tun, die die Forscher gefunden haben?

Diese Sitzungen gehören anderen Betreibern, die ihren Datenverkehr durch die Köder der Forscher geleitet haben. Wenn Sie autonome Agenten-Sitzungen über einen Router laufen lassen, den Sie nicht selbst gebaut haben, ist der erste Schritt: aufhören. Der zweite Schritt ist, jedes Credential zu rotieren, das durch diesen Router gewandert ist. Der dritte Schritt ist, Ihre Sitzungs-Logs auf anomale Tool-Aufrufe oder Output zu prüfen.

Quellenangaben