Ihr KI-Agent wird über gestohlene Tokens gekapert, nicht Prompts

Ein KI-Agent hat kein Passwort, das ein Angreifer abphishen könnte. Er hat etwas Schlimmeres: ein langlebiges Token, das er bei jedem Aufruf an Ihre E-Mails, Ihre Repositories, Ihre Cloud und Ihre Datenbanken vorzeigt. Wer dieses Token stiehlt, braucht weder das Passwort noch den zweiten Faktor noch den Agenten selbst. Er spielt einfach die Session erneut ab, und jedes System, das der Agent erreichen konnte, begrüßt ihn als den Agenten. Der größte Zugangsdaten-Dump des Jahres 2026, rund sechzehn Milliarden aus Infostealer-Logs zusammengesetzte Datensätze, drehte sich nie wirklich um Passwörter. Er drehte sich um Sessions. Und die am wenigsten beobachtete, am stärksten privilegierte Session in Ihrem Stack ist die, die Ihr Agent hält.

Das ist die Angriffsklasse, die in keinem Prompt-Injection-Bedrohungsmodell und in keiner Modell-Evaluierung auftaucht, weil das Modell gar nicht beteiligt ist. Niemand jailbreakt den Agenten. Niemand bastelt eine bösartige Anweisung. Ein Infostealer auf einem Entwickler-Laptop oder eine vergiftete Abhängigkeit auf einem Build-Server hebt ein Token aus dem Speicher oder von der Festplatte, und die Identität des Agenten spaziert unversehrt zur Tür hinaus. Hier steht, warum Agenten das perfekte Opfer sind, was 2026 bereits passiert ist und welche Kontrollen tatsächlich wirken, sobald Sie akzeptieren, dass das Token das eigentliche Ziel ist.

Das Passwort ist nicht mehr das Ziel

Angreifer sind eine Ebene höher gewandert. Die gestohlene Einheit ist nicht mehr das Passwort, sondern die authentifizierte Session: das Cookie oder Bearer-Token, das beweist, dass der Login bereits erfolgt ist. Dieses Artefakt lebt über die Multi-Faktor-Abfrage hinaus, sein Diebstahl überspringt die Authentifizierung also komplett. Die Sammlung aus sechzehn Milliarden Datensätzen, die im Juni 2026 Schlagzeilen machte, war ein Haufen Infostealer-Output, und Infostealer-Logs erfassen neben den Passwörtern auch Session-Cookies und Zugriffstokens, und genau das ist der Teil, auf den es ankommt.

Deshalb wird Multi-Faktor-Authentifizierung laufend umgangen, ohne dass jemand den zweiten Faktor anrührt. Ein Adversary-in-the-Middle-Proxy oder Schadsoftware, die ein Token vom Host liest, fängt die laufende Session ab und spielt sie erneut ab. Der Login ist längst geschehen. Das Token ist gültig. Detektionssysteme, die auf fehlgeschlagene Logins oder Passwortwechsel achten, sehen nichts, weil nichts fehlschlug und nichts sich änderte. Für einen Menschen ist das schlimm. Für einen Agenten ist es der Normalzustand.

Ihr KI-Agent ist das perfekte Opfer

Ein KI-Agent bündelt alles, was ein Angreifer will, in einer einzigen Identität. Er authentifiziert sich einmal und hält seine Zugangsdaten so lange, wie der Prozess läuft. Er trägt breite Berechtigungen, weil niemand einen autonomen Ablauf für eine erneute Zustimmung unterbrechen will. Er läuft unbeaufsichtigt, oft auf einem Server, ohne dass jemand zusieht, wenn die Session um drei Uhr nachts genutzt wird. Und er spricht mit vielen Systemen gleichzeitig, ein gestohlenes Token ist also nicht ein Konto, sondern der Wirkungsradius jedes Werkzeugs, an das der Agent angebunden war.

Vergleichen Sie das mit einer menschlichen Session. Ein Mensch loggt sich ein, arbeitet, klappt den Laptop zu, und die Session wird untätig, sodass es verdächtig aussieht, wenn sie plötzlich aus einem anderen Land wieder erwacht. Die Session eines Agenten soll ständig feuern, von einer Rechenzentrums-IP, gegen Dutzende Endpunkte. Die Verhaltensbasis, die ein gekapertes Menschenkonto auffliegen lässt, ist genau das Verhalten, das ein gesunder Agent erzeugt, ein gekaperter Agent versteckt sich also in seinem eigenen Normalverkehr. Wie in jeder KI-Agent ist eine nicht-menschliche Identität beschrieben, ist der Agent ein Konto mit Zugangsdaten, und absichern muss man das Konto, nicht das Modell.

Das ist 2026 bereits passiert

Der Token-Angriff auf Agenten ist nicht theoretisch, er traf dieses Jahr echte Werkzeuge. 2026 zeigten Forscher von Mitiga, dass sich die OAuth-Tokens von Claude Code über eine heimliche Umleitung des Model-Context-Protocol-Verkehrs stehlen lassen: ein klassischer Man-in-the-Middle, der das Token abfängt und dauerhaften Zugriff auf alles behält, womit der Assistent verbunden war. Das Modell wurde nie getäuscht. Der Transportweg schon.

• Die LiteLLM-Hintertür. Im März 2026 schleusten zwei bösartige Releases von LiteLLM, einem Proxy mit rund fünfundneunzig Millionen monatlichen Downloads, AWS-Tokens, GCP-Zugangsdaten, SSH-Schlüssel und Kubernetes-Konfigurationen von jeder Maschine aus, die sie installierte. Die vergifteten Versionen lagen etwa vierzig Minuten auf PyPI und wurden in diesem Fenster rund siebenundvierzigtausend Mal gezogen. Jede Installation übergab die Schlüssel ihrer Agenten-Infrastruktur an einen Fremden.
• Secrets-Wildwuchs in MCP-Konfigurationen. Im ersten Jahr der breiten Nutzung des Protokolls fanden Forscher mehr als vierundzwanzigtausend einzigartige Secrets in Model-Context-Protocol-Konfigurationsdateien. Das sind langlebige Tokens, im Klartext auf die Festplatte geschrieben, die auf den ersten Infostealer warten, der das Verzeichnis ausliest.
• Agenten-Missbrauch über den ganzen Lebenszyklus. Zwischen Dezember 2025 und Januar 2026 nutzte ein einzelner Akteur einen KI-Assistenten und dessen Werkzeuge über einen gesamten Einbruch hinweg, um sechs Behörden zu kompromittieren, was das Weltwirtschaftsforum als erste bestätigte KI-orchestrierte Spionagekampagne bezeichnete. Der Agent war die Hand des Angreifers, und sein Zugang war die Beute.

Das sind keine Modellfehler, das sind Zugangsdaten-Fehler im KI-Kostüm. OWASP gab der Kategorie in seiner Agentic Security Initiative den Namen ASI03, Identitäts- und Privilegienmissbrauch, genau weil der stehende Zugang des Agenten das Stehlenswerte ist.

MFA war nie die Kontrolle des Agenten

Multi-Faktor-Authentifizierung schützt ein Login-Ereignis, das ein Mensch ausführt, der auf ein Telefon tippen kann. Ein Agent hat kein Telefon und führt keinen interaktiven Login aus: Er liest ein Token aus einem Secret-Store oder einer Umgebungsvariablen und legt es vor. Der Faktor wurde einmal erfüllt, von demjenigen, der die Zugangsdaten bereitstellte, und danach nie wieder. Wenn Teams also auf Zugangsdaten-Diebstahl mit „wir fügen MFA hinzu“ reagieren, härten sie die eine Tür, die der Agent nicht benutzt, und lassen das Bearer-Token, die Tür, die er tatsächlich benutzt, auf der Festplatte liegen.

Die ehrliche Einordnung ist unbequem: Für eine nicht-menschliche Identität ist Multi-Faktor-Authentifizierung nahezu bedeutungslos. Worauf es ankommt, ist, wie kurzlebig das Token ist, wie eng es eingegrenzt ist, wo es gespeichert wird und ob irgendetwas bemerkt, wenn es vom falschen Ort aus genutzt wird. Das sind die Hebel, und kaum jemand zieht sie, weil der Agent mit einem statischen Schlüssel „einfach funktioniert“ und Ausliefern über Härten gewinnt. Es ist dieselbe Lehre wie beim Zähmen eines Coding-Agenten: Die Gefahr ist der stehende Zugang, nicht die Absicht.

Warum gerätegebundene Cookies den Agenten nicht retten

Die Browser-Welt hat eine echte Antwort auf Session-Diebstahl: Device Bound Session Credentials, die Google 2026 in Chrome 146 unter Windows allgemein verfügbar machte. DBSC bindet eine Session an einen nicht exportierbaren privaten Schlüssel im Trusted Platform Module der Maschine, und der Browser signiert alle paar Minuten eine frische Aufgabe, um zu beweisen, dass das ursprüngliche Gerät noch vorhanden ist. Ein gestohlenes Cookie wird auf einer anderen Maschine wertlos, weil es diese Signatur nicht erzeugen kann.

Das ist hervorragend für menschliches Browsen und fast nutzlos für einen kopflosen Agenten. DBSC setzt einen interaktiven Browser, ein TPM und eine Nutzer-Session voraus. Agenten laufen serverseitig, in Containern, über kurzlebige Hosts, die womöglich kein durchgängiges Secure Element haben, und sie authentifizieren sich Maschine zu Maschine, wo das „Gerät“ eine Flotte ist, kein Laptop. Die Verteidigung, die menschliche Sessions rettet, lässt sich nicht sauber auf den Ort übertragen, an dem sich das Risiko ballt. Schlimmer noch: Wie ein Forscher nach dem DBSC-Start trocken anmerkte, drängt die Gerätebindung Angreifer dazu, statt das Cookie zu stehlen eine versteckte Remote-Sitzung auf dem Host des Opfers zu fahren, sodass die laufende Session selbst zum Ziel wird. Für Agenten lautet das Äquivalent schlicht: die Maschine übernehmen und das Token an Ort und Stelle nutzen.

So schützen Sie die Session eines Agenten wirklich

Behandeln Sie die Zugangsdaten des Agenten als Kronjuwel, denn für einen Angreifer sind sie genau das. Das Ziel ist, ein gestohlenes Token schnell ablaufen zu lassen, ihm wenig Reichweite zu geben und einen Alarm auszulösen, wenn es falsch genutzt wird. Nichts davon braucht ein besseres Modell. Es braucht, dass Sie den Agenten als privilegiertes Dienstkonto behandeln, denn das ist er.

• Kurzlebige Tokens, keine statischen Schlüssel. Geben Sie Zugangsdaten aus, die Minuten leben, nicht Monate, von einem Broker, den der Agent zur Laufzeit aufruft. Ein Token, das bereits abgelaufen ist, wenn ein Infostealer es nach Hause schickt, ist nichts wert.
• Auf die eine Aufgabe begrenzen. Eine Identität pro Agent, ein Satz Rechte pro Aufgabe, kein geteilter God-Mode-Schlüssel über eine Flotte hinweg. Ein gestohlenes Token sollte ein Postfach oder ein Repository öffnen, nicht den ganzen Bestand.
• Egress standardmäßig verbieten. Ein Agent, der nur die drei Endpunkte erreicht, die er braucht, kann ein gestohlenes Token oder gestohlene Daten nirgendwo sonst hinschicken. Egress-Kontrolle macht aus einer vollen Kompromittierung eine eingegrenzte.
• Die Session beobachten, nicht den Login. Erfassen Sie eine Basislinie, wo, wann und wie das Token des Agenten genutzt wird, und alarmieren Sie bei der Abweichung: ein neues ASN, eine seltsame Uhrzeit, ein Werkzeug, das er nie aufruft. Die Übernahme zeigt sich in der Nutzung, nie in einem fehlgeschlagenen Login.
• Secrets aus Dateien heraushalten. Keine Tokens in MCP-Konfigurationen, Umgebungs-Dumps oder der Repository-Historie. Holen Sie sie zur Nutzung aus einem Vault, damit nichts auf der Festplatte liegt, das Schadsoftware auslesen kann.

Der Wechsel der Denkweise ist das ganze Spiel. Hören Sie auf zu fragen, ob das Modell getäuscht werden kann, und fragen Sie, was passiert, wenn das Token des Agenten in fremden Händen ist, denn im Jahr von sechzehn Milliarden gestohlenen Sessions ist das der wahrscheinliche Fall, nicht der Ausnahmefall. Zum größeren Muster siehe selbst-gehostete KI-Infrastruktur absichern und warum Prompt Injection sich nicht wegpatchen lässt, denn beides läuft auf Kontrollen außerhalb des Modells hinaus.

Weiterführende Lektüre

• Jeder KI-Agent ist eine nicht-menschliche Identität. Schluss mit God-Mode.
• Prompt Injection hat jetzt eine Zahl: 31,5 % Agenten-Hijack
• Selbst-gehostete KI absichern: Infrastruktur härten
• Selbst-gehostete KI vs. Cloud-APIs: Kosten, Datenschutz, Kontrolle