So sollten Refresh-Tokens von KI-Agenten kontrolliert werden

Ein KI-Agent sollte niemals ein Refresh-Token besitzen. Diese Regel klingt streng, bis man sich ansieht, was der Token ermöglicht: Ein Prozess kann damit weiter Zugriff erhalten, nachdem die ursprüngliche menschliche Freigabe längst aus dem Blick geraten ist. Ein Zugriffstoken läuft vielleicht schnell ab. Ein Refresh-Token hält die Beziehung am Leben.

Die sinnvolle Lösung besteht nicht darin, den Agenten besser im Schutz eines Bearer-Tokens zu machen. Lege die Zugangsdaten in eine Aktionsschicht, die einem von Menschen kontrollierten Prozess gehört. Der Agent fordert eine bestimmte externe Aktion an. Die Schicht entscheidet, ob dieser Lauf sie ausführen darf, erneuert den Zugriff nur bei Bedarf und gibt das Ergebnis zurück. So entsteht ein Ort, an dem sich Verwendung freigeben, widerrufen und untersuchen lässt.

Ein Passworttresor allein löst das Problem nicht. Ein Tresor schützt die Speicherung. Eine Agenten-Aktionsschicht kontrolliert die Verwendung. Teams vermischen diese Aufgaben ständig und stellen dann fest, dass ein verschlüsselter Token trotzdem jedem Prozess zur Verfügung steht, der dem Tresor die richtige Frage stellt.

KI-Agenten-Refresh-Tokens verändern die Vertrauensgrenze

KI-Agenten-Refresh-Tokens sind gefährlich, weil sie die Berechtigung über den Agentenprozess hinaus verlängern, der sie ursprünglich brauchte. Wenn ein Programmieragent ein Refresh-Token aus einer Umgebungsvariablen, Konfigurationsdatei, einem Browserprofil oder der Antwort eines Secret Managers lesen kann, kann er es mit jedem aufrufbaren HTTP-Client verwenden. Der Token gehört dann nicht mehr zu einer begrenzten Aufgabe, sondern zu allem, was Kontrolle über diesen Prozess erlangt.

OAuth 2.0, RFC 6749, beschreibt Refresh-Tokens als Zugangsdaten, mit denen sich Zugriffstokens anfordern lassen, wenn das aktuelle Token abläuft oder ungültig wird. Die Spezifikation macht sie optional, aber dadurch werden sie nicht harmlos. Anbieter stellen sie aus, weil eine interaktive Autorisierung bei jeder Erneuerung umständlich wäre. Genau diese Bequemlichkeit ist der Grund, warum ein unbeaufsichtigter Agent keinen solchen Token besitzen sollte.

Halte drei Dinge getrennt:

• Der Kontoinhaber ist die Person oder Dienstidentität, deren Konto den Zugriff gewährt hat.
• Der Aktionsanforderer ist der Agentenprozess, der jetzt einen API-Aufruf ausführen möchte.
• Der Zugangsdatenverwalter ist die Komponente, die das Refresh-Token speichert und mit dem Token-Endpunkt spricht.

In einer kleinen Umgebung kann eine Person oder ein Programm mehrere Rollen übernehmen. Die Rollen müssen trotzdem existieren. Wenn derselbe Agent alle drei Rollen innehat, kann er ein neues Konto verbinden, seine Scopes erweitern, sich unbegrenzt neu autorisieren und die Aktion zwischen gewöhnlichen Anfragen verbergen. Das ist kein Autorisierungsdesign. Es ist ein Bearer-Token mit einem Chatbot daran.

Ich habe Teams erlebt, die sagten: «Der Agent braucht nur Lesezugriff», und anschließend ein Refresh-Token mit weitreichendem Zugriff auf Repositories, E-Mail oder Cloud-Dienste in eine lokale .env-Datei legten. Das Zugriffstoken ist vielleicht nur kurz gültig, aber das Refresh-Token macht den Fehler dauerhaft. Eine Prompt-Injection muss das Modell nicht dazu bringen, ein Passwort herauszugeben. Sie kann es dazu bringen, die weiterhin gültige Berechtigung für eine im Kontext plausibel wirkende Anfrage zu verwenden.

Die Grenze sollte liegen, bevor Zugangsdaten in den Agentenprozess gelangen. Der Agent erhält weder einen Tokenwert noch einen Platzhalter, den er anderswo eintauschen kann. Er bekommt eine Operationsschnittstelle: dieses Issue abrufen, diesen Entwurf anlegen, den Status dieses Deployments lesen, eine SSH-Sitzung zu diesem freigegebenen Host öffnen. Die Aktionsschicht besitzt die dahinterliegenden Protokolldetails.

Ein Mensch muss die Berechtigung besitzen, nicht nur einen Prompt bestätigen

Die Person, die eine Erneuerung freigeben kann, sollte feststehen, bevor die OAuth-Verbindung entsteht. «Jeder Entwickler kann auf Erlauben klicken» funktioniert, bis der Kontoinhaber das Unternehmen verlässt, ein gemeinsames Postfach den Besitzer wechselt oder ein Agent einen Dienst unter der Identität einer anderen Person neu verbindet.

Bei einem persönlichen SaaS-Konto sollte der Kontoinhaber die erste Autorisierung durchführen und eine erneute Verbindung nach Widerruf oder Ablauf freigeben. Für ein gemeinsames Betriebskonto braucht es eine verantwortliche Person und eine Vertretung, die den Zugriff widerrufen kann. Bei einer Maschinenidentität sollte der Dienstverantwortliche die Client-Registrierung und die Scopes autorisieren. Behandle eine Person und eine Maschinenidentität nicht als austauschbar, nur weil beide dieselbe API aufrufen können.

Trenne vier Entscheidungen, die oft in einem Browserklick zusammenfallen:

1. Wer darf die ursprüngliche Berechtigung erstellen?
2. Welche Aktionsschicht darf das daraus entstehende Refresh-Token aufbewahren?
3. Welche Agentensitzungen dürfen Aktionen mit dieser Berechtigung anfordern?
4. Wer darf die Berechtigung widerrufen oder eine neue Verbindung freigeben?

Der ursprüngliche OAuth-Zustimmungsbildschirm beantwortet nur die erste Frage, und manchmal nicht einmal diese vollständig. Er teilt dem Anbieter mit, dass ein Kontoinhaber einen Client mit bestimmten Scopes autorisiert hat. Er sagt deinem lokalen System nicht, ob ein nicht vertrauenswürdiges Repository, ein neuer Agenten-Unterprozess oder ein nächtlicher Job diese Berechtigung verwenden darf.

Ein praktischer Berechtigungseintrag braucht mehr als die E-Mail-Adresse des Anbieter-Kontos. Speichere einen lokalen Eintrag mit einer undurchsichtigen Berechtigungs-ID, dem Anbieter, einer Konto-Referenz, den Scopes, dem Besitzer, einer Person für den Widerruf, dem Verbindungsdatum und den Aktionen, die diese Berechtigung anfordern dürfen. Kopiere das Refresh-Token nicht in diesen Eintrag. Der Eintrag erklärt den Token, er darf nicht zu einem zweiten Geheimnisspeicher werden.

Schwierig ist der gemeinsame Zugriff. Ein Team verbindet oft ein Administratorkonto, weil es schnell geht, und lässt dann die Agenten aller Entwickler darunter arbeiten. Damit geht die Verantwortlichkeit verloren. Unterstützt die API Servicekonten, App-Installationen, delegierte Identitäten oder eng begrenzte Projekttokens, solltest du diese verwenden. Falls nicht, beschränke die Aktionsschicht auf eine kleine Gruppe freigegebener Operationen und halte den tatsächlichen Besitzer des gemeinsamen Kontos fest.

Gib einem Agenten nicht die Berechtigung, selbstständig einen neuen OAuth-Browser-Flow zu starten. Er kann zwar eine echte Anbieterseite anzeigen, aber einen Menschen auch zu einem umfassenderen Konto, einer größeren Scope-Auswahl oder einem anderen Tenant führen. Eine Verbindung zu starten ist eine administrative Aktion. Der Mensch sollte sie aus der Aktionsschicht heraus einleiten und Konto sowie Scope-Liste vor der Zustimmung prüfen.

Die Aktionsschicht sollte nur für eine freigegebene Aktion erneuern

Eine kontrollierte Aktionsschicht sollte ein Refresh-Token nur dann eintauschen, wenn eine autorisierte Anfrage ein aktuelles Zugriffstoken benötigt. Sie sollte keine Hintergrundschleife ausführen, die jedes Token «vorsichtshalber» erneuert. Eine vorweggenommene Erneuerung wirkt im Code ordentlich und erschwert die Reaktion auf Vorfälle, weil sie Berechtigungen ohne passende menschliche oder agentische Aktion am Leben hält.

Der Anfrageweg kann einfach bleiben:

1. Eine Agentensitzung fordert eine benannte Operation an und übergibt gewöhnliche Aktionsparameter.
2. Die Aktionsschicht ermittelt die zu dieser Operation gehörende Berechtigung und prüft, ob die Sitzung sie verwenden darf.
3. Fehlt das zwischengespeicherte Zugriffstoken oder läuft es bald ab, sendet die Schicht das Refresh-Token an den Token-Endpunkt des Anbieters.
4. Die Schicht ruft die Ziel-API mit dem Zugriffstoken auf und gibt das gefilterte Ergebnis an den Agenten zurück.
5. Die Schicht protokolliert Aktion und Erneuerung, aber keine Zugangsdaten.

Der Agent wählt niemals Token-Endpunkt, Client-ID, Callback-URL oder Scope-String. Diese Werte gehören zur Verbindungsdefinition, die der Mensch freigegeben hat. Wenn der Agent sie übergeben darf, wird dein Gateway zu einem offenen Token-Relay.

Nehmen wir an, ein Agent soll eine Release-Notiz in einem Projekt-Tracker veröffentlichen. Er bittet die Aktionsschicht, ein Issue in einem benannten Projekt anzulegen. Die Schicht erkennt, dass dafür eine Tracker-Berechtigung für dieses Projekt nötig ist, prüft die anfordernde Sitzung, erneuert das Zugriffstoken bei Bedarf und veröffentlicht die Notiz. Zurückgegeben werden können die neue Issue-ID und eine vom Anbieter gelieferte URL-ähnliche Referenz, nicht der Bearer-Token, mit dem das Issue erstellt wurde.

Ändere nun den Prompt. Eine schädliche Anweisung in einem Repository fordert den Agenten auf, den Zugriff zu «überprüfen», indem er alle Projekte der Organisation auflistet und in jedem ein Test-Issue erstellt. Besitzt der Agent das Refresh-Token, kann die Anweisung direkt zu einer Reihe von API-Aufrufen führen. Verfügt er nur über die benannte Operationsschnittstelle, kann die Schicht Anfragen außerhalb des freigegebenen Projekts ablehnen oder vor der Fortsetzung eine weitere menschliche Freigabe verlangen.

Dafür ist keine komplizierte Richtliniensprache nötig. Es braucht eine kleine, verständliche Auswahl: Welcher Prozess fordert an, welche Berechtigung darf er verwenden und braucht diese Aktion eine menschliche Freigabe? Mehr Optionen machen das Design nicht automatisch sicherer. Oft weiß der Betreiber dann nur nicht mehr, welche Regel gewonnen hat.

Sallyport folgt dieser Trennung, indem es API-Zugangsdaten in seinem verschlüsselten Tresor aufbewahrt und HTTP- oder SSH-Aktionen über seine MCP-Verbindung ausführt, statt die Zugangsdaten an den Agenten zurückzugeben.

Der Berechtigungstyp bestimmt, was sich sicher automatisieren lässt

Verwende den Authorization-Code-Flow mit PKCE für die Verbindung eines menschlichen Kontos in einer Desktop- oder lokalen Anwendung. Der Mensch meldet sich beim Anbieter an, prüft die Zustimmungsanfrage und kehrt über den registrierten Weiterleitungspfad zur lokalen Anwendung zurück. PKCE bindet die Autorisierungsantwort an den Client, der den Flow gestartet hat, und verringert den Wert eines abgefangenen Autorisierungscodes.

RFC 9700, OAuth 2.0 Security Best Current Practice, schreibt vor, dass öffentliche Clients PKCE verwenden müssen. Außerdem müssen Refresh-Tokens öffentlicher Clients entweder an den Sender gebunden sein oder rotiert werden. Das ist für Agentenintegrationen wichtig, weil eine lokale Anwendung oft wie ein öffentlicher Client arbeitet. Ein in einer Desktop-App ausgeliefertes Client-Geheimnis macht sie nicht zu einem vertraulichen Client. Wer die App besitzt, kann das Geheimnis extrahieren.

Wähle den Flow passend zur verbundenen Identität:

• Authorization Code mit PKCE für das Konto einer Person beim Anbieter.
• Client Credentials für eine Dienstidentität, wenn der Anbieter dies unterstützt und keine Delegation eines menschlichen Kontos nötig ist.
• Das installations- oder anwendungsspezifische Modell des Anbieters, wenn es einen engeren Zugriff auf Projekte oder Organisationen ermöglicht.
• Device Authorization nur, wenn der Anbieter und die Betriebsumgebung es erfordern. Zeige dem Menschen genau, welche Identität und welche Scopes er freigibt.

Client Credentials erzeugen normalerweise keine Refresh-Tokens, weil der Client durch erneute Authentifizierung selbst ein neues Zugriffstoken anfordern kann. Das kann für einen autonomen Job sicherer sein, wenn die Dienstidentität nur enge Rechte besitzt und das Material zur Client-Authentifizierung in der Aktionsschicht bleibt. Verwende Client Credentials nicht als Vorwand, einem Programmieragenten ein weitreichendes Client-Geheimnis zu geben.

Offline-Zugriff verdient besondere Aufmerksamkeit. Einige OpenID-Connect-Anbieter verlangen den Scope offline_access, bevor sie ein Refresh-Token ausstellen. Fordere ihn nur an, wenn eine Aktion tatsächlich nach Ende der interaktiven Sitzung laufen muss. Ist bei jeder Operation eine Person anwesend, kann ein kurzlebiges Zugriffstoken mit erneuter Autorisierung besser passen. Teams verlangen Offline-Zugriff oft standardmäßig, weil sie sich dann nicht um Ablauf kümmern müssen. Damit wird eine Unbequemlichkeit gegen dauerhafte Zugangsdaten getauscht.

Vermeide Resource Owner Password Credentials vollständig. RFC 9700 rät von diesem Berechtigungstyp ab, weil das Passwort der Person an den Client übergeben wird. Eine Aktionsschicht macht das nicht akzeptabel. Sie bietet lediglich einen weiteren Ort, an dem ein Passwort verloren gehen kann.

Rotation hilft nur, wenn der Speicher den Austausch korrekt verarbeitet

Die Rotation von Refresh-Tokens verringert den Schaden eines kopierten Tokens, indem jede erfolgreiche Erneuerung den vorherigen Token ersetzt. Ein Anbieter kann die Wiederverwendung eines alten Tokens erkennen und die betroffene Berechtigungsfamilie ungültig machen. Diese Erkennung ist hilfreich, kann aber auch die legitime Integration aussperren, wenn die eigene Erneuerungslogik fehlerhaft ist.

Der häufigste Fehler ist ein Wettlauf. Zwei Agentensitzungen benötigen fast gleichzeitig ein Zugriffstoken. Beide lesen dasselbe alte Refresh-Token. Die erste Sitzung erneuert erfolgreich und erhält einen neuen Wert. Die zweite sendet den alten Wert kurz danach. Je nach Anbieter schlägt die Anfrage fehl oder löst eine Wiederverwendungserkennung aus, die die gesamte Familie einschließlich des neuen Tokens widerruft.

Verhindere den Wettlauf mit genau einem Erneuerungsbesitzer pro Berechtigung. Die Aktionsschicht sollte die Erneuerung für jede Berechtigungs-ID serialisieren. Ein zweiter Aufrufer wartet auf das Ergebnis der ersten Erneuerung und verwendet anschließend das neu gespeicherte Zugriffstoken, statt eine weitere Tokenanfrage zu senden. Das ist eine Frage der Korrektheit, keine Optimierung.

Speichere den Ersatz-Token, bevor du die Erneuerung für künftige Vorgänge als erfolgreich betrachtest. Eine sichere Reihenfolge sieht so aus:

1. Sende das alte Refresh-Token über TLS an den Token-Endpunkt.
2. Prüfe die Tokenantwort und ordne sie dem erwarteten Anbieter und der erwarteten Berechtigung zu.
3. Schreibe das neue Refresh-Token und seine Metadaten in einer dauerhaften, atomaren Aktualisierung in den verschlüsselten Speicher.
4. Markiere den alten Token im lokalen Zustand als unbrauchbar.
5. Gib wartende Aufrufe mit dem neuen Zugriffstoken oder einem neuen Anfrageweg frei.

Stürzt der Prozess ab, nachdem der Anbieter den Token rotiert hat, aber bevor der lokale Speicher den Ersatz festhält, kann die Berechtigung verloren sein. Wiederholungen lösen das nicht. Der Wiederherstellungsweg ist eine vom Menschen geführte erneute Verbindung. Deshalb sind die Einträge zu Besitzer und widerrufsberechtigter Person wichtig.

Einige Anbieter stellen nur manchmal ein neues Refresh-Token aus, andere geben denselben Token zurück. Dein Code muss beide Verhaltensweisen akzeptieren. Bewahre den vorherigen Wert nur so lange auf, bis Anbieterantwort und dauerhafte Speicherung erfolgreich waren. Protokolliere keinen der beiden Werte, auch nicht beim Debugging. Viele Token-Leaks beginnen mit einer vorübergehenden Debug-Ausgabe, die eine Veröffentlichung überlebt hat.

Sendergebundene Tokens können das Replay-Risiko verringern, indem sie an einen kryptografischen Schlüssel gebunden werden, den der Client besitzt. DPoP, definiert in RFC 9449, ist ein Ansatz dafür. Er macht die sichere Verwahrung nicht überflüssig. Wenn ein Agent sowohl das Refresh-Token als auch den privaten Signaturschlüssel verwenden kann, besitzt er weiterhin dauerhafte Berechtigungen. Bewahre beide Materialien hinter der Aktionsschicht auf und prüfe das Verhalten des Anbieters, bevor du dich auf diese Bindung verlässt.

Für den Widerruf braucht es eine benannte Person und einen getesteten Weg

Widerruf ist keine Einstellung, die man einmal aktiviert. Jemand muss ihn unter Zeitdruck ausführen können, wenn das Dashboard des Anbieters langsam ist und sich niemand daran erinnert, welches Konto die Integration autorisiert hat.

Gib dem Kontoinhaber und einer benannten Vertretung einen direkten Widerrufsweg. Beim Widerruf muss die Aktionsschicht das lokale Refresh-Token entfernen, zwischengespeicherte Zugriffstokens ungültig machen und Sitzungen stoppen, die diese Berechtigung weiterhin anfordern könnten. Nur die Benutzeroberfläche eines Agenten zu deaktivieren, während die Zugangsdaten gespeichert bleiben, ist kein vollständiger Widerruf.

RFC 7009 definiert eine OAuth-Anfrage zum Widerruf von Tokens. Der Anbieter veröffentlicht seinen eigenen Endpunkt, aber das Anfrageformat sieht normalerweise so aus:

POST /revoke HTTP/1.1
Host: authorization.example
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <client authentication>

token=<refresh-token>&token_type_hint=refresh_token

RFC 7009 verlangt von Servern eine erfolgreiche Antwort, selbst wenn der übermittelte Token bereits ungültig oder unbekannt ist. So kann der Endpunkt nicht als Oracle für die Gültigkeit eines Tokens missbraucht werden. Für Betreiber bedeutet das: Ein HTTP-Erfolg allein beweist nicht, dass die Berechtigung aktiv Zugriff hatte. Halte fest, dass die Widerrufsanfrage gesendet wurde, entferne die lokale Zugangsdaten und überprüfe den Zustand anschließend mit einem harmlosen Anbieteraufruf oder einem Prüfprotokoll, falls es eines gibt.

Plane den Widerruf für diese Ereignisse: Der Kontoinhaber verlässt das Unternehmen, eine Agentensitzung steht unter Verdacht, eine Repository-Anweisung hat einen unerwarteten externen Aufruf ausgelöst, eine Integration wird stillgelegt oder ein Anbieter meldet die Wiederverwendung eines Tokens. Warte nicht auf ein Leak, um zu entscheiden, wer den Knopf drücken darf.

Ein bereits ausgegebenes Zugriffstoken kann bis zu seinem Ablauf verwendbar bleiben. Manche Anbieter widerrufen es sofort, andere nicht. Deine lokale Schicht kann die Ausgabe neuer Aktionen sofort stoppen. Das ist die Kontrolle, die du besitzt. Versprich keine sofortige globale Ungültigkeit, wenn der Anbieter sie nicht dokumentiert und du sie nicht getestet hast.

Trenne den Widerruf beim Anbieter von der lokalen Deaktivierung. Die lokale Deaktivierung hindert deine Aktionsschicht daran, die Berechtigung zu verwenden. Der Widerruf beim Anbieter fordert diesen auf, sie ebenfalls abzulehnen. Während eines Vorfalls solltest du beides in dieser Reihenfolge tun: zuerst den eigenen Ausführungspfad abschneiden, dann die Anfrage an den Anbieter senden. Der erste Schritt liegt unter deiner Kontrolle und darf nicht von einem externen Netzwerkaufruf abhängen.

Ein Audit-Eintrag muss die Absicht erklären, nicht nur den Datenverkehr

Eine Liste von HTTP-Aufrufen zeigt nicht, ob eine Erneuerung berechtigt war. Du brauchst einen Eintrag, der menschliche Entscheidung, anfordernde Agentensitzung, Berechtigungsreferenz und daraus resultierende externe Aktion miteinander verknüpft.

Schreibe keine Refresh-Tokens, Zugriffstokens, Autorisierungscodes, Client-Assertions oder vollständigen API-Inhalte in das Audit-Log. Tokenwerte sind Geheimnisse. Vollständige Antworten können Kundendaten, Repository-Inhalte oder persönliche Informationen enthalten. Wer sie aus Bequemlichkeit protokolliert, erzeugt einen zweiten, noch unübersichtlicheren Geheimnis- und Datenspeicher.

Ein nützlicher Ereigniseintrag enthält Ereignis-ID, Zeitpunkt, Sitzungs-ID, Identität des anfordernden Prozesses, Berechtigungs-ID, Referenz auf das verbundene Konto, Operationsname, Host des Anbieters, angeforderte Ressource, beim Verbinden erfasste Scopes, Freigabereferenz, Ergebnisklasse und gegebenenfalls einen Fehlercode. Für eine Erneuerung genügt die Information, dass sie stattgefunden hat und ob sie erfolgreich war. Der Tokenwert ist für die Untersuchung nicht nötig.

Der Unterschied zwischen Aktions- und Berechtigungseintrag ist wichtig. Ein Aktionsprotokoll sagt, dass eine bestimmte Agentensitzung den Deployment-Status einer benannten Umgebung angefordert hat und die Aktionsschicht dies erlaubt hat. Ein Berechtigungseintrag sagt, welche Berechtigung diese Anfrage unterstützt und wem sie gehört. Verknüpfe beide über eine undurchsichtige Berechtigungs-ID, aber gib nicht jedem Betreiber, der die Aktionshistorie einsehen kann, auch Zugriff auf Verbindungsdetails.

Manipulationsnachweise verbessern die Qualität einer Untersuchung. Kann ein kompromittierter lokaler Prozess dasselbe Log ändern, in das er schreibt, kann ein Angreifer die entscheidenden Einträge löschen. Verwende eine nur anhängbare Ereignisverarbeitung mit Integritätsprüfungen und überprüfe das Log unabhängig von dem Prozess, der es erzeugt hat.

Sallyport erstellt seine Journale für Sitzungen und Aktivitäten aus einem verschlüsselten, hashverketteten Audit-Log. sp audit verify prüft diese Kette offline, ohne einen Tresorschlüssel.

Prüfe das Verhalten in einem Rhythmus, der zur Macht der Berechtigung passt. Eine Berechtigung für einen persönlichen Issue-Tracker braucht vielleicht gelegentliche Überprüfung. Eine Berechtigung, die Produktionsinfrastruktur ändern kann, sollte nach jeder neuen Verbindung, jeder Scope-Änderung und jedem unerwarteten Agentenverhalten geprüft werden. Die Aktionsschicht muss die Einträge so verständlich machen, dass ein Besitzer beantworten kann: «Welcher Agent hat mein Konto wofür und unter wessen Freigabe verwendet?»

Browserprofile und allgemeine Token-Broker schaffen stille Umgehungen

Ein Browserprofil ist ein schlechter Speicher für Agenten-Zugangsdaten. Es kann Sitzungscookies, zwischengespeicherte Zugriffstokens, Refresh-Tokens, Kontenauswahl und unabhängige Browserdaten enthalten. Ein Agent mit Zugriff auf dieses Profil erhält mehr als die Berechtigung für eine einzelne API-Aktion. Außerdem wird die Bereinigung schwierig, weil sich Zustand beim Anbieter und Browserzustand vermischen.

Ein allgemeiner Token-Broker kann dasselbe Problem erzeugen, wenn er beliebige Parameter für Token-Endpunkte von Aufrufern akzeptiert. Teams bauen oft eine API namens getToken(scope) und fühlen sich sicherer, weil der Token nicht mehr im Agentenprozess liegt. Der Broker wird trotzdem zu einem Tokenautomaten, wenn jede Sitzung jedes verbundene Konto oder beliebige Scopes anfordern kann.

Lass den Aufrufer eine Operation anfordern, keinen Token. «Release-Notiz in Projekt A erstellen» hat einen Besitzer, ein Ziel und eine überprüfbare Scope-Anforderung. «Gib mir einen Token für tracker.write» überlässt dem Aufrufer zu viel Macht.

Löse das nicht mit einer riesigen Regel-Engine, bevor du deine Operationen verstanden hast. Ein kurzes Verzeichnis freigegebener Aktionen, das an benannte Berechtigungen und menschliche Freigabepunkte gebunden ist, lässt sich leichter prüfen und schwerer umgehen. Füge Komplexität erst hinzu, wenn ein konkreter betrieblicher Bedarf sie verlangt.

Vermeide außerdem, ein Refresh-Token für Entwicklung, Staging und Produktion gemeinsam zu verwenden. Getrennte Berechtigungen machen den Widerruf weniger dramatisch und Audit-Einträge eindeutiger. Ein Staging-Agent sollte keinen Weg in die Produktion behalten, nur weil beide Umgebungen zufällig denselben Identitätsanbieter nutzen.

Beginne mit einer Besitzübersicht und einer Widerrufsübung

Das erste nützliche Ergebnis ist ein Berechtigungsinventar, nicht Code. Lege für jedes Refresh-Token, dessen Verwendung ein Agent auslösen könnte, eine Zeile an. Nimm Anbieter, Konto-Referenz, Berechtigungs-ID, Scopes, Ort der Aktionsschicht, Kontoinhaber, Vertretung für den Widerruf, Erstellungsverfahren, letzte bestätigte Verwendung und lokales Deaktivierungsverfahren auf. Kannst du eine Spalte nicht ausfüllen, kontrollierst du diese Berechtigung noch nicht.

Führe anschließend mit einer risikoarmen Integration eine Widerrufsübung durch. Der Besitzer soll die Berechtigung lokal deaktivieren, sie beim Anbieter widerrufen und danach eine gewöhnliche Agentenaktion versuchen. Prüfe, dass die Aktionsschicht die Anfrage blockiert, dass eine erneute Verbindung eine ausdrückliche menschliche Aktion benötigt und dass die Audit-Spur die frühere Sitzung identifiziert. Dabei kommen Annahmen schnell ans Licht: fehlende Anbieter-Endpunkte, unklare Kontobesitzer, auf alten Entwicklergeräten gespeicherte Tokens und zwischengespeicherte Zugriffstokens, die länger gültig bleiben als lokal erwartet.

Lege eine Ablaufprüfung für Berechtigungen fest, deren Anbieter keine zeitliche Begrenzung erzwingt. Langer Zugriff kann für unbeaufsichtigte Arbeit nötig sein, aber unbefristeter Zugriff sollte eine bewusst beschlossene Ausnahme mit benannter zuständiger Person sein. Kann ein Team den Besitzer nicht nennen, sollte die Berechtigung nicht nutzbar bleiben.

Der Maßstab ist einfach: Ein Agent darf Arbeit anfordern, aber er darf nicht die Fähigkeit eines Kontos erben, sich für immer selbst neu zu autorisieren. Bewahre die Refresh-Zugangsdaten dort auf, wo ein Mensch ihre Verwendung kontrollieren kann, und mache den Widerruf zu einer geübten Handlung statt zu einer Notfall-Suche durch Browser-Tabs.