Bearer-Tokens in Agentenaufrufen: Warum Zugangsdaten nicht in URLs gehören

Bearer-Tokens in Agentenaufrufen: Warum Zugangsdaten nicht in URLs gehören

Wer ein Bearer-Token besitzt, erhält laut RFC 6750 Zugriff auf die zugehörigen Ressourcen. Einen kryptografischen Schlüssel muss dabei niemand nachweisen. Deshalb entscheidet auch die Position des Tokens in der HTTP-Anfrage darüber, wo es offengelegt werden kann. Baut ein KI-Agent Tokens in URLs ein, landen sie womöglich an Stellen, die nie als Ablage für Geheimnisse gedacht waren.

Das Token ist der Schlüssel

RFC 6750 regelt die Nutzung von Bearer-Tokens in OAuth 2.0. Laut Definition kann jede Partei, die das Token besitzt, es genauso verwenden wie jede andere; ein kryptografischer Besitznachweis ist nicht vorgesehen. Die Spezifikation folgert daraus, dass Bearer-Tokens bei Speicherung und Übertragung vor Offenlegung geschützt werden müssen. TLS ist verpflichtend.

Jede Kopie ist ein Zugang.

Header, Body, Query: Was der Standard vorsieht

RFC 6750 beschreibt drei Wege, ein Token an einen Resource Server zu übertragen. Pro Anfrage darf der Client nur einen davon nutzen.

Der bevorzugte Weg ist der Authorization-Header mit dem Schema Bearer. Clients SOLLEN ihn nutzen, Resource Server MÜSSEN ihn unterstützen:

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer <ACCESS_TOKEN>

Die Übertragung als access_token in einem formularkodierten Body knüpft der RFC an strenge Bedingungen: Content-Type application/x-www-form-urlencoded, ein einteiliger Body und eine HTTP-Methode mit definierter Body-Semantik. GET ist damit ausgeschlossen. Laut Spezifikation soll dieser Weg nur in Anwendungskontexten genutzt werden, in denen die beteiligten Browser keinen Zugriff auf den Authorization-Header haben.

Als dritte Methode beschreibt RFC 6750 einen Query-Parameter wie ?access_token=<ACCESS_TOKEN>. Wegen der damit verbundenen Sicherheitsmängel soll dieser Weg nicht verwendet werden, sofern das Token über den Authorization-Header oder den Request-Body übertragen werden kann. Das Token steht dabei in der URL selbst, und damit beginnt das eigentliche Problem.

Warum HTTPS die URL nicht schützt

TLS schützt die Übertragung, nicht aber die weitere Verarbeitung der URL an ihren Endpunkten. OWASP stellt klar, dass HTTPS allein diese Schwachstelle nicht behebt: Query-Parameter landen auch bei verschlüsselter Verbindung im Referer-Header, in Web-Logs, im Browserverlauf, im Browser-Cache und auf geteilten Systemen. In einem von OWASP beschriebenen Praxisfall tauchte ein Einmalpasswort aus einer Login-URL zusätzlich in Monitoring-Tools von Drittanbietern auf.

Eine kurze Laufzeit verkleinert das Zeitfenster, beseitigt das Problem aber nicht. OWASP empfiehlt, solche Werte während ihrer Gültigkeit wie ein Passwort zu behandeln. Für Bearer-Tokens gilt dieselbe Logik.

Was das für Agenten bedeuten kann

Ein bestimmtes Produkt steht hier nicht im Fokus, wohl aber ein naheliegendes Muster: Ein Agent baut eine URL mit ?access_token=… und übergibt sie einem Fetch-Tool. Die vollständige URL könnte im Tool-Log, im Transkript und in der Zusammenfassung für die Nutzerin oder den Nutzer landen und von dort in einen Chatkanal wandern. Weil ein Bearer-Token ohne kryptografischen Besitznachweis nutzbar ist, wäre jede dieser Kopien sicherheitsrelevant.

Der Schutz des Tokens sollte deshalb technisch erzwungen werden, statt vom Verhalten des Modells abzuhängen. Dasselbe Prinzip steht hinter NCSC warnt: Agentische KI braucht Grenzen außerhalb des Modells und Googles Zero-Trust-Muster setzt Sicherheitsgrenzen außerhalb des KI-Agenten.

Konsequenzen für Entwicklung, Betrieb und Security

Für Entwicklungsteams heißt das: Tool-Schnittstellen sollten Zugangsdaten als eigenes Header-Feld annehmen, statt das Modell das Token in eine URL schreiben zu lassen. Idealerweise sieht das Modell das Token gar nicht, und das Tool setzt den Header erst beim Ausführen der Anfrage.

Für den Plattformbetrieb gilt: Proxies, Tool-Logs und Tracing sollten access_token und ähnliche Query-Parameter vor dem Schreiben maskieren. Das fängt Integrationen ab, bei denen Tokens trotzdem in URLs geraten.

Für Security-Teams reicht eine Richtlinie allein nicht. Ein kontrollierter Test mit einem kurzlebigen Test-Token zeigt, ob die Schutzmaßnahmen tatsächlich greifen: Anfrage über den vorgesehenen Agentenpfad ausführen, danach Proxy-Logs, Tool-Traces, Transkripte und Chat-Ausgaben nach dem Token oder seinem eindeutigen Präfix durchsuchen. Taucht es an einer dieser Stellen auf, ist der Pfad nicht ausreichend abgeschirmt. Ein produktives Token in einer URL sollte als offengelegt behandelt und rotiert werden, solange es noch gültig ist oder seine Laufzeit unklar bleibt.

Fazit: Die Mindestregel für Agenten-Integrationen

Bearer-Tokens gehören standardmäßig in den Authorization-Header und nicht in Query-Strings. RFC 6750 bevorzugt diesen Weg, und OWASP zeigt, warum URLs selbst über HTTPS an zu vielen Stellen kopiert werden. Ich halte diese Regel für Agenten-Integrationen für nicht verhandelbar. Wo eine API ausschließlich Query-Tokens akzeptiert, braucht es eine dokumentierte Ausnahme, konsequente Log-Maskierung und einen Test, der bestätigt, dass das Token weder in Traces noch in Transkripten auftaucht.