# Warum sind OAuth-Refresh-Token-Dateien Produktionszugangsdaten? Eine kopierte Datei `auth.json` ist kein überflüssiger Setup-Rest. Wenn sie ein Refresh-Token enthält, handelt es sich um Produktionszugangsdaten, mit denen weiterhin Zugriffstokens erstellt werden können, nachdem die Person, die sie kopiert hat, längst Feierabend gemacht hat. Dass die Maschine headless läuft, ändert daran nichts. Es entfernt lediglich die Browserabfrage, die jemanden daran erinnert hätte, über die Zuständigkeit nachzudenken. Ich habe Teams erlebt, die einen API-Schlüssel sorgfältig schützen und dann eine Refresh-Token-Datei als Chat-Anhang an einen Build-Host schicken, weil das darin enthaltene Zugriffstoken schnell ablief. Das ist genau falsch herum. Das kurzlebige Zugriffstoken ist meist der uninteressanteste Teil der Datei. Der Erneuerungsweg ist der Teil, den ein Angreifer, ein Agent mit zu vielen Berechtigungen oder ein nicht verantworteter Nachtjob immer wieder verwenden kann. ## Eine Refresh-Token-Datei ist ein Zugangsdatenpaket Eine OAuth-Refresh-Token-Datei ist ein Zugangsdatenpaket, weil sie oft genügend Informationen enthält, um ohne anwesende Person ein neues Bearer-Token zu erhalten. Die genauen Felder unterscheiden sich je nach Client-Bibliothek. Die gefährliche Kombination ist jedoch vertraut: ein Refresh-Token, eine Client-ID, ein Token-Endpunkt, gewährte Scopes und manchmal ein Client-Secret oder eine gerätespezifische Assertion. Lass dich von der Dateiendung nicht in falscher Sicherheit wiegen. JSON ist nur eine Verpackung. Eine Datei namens `.cache/session.json`, `token-store.json` oder `auth.json` verdient dieselbe Behandlung wie ein privater SSH-Schlüssel, wenn sie den Zugriff auf einen Produktionsdienst erneuern kann. Das OAuth 2.0 Authorization Framework, RFC 6749, beschreibt Refresh-Tokens als Zugangsdaten, mit denen Zugriffstokens angefordert werden. Außerdem heißt es dort, dass der Autorisierungsserver ein neues Refresh-Token ausstellen kann und der Client das alte verwerfen muss. Diesen letzten Satz tut man leicht als Protokolldetail ab. In einem unbeaufsichtigten System ist er eine betriebliche Anforderung: Zwei Worker, die dieselbe aktuelle Datei zu besitzen glauben, können nun um die Identität einer Zugangsdaten wetteifern. Trenne diese drei Dinge in deinem Verzeichnis: - Ein Zugriffstoken autorisiert einen Aufruf für einen begrenzten Zeitraum. - Ein Refresh-Token autorisiert die Erneuerung, oft über viele Lebensdauern von Zugriffstokens hinweg. - Ein OAuth-Client identifiziert die Software, die die Erneuerung anfordert. Teams setzen die ersten beiden oft gleich und ziehen dann den falschen Schluss aus der Ablaufzeit. Ein Zugriffstoken mit fünf Minuten Lebensdauer macht ein kopiertes Refresh-Token nicht sicher. Es kann lediglich bedeuten, dass die kopierte Datei einem Eindringling in Fünf-Minuten-Paketen neue Tokens liefert. Ein Eintrag im Produktionsverzeichnis sollte mehr beantworten als «Welcher Dienst verwendet das?». Halte den Autorisierungsserver, die OAuth-Client-ID, den Ressourcenserver, das Subjekt oder Dienstkonto, die genau gewährten Scopes, die Umgebung, den Ausstellungszeitpunkt, sofern verfügbar, den Verantwortlichen für die Erneuerung, den genehmigten Ausführungspfad und die Widerrufsmethode fest. Wenn du diese Felder nicht ausfüllen kannst, hast du noch keine Zugangsdaten für den autonomen Einsatz. Du hast eine Datei, die zufällig im Test funktioniert hat. ## Bei Headless-Arbeit geht die Zuständigkeit leicht verloren Ein Headless-Agent braucht eine Erneuerungsregelung mit einer klar benannten verantwortlichen Person oder Stelle. Der typische Fehler beginnt damit, dass ein Entwickler ein lokales Tool mit seinem eigenen Konto autorisiert und anschließend dessen Cache auf einen Server kopiert, weil der Server den Browser-Ablauf nicht abschließen kann. Der Job funktioniert, also wird die Kopie dauerhaft. Jetzt sind Fragen angebracht, die oft übersprungen werden, weil sie unangenehm sind. Repräsentiert das Token den Entwickler, das Team oder den Job? Wer kann es widerrufen, ohne die Arbeit einer anderen Person zu unterbrechen? Welches Repository oder welche Agentenanweisung sagt dem Job, wo er es findet? Kann ein ausscheidender Mitarbeiter die dahinterliegende Identität ungültig machen? Zeigt die Zustimmungsseite des Anbieters ein persönliches Konto, obwohl sich der Job wie ein Dienst verhält? «Das Plattformkonto besitzt es» ist keine Antwort, solange dieses Konto keinen dokumentierten Administrator, kein Wiederherstellungsverfahren und keine begrenzten Berechtigungen hat. Ein Token aus einer persönlichen Anmeldung ist in einer Hinsicht problematischer als ein sichtbarer API-Schlüssel: Es kommt oft als undurchsichtige Cache-Datei daher, sodass Prüfer nicht erkennen können, welche Berechtigungen damit übernommen wurden. Verwende eine dedizierte Dienstidentität, wenn der Anbieter das unterstützt. Gib dieser Identität nur die kleinste Gruppe von Ressourcenberechtigungen, mit der der Job abgeschlossen werden kann. Registriere für jede relevante Vertrauensgrenze einen eigenen OAuth-Client, etwa für Entwicklung, Staging und Produktion. Verwende keinen weitreichenden Client und keine weitreichende Zustimmung, nur weil sich damit die Erneuerung bequem durchführen lässt. Es lohnt sich, eine Unterscheidung klar zu halten: OAuth-Clientidentität und Ressourcenidentität sind verschiedene Kontrollen. Eine Client-ID sagt, welche Software ein Token angefordert hat. Das Subjekt und die Scopes legen fest, auf wessen Ressourcen das Token zugreifen kann und was es dort tun darf. Ein Team, das zwar einen dedizierten Client anlegt, ihn aber weiterhin als menschlicher Administrator autorisiert, verbessert die Zuordnung ein wenig, lässt das Berechtigungsproblem jedoch bestehen. Für einen Agenten solltest du neben der Bereitstellungsdokumentation einen einfachen Zuständigkeitseintrag anlegen, nicht in der Token-Datei: ```text Credential name: billing-export-prod OAuth client: agent-billing-prod Resource identity: svc-billing-export Scopes: reports.read, exports.write Renewal owner: platform-oncall Execution path: production job runner through credential broker Revocation: authorization server admin console and RFC 7009 endpoint ``` Dieser Eintrag ist absichtlich langweilig. Gerade deshalb hilft er um zwei Uhr morgens. Ein Betreiber kann damit die richtige Berechtigung widerrufen, ohne zu raten, ob die Datei zu einem alten Laptop eines Entwicklers, einem Staging-Test oder dem Job gehörte, der jetzt Alarm auslöst. ## Bewahre den Erneuerungsweg außerhalb des Agenten-Arbeitsbereichs auf Der Agentenprozess sollte eine Refresh-Token-Datei überhaupt nicht lesen. Wenn ein Agent den Wert lesen kann, kann er ihn ausgeben, in ein Protokoll schreiben, in einen Patch einbetten, an ein entferntes Tool senden oder in einem Absturzbericht hinterlassen. Anweisungen, die zur Geheimhaltung auffordern, ändern nichts daran, dass der Prozess lesbare Daten nach außen übertragen kann. Dateiberechtigungen sind weiterhin wichtig, aber sie bilden nur eine Eindämmungsschicht nach der architektonischen Entscheidung. Ein Dateimodus wie `0600` hält andere lokale Konten auf einem herkömmlichen Unix-Host fern. Er hindert jedoch weder den autorisierten Agentenprozess noch seine Plugins, Kindprozesse, den Debugger oder einen Backup-Job daran, die Datei zu lesen. Außerdem erklärt er nicht, warum dieser Host überhaupt eine Produktionszugangsdaten für die Erneuerung besitzt. Lege das Refresh-Token in einem Secret-Manager, einem Zugangsdaten-Store des Betriebssystems oder einem lokalen Broker ab, der vom Agenten keine Rohwerte abfragen lässt. Der Broker sollte eine eng begrenzte Aktionsanfrage akzeptieren, die Zugangsdaten intern abrufen oder erneuern, den genehmigten Ressourcen-Endpunkt aufrufen und das vom Agenten benötigte Ergebnis zurückgeben. Eine Anfrage kann so aussehen: ```json { "action": "create_export", "target": "billing-api", "parameters": { "report_date": "2026-07-23" } } ``` Der Agent erhält dann eine Antwort wie diese, kein Token: ```json { "status": "accepted", "export_id": "exp_4821", "report_date": "2026-07-23" } ``` Diese Grenze verhindert einen häufigen Fehler: Ein geheimes Verzeichnis wird in jeden Job-Container eingebunden und anschließend als kontrollierter Zugriff bezeichnet. Durch das Einbinden steht das Secret jeder Bibliothek, jedem Shell-Befehl, jeder Erweiterung und jedem versehentlichen Diagnose-Dump innerhalb dieses Containers zur Verfügung. Ein Broker kann unbekannte Ziele ablehnen, selbst die richtige Zugangsdaten anhängen und den Erneuerungsstatus aus dem Speicher des Agenten heraushalten. Auf macOS folgt Sallyport diesem Muster für seine unterstützten HTTP- und SSH-Aktionen: Die Zugangsdaten bleiben in seinem verschlüsselten Tresor, und der Agent erhält Aktionsergebnisse statt Klartext-Secrets. Dieser Entwurf ist hilfreich, weil er die Anfrage als das zu autorisierende Element behandelt und nicht die Token-Datei als bequeme Übergabe. Lege Refresh-Token-Dateien nicht in Repository-Verzeichnissen, CI-Arbeitsbereichen, gemeinsam genutzten Netzwerkordnern, versteckten Dateien im Home-Verzeichnis, Container-Images oder allgemeinen Backup-Pfaden ab. Jeder Ort schafft einen eigenen Kopiermechanismus, und jede Kopie führt zu einem weiteren künftigen Widerrufsproblem. Wenn ein älteres Tool unbedingt einen Pfad verlangt, gib ihm ein kurzlebiges, isoliertes Laufzeitverzeichnis, das einem Zugangsdaten-Helfer gehört. Der Helfer muss dann für das Erstellen und Entfernen der Datei verantwortlich sein. Behandle das als zeitlich begrenzte Kompatibilitätsausnahme, nicht als Standardmuster. ## Scopes sollten einen Job beschreiben, keine Abteilung Ein Headless-Agent sollte Scopes besitzen, die genau seinen einen Job beschreiben. Ein Token, das jedes Projekt lesen darf, weil der Agent irgendwann vielleicht ein weiteres Projekt benötigt, wird schließlich in einem Kontext verwendet, den niemand erwartet hat. Weite Scopes sind beliebt, weil Zustimmungsdialoge und Dokumentation der Anbieter frustrierend sein können. Die Kosten fallen später an, während eines Vorfalls, wenn der Widerruf eines Automatisierungstokens auch unabhängige Arbeit unterbricht. Beginne mit den endgültigen API-Aufrufen, nicht mit der Liste aller verfügbaren Scopes des Anbieters. Notiere die Verben und Ressourcen, die der Job braucht. Ein Job, der Rechnungen abruft und einen fertigen Export hochlädt, benötigt möglicherweise Lesezugriff auf Rechnungen und Schreibzugriff auf einen Export-Speicherort. Er benötigt keine Benutzerverwaltung, kein Löschen von Repositories, keine Änderungen an der Abrechnung und keine Berechtigungen zur Verwaltung von Zugriffsrechten, nur weil eine Person diese Berechtigungen bei der Ersteinrichtung verwendet hat. OAuth-Scopes allein reichen nicht aus. Berechtigungen auf Ressourcenseite können die Wirkung eines harmlos wirkenden Scopes vergrößern. Ein Token mit `files.write` kann weiterhin große Schäden anrichten, wenn sein Subjekt Zugriff auf jeden Teamordner hat. Binde die Dienstidentität an ein begrenztes Projekt, einen Ordner, eine Organisationseinheit oder ein Repository, sofern der Anbieter das erlaubt. Teste anschließend Negativfälle: Eine Aktion gegen eine benachbarte Produktionsressource sollte aus Berechtigungsgründen fehlschlagen und nicht nur deshalb, weil der Agent sie bisher noch nicht ausprobiert hat. Erstelle getrennte Berechtigungen für getrennte Aufgaben, auch wenn der Anbieter eine kombinierte Liste akzeptiert. Halte zum Beispiel einen Job zur schreibgeschützten Datensammlung von einem Job getrennt, der Ergebnisse veröffentlicht. Ein gestohlenes Publisher-Credential hat andere Auswirkungen, einen anderen Rotationsrhythmus und einen anderen Genehmigungsverantwortlichen als ein Lesetoken. Die Kombination spart zwar einen Erneuerungsablauf, erschwert aber jede Untersuchung. Vermeide Scope-Muster, die auf der Sitzung eines menschlichen Administrators beruhen. Administratoren stimmen oft weitreichenden Berechtigungen zu, weil sie sie für die Einrichtung brauchen. Der laufende Agent übernimmt nicht das Urteilsvermögen des Administrators. Er übernimmt seine Autorisierung. Ein nützlicher Prüftest lautet: Lies den Zustimmungsdatensatz und versuche, den Job in einem Satz zu beschreiben. Wenn daraus «Er kann mehrere Dinge verwalten, die wir vielleicht brauchen» wird, ist die Berechtigung noch nicht bereit. Begrenze den Job oder teile ihn auf. Zwei Zugangsdaten zu verwalten ist günstiger, als festzustellen, dass ein Export-Agent Identitätseinstellungen ändern konnte. ## Selbst erneuernde Tokens brauchen einen einzigen Zuständigen Die Rotation von Refresh-Tokens schafft ein Problem bei der Zustandsverwaltung, das unbeaufsichtigte Worker bewusst lösen müssen. Viele Autorisierungsserver rotieren Refresh-Tokens: Nach einer erfolgreichen Erneuerung gibt der Server einen Ersatz zurück und macht das vorherige Token möglicherweise ungültig. RFC 9700, OAuth 2.0 Security Best Current Practice, empfiehlt für öffentliche Clients die Rotation von Refresh-Tokens oder sendergebundene Refresh-Tokens, um Replay-Angriffe zu erkennen. Das ist eine solide Sicherheitsempfehlung, macht eine gemeinsam genutzte Datei aber nicht sicher. Betrachte einen häufigen Fehler. Worker A und Worker B starten mit derselben eingebundenen `auth.json`. Worker A erneuert zuerst und erhält `R2`; der Anbieter macht `R1` ungültig. Bevor A `R2` speichert, stürzt der Prozess ab oder die Dateispeicherung landet in einer lokalen Schicht, die B nicht sehen kann. Worker B sendet `R1`, erhält `invalid_grant` und versucht es erneut. Ein Betreiber sieht einen fehlgeschlagenen Job, kopiert einen älteren Cache aus einem Backup und erzeugt damit noch mehr Kopien der Zugangsdaten. Verwende eine dieser Regelungen: 1. Ein einzelner Zugangsdaten-Broker übernimmt die Erneuerungen und speichert den Ersatz transaktional. 2. Ein einzelner geplanter Worker besitzt eine bestimmte Berechtigung, mit einer ausdrücklichen Sperre und ohne parallele Replikate, die den Token-Zustand gemeinsam verwenden. 3. Für einzelne Worker gibt es getrennte Berechtigungen, sodass jedes Refresh-Token genau einen Schreiber hat. Die erste Regelung ist meist die sauberste. Die zweite kann für einen kleinen, kontrollierten Job funktionieren, aber Ablauf der Sperre und Wiederherstellung nach Abstürzen müssen sorgfältig entworfen werden. Die dritte verursacht mehr Aufwand bei Zustimmung und Lebenszyklus, begrenzt Fehler jedoch gut. Schalte die Rotation nicht ab, wenn der Anbieter das erlaubt, nur um den Wettlauf zu beheben. Diese Empfehlung ist verlockend, weil sie den Nebenläufigkeitsfehler verbirgt. Außerdem kann ein gestohlenes Refresh-Token dadurch länger unbemerkt aktiv bleiben. Behebe stattdessen das Zuständigkeitsmodell. Dein Speicherpfad muss das neue Token atomar aktualisieren und genügend Metadaten bewahren, um einen veralteten Schreiber zu erkennen. Speichere mindestens eine Version, den Zeitpunkt der letzten erfolgreichen Erneuerung und eine stabile Kennung für die Zugangsdaten, die gefahrlos protokolliert werden kann. Der Secret-Store sollte eine Aktualisierung ablehnen, die Version 14 ersetzen will, wenn bereits Version 15 existiert. Ein einfaches Überschreiben lädt einen langsamen Worker dazu ein, einen veralteten Zustand wiederherzustellen. Wenn der Autorisierungsserver sendergebundene Tokens anbietet, prüfe, woran sie gebunden sind. Ein Nachweisverfahren kann ein kopiertes Token ohne den entsprechenden, vom Client gehaltenen Schlüssel weniger nützlich machen. Es ersetzt weder die Zugriffskontrolle für diesen Schlüssel noch macht es aus einer menschlichen Zustimmung eine geeignete Dienstidentität. Betrachte es als zusätzliche Barriere und nicht als Grund, Cache-Dateien zu verteilen. ## Rotation ist ein Ablaufplan, keine Kalendererinnerung Eine Rotationsrichtlinie ist nur glaubwürdig, wenn jemand sie ohne Improvisation ausführen kann. Eine kalenderbasierte Rotation hat ihren Platz, aber Änderungen der Zuständigkeit, verdächtige Aktivitäten, ein kompromittierter Host, eine Offenlegung im Repository und unerwartete `invalid_grant`-Fehler sollten dieselbe vorbereitete Abfolge auslösen. Warte bei Verdacht auf eine entwichene Kopie nicht bis zum geplanten Datum. Ein brauchbarer Ablaufplan umfasst fünf Aktionen: 1. Halte den betroffenen Agenten oder Broker-Pfad an, damit während der Änderung keine weitere Erneuerung stattfinden kann. 2. Ermittle anhand des Zuständigkeitseintrags und der Protokolle den OAuth-Client, die Ressourcenidentität, die Scopes und die Version der Zugangsdaten. 3. Widerrufe das Refresh-Token oder die Berechtigung beim Autorisierungsserver, über die Konsole des Anbieters oder, sofern verfügbar, dessen RFC-7009-kompatiblen Widerrufs-Endpunkt. 4. Entferne jede bekannte Laufzeitkopie und entkräfte jeden Backup- oder Cache-Prozess, der sie wiederherstellen kann. 5. Registriere die dedizierte Identität erneut, teste die kleinste erlaubte Aktion und dokumentiere die Ersatzversion. RFC 7009 definiert den Widerruf von Tokens und erlaubt Servern ausdrücklich, bei der Bearbeitung einer Anfrage verwandte Tokens und Berechtigungen zu widerrufen. Ein Betreiber muss daher vor dem Widerruf die Reichweite kennen. Ein Anbieter kann das aktuelle Zugriffstoken, die gesamte Refresh-Token-Familie oder die komplette Berechtigung ungültig machen. Die richtige Reaktion besteht nicht darin, den Widerruf zu vermeiden. Dokumentiere stattdessen, welche Jobs eine Berechtigung gemeinsam verwenden, damit sie nicht versehentlich dieselbe Berechtigung teilen. Teste die Rotation mit einer kurzlebigen Identität außerhalb der Produktion. Bestätige, dass ein neu ausgestellter Ersatz funktioniert, das alte Token scheitert und ein veralteter Worker den neuen Zustand nicht überschreiben kann. Übe anschließend die Reaktion auf ein widerrufenes Token. Der Job soll mit einem erkennbaren Fehler und einer zuordenbaren Identität sicher abbrechen, statt still auf den gecachten Login eines Entwicklers zurückzugreifen. Backups brauchen besondere Behandlung. Auch verschlüsselte Backups bewahren ein Refresh-Token auf, bis die Aufbewahrungsfrist endet. Historische Backup-Blöcke lassen sich möglicherweise nicht sofort löschen, aber die offengelegte Berechtigung kann sofort widerrufen werden. Dokumentiere den Aufbewahrungsort, damit ein Ermittler weiß, dass sich auf den Wiederherstellungsmedien ein veraltetes Secret befindet, selbst wenn es nicht mehr funktioniert. ## Protokolliere Aktionen und Erneuerungsereignisse getrennt Audit-Protokolle müssen sowohl Erneuerungsereignisse als auch die mit den daraus resultierenden Zugriffstokens ausgeführten Aktionen zeigen. Ein Erneuerungsereignis sagt dir, dass eine Zugangsdaten weiterhin aktiv war. Es sagt nicht, ob der Agent einen Bericht gelesen oder tausend Datensätze geändert hat. Umgekehrt kannst du bei einem API-Aktionsprotokoll ohne Zugangsdatenversion nicht erkennen, welcher Erneuerungsweg die Aktion autorisiert hat. Speichere für jede Erneuerung sichere Metadaten: Zeitstempel, Kennung der Zugangsdaten, Token-Version vorher und nachher, OAuth-Client-ID, Subjekt-ID, angeforderte oder zurückgegebene Scopes, sofern der Anbieter sie bereitstellt, Ausführungshost oder Brokeridentität und Ergebnis. Speichere für jede geschützte Aktion sichere Metadaten: Agentensitzung oder Job-ID, angefordertes Ziel, Vorgang, Ressourcen-ID, Autorisierungsentscheidung, Ergebnisc ode und Korrelations-ID. Protokolliere niemals das Refresh-Token, Zugriffstoken, den Autorisierungscode, das Client-Secret, die vollständige Callback-URL oder den rohen Authorization-Header. Eine nachträgliche Entfernung ist zu spät, wenn ein Collector, ein Terminalrekorder oder ein Fehlermonitor das Ereignis bereits erhalten hat. Baue Protokollaufrufe so, dass sie diese Felder niemals akzeptieren, statt darauf zu vertrauen, dass jeder Aufrufer an einen Filter denkt. Eine nützliche Abfrage bei einem Vorfall beginnt mit einer Ressourcenaktion und verfolgt sie rückwärts. Angenommen, ein Export ist am falschen Zielort aufgetaucht. Du solltest beantworten können: Welcher Job hat ihn angefordert, welcher Prozess hat den Job ausgeführt, welchen OAuth-Client hat er verwendet, welche Zugangsdatenversion hat den Zugriff geliefert, wann wurde diese Version ausgestellt und hat ein anderer Host dieselbe Version verwendet? Wenn eine Verbindung davon abhängt, den Token-Wert zu lesen, ist das Audit-Design fehlerhaft. Manipulationssicherheit ist wichtig, wenn Agenten ohne ständige Aufsicht handeln. Ein schreibgeschütztes oder nur erweiterbares Protokoll auf demselben Host ist besser als völlige Stille, aber ein Angreifer mit Kontrolle über den Host kann sowohl den Cache als auch den Eintrag bearbeiten. Bewahre Audit-Daten in einem geschützten System auf und überprüfe ihre Integrität unabhängig. Systeme, die einen verschlüsselten, hashverketteten Datensatz aufbewahren können, geben Ermittlern durch eine Offline-Prüfung die Möglichkeit, Änderungen an Einträgen zu erkennen, ohne die zugrunde liegenden Secrets offenzulegen. ## Genehmigungen sollten auf Aktionen liegen, nicht auf der Offenlegung von Tokens Eine menschliche Genehmigung ist an der Grenze am nützlichsten, an der ein Agent ein externes System beeinflussen will. Eine Person einmalig um die Genehmigung einer Refresh-Token-Datei zu bitten und anschließend jedem Prozess wochenlang ihre Verwendung zu erlauben, erweckt den Eindruck von Kontrolle, während der sensible Wert in Umlauf kommt. Wähle Genehmigungen nach den möglichen Folgen. Ein schreibgeschützter Abruf kann in einer vorab genehmigten, eng begrenzten Sitzung laufen. Das Senden von Daten an ein neues Ziel, das Ändern von Berechtigungen, das Löschen einer Ressource oder die Verwendung einer Zugangsdaten außerhalb ihres üblichen Jobs sollte eine menschliche Entscheidung erfordern. Die genehmigende Person muss den anfragenden Prozess, das Ziel, den Vorgang und genügend Parameter sehen, um die Wirkung zu verstehen. Eine allgemeine Abfrage wie «OAuth zulassen» ist nahezu nutzlos. Verwechsle häufige Abfragen nicht mit Sicherheit. Wenn jeder harmlose Aufruf eine Zustimmung verlangt, bestätigen Menschen irgendwann automatisch. Lege für Routinearbeit eine sinnvolle Sitzungsgrenze fest und verlange für Aktionen mit großen Folgen eine separate Genehmigung. Die Entscheidung muss sichtbar bleiben, wenn der Agent am Küchentisch, über eine mobile Verbindung oder in einem Nachtjob läuft. Der Test ist einfach: Wenn eine Agentenanweisung feindselig wird oder sich ein Plugin schlecht verhält, kann es den Zugriff in eine Aktion außerhalb der eigenen Umgebung verwandeln, ohne eine Kontrolle zu passieren, die einem Menschen zeigt, was geschehen wird? Wenn die Antwort ja lautet, weil der Agent bereits `auth.json` besitzt, verschiebe die Zugangsdaten hinter einen Broker und gestalte die Anfrageschnittstelle neu. ## Behandle alte auth.json-Dateien als Migrationsprojekt Vorhandene Token-Caches verschwinden selten an einem einzigen Nachmittag. Wenn du sie jedoch nicht dokumentierst, weil die Migration unbequem ist, werden sie garantiert dauerhaft. Finde zunächst jeden Nutzer und ordne die Datei anschließend nach Dienst, Subjekt, Scopes, Umgebung, Anzahl der Schreiber und Speicherpfad ein. Widerrufe Kopien, die du nicht zuordnen kannst. Eine Zugangsdaten ohne Verantwortlichen darf sich nicht selbst erneuern. Verschiebe einen Workflow nach dem anderen. Erstelle zuerst eine dedizierte Ressourcenidentität und einen Client. Lege danach dessen Refresh-Token im ausgewählten Secret-Store oder Broker ab. Ändere anschließend den Job so, dass er eine erlaubte Aktionsanfrage übermittelt, und vergleiche den neuen Audit-Eintrag mit dem bisherigen Job-Ergebnis. Erst wenn der Ersatz funktioniert, solltest du die alte persönliche Berechtigung widerrufen. Einige Tools werden sich dagegen wehren. Manche SDKs gehen davon aus, dass sie einen lokalen JSON-Cache selbst verwalten, und erneuern stillschweigend, sobald sie ihn sehen. Halte solche Tools in einem eingeschränkten Kompatibilitäts-Wrapper. Nur ein Prozess darf die Datei lesen, und der allgemeine Agentenzugriff muss ausgeschlossen sein. Nimm die Entfernung dieses Wrappers in die Aufgabenliste des Service-Verantwortlichen auf. «Die Bibliothek erwartet es» erklärt eine vorübergehende Ausnahme, rechtfertigt aber keinen dauerhaften Weg für den Abfluss von Secrets. Das erste Migrationsziel sollte die Datei mit den weitreichendsten Scopes oder der am wenigsten klaren Zuständigkeit sein, nicht die am einfachsten zu verschiebende Datei. Diese Zugangsdaten verwandeln einen ansonsten begrenzten Fehler des Agenten in einen Produktionsvorfall. Sobald du einen Workflow sauber verschoben hast, erschwere die Wiederholung des alten Musters durch Bereitstellungsprüfungen, Änderungen an Vorlagen und den Verzicht darauf, rohe Zugangsdaten-Caches in Agentenlaufzeiten einzubinden. Ein Refresh-Token sollte genau einen verantwortlichen Besitzer, einen kontrollierten Erneuerungsweg und einen Audit-Trail haben, der jede damit autorisierte externe Aktion benennt. Wenn deine aktuelle `auth.json` diese Bedingungen nicht erfüllt, widerrufe sie, sobald der Ersatzweg nachweislich funktioniert.