Token-Diebstahl und Replay-Angriffe gegen KI-Agenten: Wie Anmeldedaten lecken und wie Sie den Schaden eingrenzen

Ein KI-Agent ist kein Mensch, der sich einmal am Morgen anmeldet. Er ist ein Prozess, der im Sekundentakt fremde APIs aufruft, Tokens zwischen Diensten weiterreicht und oft mit weitreichenden Berechtigungen ausgestattet ist. Genau das macht seine Anmeldedaten zu einem lohnenden Ziel. Wird ein Token gestohlen, kann ein Angreifer im Namen des Agenten handeln, ohne je ein Passwort zu kennen oder einen zweiten Faktor zu überwinden.

Was ist Token-Diebstahl bei KI-Agenten und warum ist er so gefährlich?

Token-Diebstahl bedeutet, dass ein Angreifer ein gültiges Zugriffstoken oder Refresh-Token eines Agenten erbeutet und es anschließend selbst gegenüber einer API oder einem Ressourcen-Server vorzeigt. Beim Replay-Angriff spielt der Angreifer dieses abgefangene Token einfach erneut ein. Der Server sieht ein technisch korrektes Token und gewährt Zugriff, weil er nicht unterscheiden kann, ob der legitime Agent oder ein Dieb es vorzeigt. Die wirksamste Gegenmaßnahme ist die Token-Bindung (Sender-Constraining): Das Token wird kryptografisch an einen Schlüssel des rechtmäßigen Clients gebunden, sodass ein gestohlenes Token ohne den zugehörigen privaten Schlüssel nutzlos ist.

Die Gefahr ist bei Agenten größer als bei klassischen Webanwendungen, weil drei Faktoren zusammenkommen. Erstens laufen Agenten autonom: Es gibt keinen Menschen, der eine ungewöhnliche Anmeldung bemerkt und stutzig wird. Zweitens sind Agenten oft überprivilegiert, weil Entwickler ihnen aus Bequemlichkeit breite Scopes zuweisen. Drittens bewegen sich Tokens in Agenten-Architekturen ständig zwischen Komponenten, durch Prompts, durch Tool-Aufrufe und durch Protokolle wie das MCP, und jede dieser Stationen ist eine mögliche Schwachstelle, an der ein Token nach außen gelangen kann.

Wie gelangen die Anmeldedaten eines Agenten überhaupt nach außen?

Dass die Anmeldedaten eines Agenten nach außen gelangen, ist selten die Folge eines spektakulären Einbruchs. Meist sind es alltägliche Konstruktionsfehler, die ein Token aus seinem geschützten Kontext heraustragen.

Der häufigste Pfad ist das Logging. Agenten protokollieren ihre HTTP-Aufrufe zur Fehlersuche, und allzu oft landet der vollständige Authorization-Header inklusive Bearer-Token im Klartext im Log. Wer Zugriff auf die Log-Pipeline, auf einen zentralen Logserver oder auf ein angebundenes Observability-Werkzeug hat, liest die Tokens direkt mit.

Ein zweiter Pfad führt über die Prompt-Schicht. Wenn ein Token in den Kontext des Sprachmodells gerät, etwa weil es Teil einer Systemnachricht oder eines Tool-Ergebnisses ist, kann eine Prompt Injection das Modell dazu bringen, dieses Geheimnis auszugeben. Der Agent wird damit zum Komplizen, der seine eigenen Schlüssel verrät, ohne dass eine klassische Sicherheitslücke ausgenutzt wurde.

Weitere typische Quellen runden das Bild ab:

• Hartcodierte Geheimnisse im Code, die über ein öffentliches Repository oder ein Container-Image abfließen.
• Tokens in Umgebungsvariablen eines kompromittierten Containers, die jeder Prozess im selben Namespace auslesen kann.
• Überbreite Weitergabe an Sub-Agenten oder externe Tools, die das Token gar nicht bräuchten (das sogenannte Confused-Deputy-Problem).
• Man-in-the-Middle bei fehlender oder falsch konfigurierter TLS-Prüfung zwischen Agent und API.
• Persistente Refresh-Tokens in unverschlüsselten lokalen Dateien oder Browser-Speichern.

Entscheidend ist die Erkenntnis: Sobald ein Token den Prozessspeicher des Agenten verlässt, sollten Sie davon ausgehen, dass es nach außen gelangen kann. Sicherheit entsteht nicht dadurch, jeden Abfluss zu verhindern, sondern dadurch, ein abgeflossenes Token wertlos zu machen.

Wie funktioniert ein Replay-Angriff konkret?

Ein Replay-Angriff ist im Kern unspektakulär, und genau darin liegt seine Stärke. Der Angreifer benötigt keine Schwachstelle im Token-Format und keinen Bruch der Kryptografie. Er fängt eine gültige, signierte Anfrage ab oder erbeutet das nackte Bearer-Token und sendet es ein zweites Mal an dieselbe API.

Bei einem reinen Bearer-Token im Sinne von OAuth 2.0 gilt das Prinzip: Wer das Token hat, darf handeln. Es gibt keine zusätzliche Prüfung, ob der Absender auch der rechtmäßige Inhaber ist. Der Ressourcen-Server validiert Signatur und Ablaufzeit, findet beides in Ordnung und antwortet. Aus seiner Sicht handelt es sich um eine völlig reguläre Anfrage des Agenten.

Bei einem Agenten verschärft sich die Lage durch die Frequenz und die Reichweite. Während ein gestohlenes Benutzer-Token vielleicht eine Sitzung kompromittiert, kann ein Agenten-Token für Massenoperationen missbraucht werden, bevor jemand reagiert: tausende API-Aufrufe, Datenabfluss im großen Stil oder die Manipulation nachgelagerter Systeme. Der Schaden skaliert mit der Geschwindigkeit der Maschine, nicht mit der eines Menschen.

Wie begrenzt Token-Bindung den Replay-Angriff?

Token-Bindung verwandelt ein Bearer-Token in ein an den Absender gebundenes Token. Der zentrale Gedanke: Das Token allein genügt nicht mehr. Der Client muss zusätzlich beweisen, dass er den privaten Schlüssel besitzt, an den das Token gebunden ist. Ein Dieb, der nur das Token erbeutet, hält damit eine wertlose Hülle in der Hand.

In der Praxis haben sich zwei standardisierte Verfahren durchgesetzt, die beide auf demselben Prinzip beruhen, sich aber in der Umsetzung unterscheiden.

Merkmal	DPoP (RFC 9449)	mTLS-gebundene Tokens (RFC 8705)
Bindung erfolgt über	Anwendungs-Schicht, signierter Proof-JWT pro Anfrage	Transport-Schicht, X.509-Client-Zertifikat
Was der Dieb zusätzlich bräuchte	Privaten Schlüssel des Client-Schlüsselpaars	Privaten Schlüssel des Zertifikats
Replay-Schutz im engen Zeitfenster	Server-Nonce plus jti-Verfolgung	TLS-Sitzung selbst
Typischer Einsatz	Öffentliche Clients, SPAs, mobile und Agenten-Clients	Backend-zu-Backend, regulierte Umgebungen (z. B. FAPI)
Infrastruktur-Aufwand	Gering, kein Zertifikatsmanagement nötig	Höher, PKI und Zertifikatsverteilung erforderlich

Bei DPoP weist der Client für jede Anfrage einen frischen Proof in Form eines signierten JWT im DPoP-Header nach. Der Autorisierungsserver bindet das ausgegebene Token an den öffentlichen Schlüssel des Clients; der Ressourcen-Server prüft, dass der Proof mit dem passenden privaten Schlüssel signiert wurde. Da ein abgefangener Proof selbst im kurzen Gültigkeitsfenster erneut eingespielt werden könnte, sieht der Standard eine vom Server gewählte Nonce vor, und der Server verfolgt die jti-Kennung, um Wiederholungen zu erkennen.

Bei mTLS-gebundenen Tokens geschieht die Bindung auf der Transportschicht. Das Token enthält einen Hash des Client-Zertifikats, und nur wer die mit diesem Zertifikat aufgebaute TLS-Verbindung führt, kann das Token einlösen. Für Backend-Agenten in regulierten Umgebungen ist dies oft die robustere Wahl, erfordert aber eine funktionierende PKI.

Für die meisten Agenten-Szenarien ist DPoP der pragmatische Einstieg, weil es ohne Zertifikatsverwaltung auskommt und sich gut zu öffentlichen und containerisierten Clients fügt.

Welche Rolle spielen kurzlebige Tokens?

Token-Bindung verhindert den Missbrauch eines gestohlenen Tokens. Kurzlebige Tokens begrenzen, wie lange ein Token überhaupt etwas wert ist, falls die Bindung doch einmal umgangen wird oder gar nicht implementiert ist. Beide Maßnahmen ergänzen einander; keine ersetzt die andere.

Ein kurzlebiges Zugriffstoken mit einer Lebensdauer von wenigen Minuten verkleinert das Zeitfenster für einen Replay-Angriff drastisch. Erbeutet ein Angreifer ein solches Token, läuft es ab, bevor er es großflächig ausnutzen kann. Die eigentliche Disziplin liegt darin, dieses Prinzip konsequent durchzuhalten, statt aus Bequemlichkeit langlebige Tokens auszustellen.

Drei Grundsätze haben sich bewährt:

• Kurze Gültigkeit für Zugriffstokens, gemessen in Minuten, nicht in Stunden oder Tagen.
• Refresh-Tokens an den Client binden und rotieren: Bei jeder Einlösung wird ein neues ausgestellt und das alte entwertet, sodass eine Wiederverwendung sofort auffällt.
• Just-in-time-Ausstellung statt langlebiger Vorratstokens: Der Agent fordert ein Token erst an, wenn er es für eine konkrete Aufgabe benötigt, idealerweise mit eng zugeschnittenem Scope.

Bei Agenten lohnt zudem der Gedanke an aufgabenbezogene Tokens. Statt einem Agenten ein einziges, breites und langlebiges Token zu geben, erhält er pro Teilaufgabe ein eng begrenztes, kurzlebiges Token. Damit verkleinert sich der potenzielle Schaden eines einzelnen Vorfalls erheblich.

Wie grenzen Sie den Schaden (Blast Radius) ein?

Den Schadensradius einzugrenzen heißt, von der Annahme auszugehen, dass ein Token irgendwann nach außen gelangt, und die Architektur so zu bauen, dass ein einzelnes kompromittiertes Token nur begrenzten Schaden anrichtet. Sicherheit verlagert sich damit von der reinen Verhinderung hin zur Eingrenzung und schnellen Erkennung.

Die folgenden Maßnahmen wirken zusammen und sollten in dieser Reihenfolge priorisiert werden:

1. Geringste Berechtigung (Least Privilege). Jedes Agenten-Token erhält nur die Scopes, die für seine konkrete Aufgabe nötig sind. Ein Agent, der Rechnungen liest, braucht keinen Schreibzugriff auf das gesamte Buchhaltungssystem.
2. Audience-Restriction. Binden Sie das Token an einen bestimmten Empfänger (aud), sodass ein an Dienst A ausgestelltes Token bei Dienst B nicht akzeptiert wird. So lässt sich ein Confused-Deputy-Angriff wirksam eindämmen.
3. Token-Bindung plus kurze Lebensdauer, wie oben beschrieben, als kombinierte Grundlage.
4. Saubere Geheimnis-Verwaltung. Tokens gehören in einen Secrets-Manager oder einen geschützten Speicher, niemals in Logs, Prompts, Quellcode oder unverschlüsselte Umgebungsdateien. Redigieren Sie Header in der Protokollierung konsequent.
5. Anomalie-Erkennung und sofortiger Widerruf. Überwachen Sie ungewöhnliche Nutzungsmuster eines Agenten-Tokens (plötzliche Volumensprünge, neue Quell-IPs, ungewohnte Endpunkte) und halten Sie einen Mechanismus bereit, ein Token oder einen kompletten Client binnen Sekunden zu sperren.

Der vierte und fünfte Punkt sind das Sicherheitsnetz: Wenn Bindung und kurze Lebensdauer ein Token schon weitgehend wertlos machen, sorgen sparsame Berechtigungen, Empfänger-Bindung und schnelle Sperrung dafür, dass selbst ein erfolgreicher Missbrauch lokal begrenzt bleibt.

Worauf kommt es bei der Umsetzung in einer Agenten-Architektur an?

Die genannten Standards entfalten ihre Wirkung nur, wenn die gesamte Kette mitspielt. Es genügt nicht, DPoP am Autorisierungsserver zu aktivieren, wenn der Ressourcen-Server den Proof gar nicht prüft. Achten Sie auf drei Dinge.

Erstens muss die Token-Bindung durchgängig sein, vom ausstellenden Server über jeden zwischengeschalteten Dienst bis zum Ressourcen-Server. Eine Bindung, die unterwegs verloren geht, schützt nicht.

Zweitens behandeln Sie das Sprachmodell als nicht vertrauenswürdige Komponente. Tokens sollten niemals in den Kontext gelangen, den das Modell verarbeitet. Die Token-Verwaltung gehört in eine deterministische Schicht außerhalb des Modells, etwa in das Tool-Gateway oder den MCP-Server, der die Aufrufe ausführt.

Drittens planen Sie den Widerruf von Anfang an mit ein. Eine Architektur, in der ein kompromittiertes Token nicht zentral und schnell entwertet werden kann, hat im Ernstfall kein wirksames Gegenmittel. Kurzlebige Tokens und rotierende Refresh-Tokens machen den Widerruf erst praktikabel.

Token-Diebstahl gegen KI-Agenten lässt sich nicht vollständig verhindern, aber er lässt sich entschärfen. Die Kombination aus an den Absender gebundenen Tokens, kurzer Lebensdauer, geringsten Berechtigungen und schneller Erkennung verwandelt ein gestohlenes Token von einer Katastrophe in ein beherrschbares Ereignis. Wer seine Agenten-Identitäten nach diesen Grundsätzen baut, sorgt dafür, dass ein Vorfall zwar ärgerlich, aber nicht existenzbedrohend ist.