# API-Zugriff für KI-Agenten: direkte Tokens oder vermittelte Aktionen? Ein KI-Coding-Agent sollte kein allgemeines SaaS-Token erhalten, nur weil er eine API aufrufen muss. Wenn du das Token direkt übergibst, wird der Agentenprozess zum Besitzer einer Zugangsdaten. Damit entstehen die üblichen Wege, auf denen Zugangsdaten nach außen gelangen: ein ausführlicher Befehl, ein Unterprozess, ein hochgeladenes Diagnosepaket, ein Tool-Ergebnis oder eine Anweisung, die den Agenten auffordert, seine Konfiguration auszugeben. Das heißt nicht, dass jeder API-Aufruf zum bürokratischen Akt werden muss. Du solltest vielmehr die **Berechtigung, eine Aktion auszuführen**, vom **Besitz der Zugangsdaten, die sie autorisieren**, trennen. Gib dem Agenten eine begrenzte Möglichkeit, nützliche Arbeit anzufordern, und bewahre die Zugangsdaten in der Komponente auf, die die Aktion ausführt. Wo die Folgen es rechtfertigen, sollte ein Mensch entscheiden. Die Unterscheidung wird leicht verwischt, weil ein erfolgreicher curl-Befehl harmlos aussieht. Problematisch wird es, sobald der Agent ein Produktions-Deployment erstellen, ein Kundenticket schließen, ein Issue ändern oder einen Remote-Befehl ausführen kann. Dann ist ein Token keine Konfigurationsfrage mehr. Es ist operative Berechtigung ohne eigenes Urteilsvermögen. ## Die direkte Übergabe eines Tokens macht den Agenten zur Grenze für Zugangsdaten Wenn du `SAAS_TOKEN` in die Umgebung, eine Konfigurationsdatei, eine Tool-Definition oder einen für Prompts zugänglichen Secret Store des Agenten legst, kann er authentifizierte Anfragen stellen, ohne dass eine andere Komponente entscheidet, ob jede einzelne Anfrage zur Aufgabe gehört. Das Token kann sinnvolle Berechtigungsbereiche haben. Es steht trotzdem jedem Verhalten dieses Prozesses und oft auch den von ihm gestarteten Programmen zur Verfügung. Entwickler sagen häufig, der Agent könne eine Umgebungsvariable nicht «sehen». Diese Behauptung hält dem normalen Einsatz von Tools nicht stand. Ein Agent kann eine Shell auffordern, ihre Umgebung zu prüfen, ein Skript aufrufen, das die Variable erbt, ein Testtool mit Debug-Logging ausführen oder einen Konfigurations-Snapshot in ein Repository schreiben. Der genaue Weg hängt vom Agenten und seinen Tools ab. Die sichere Annahme ist deshalb einfach: Wenn der Prozess ein Bearer-Token direkt verwenden kann, kann er das Token meist auch an einem Ort sichtbar machen, den du nicht vorgesehen hast. Ein Bearer-Token hat eine weitere unangenehme Eigenschaft. Der SaaS-Dienst kann nicht zwischen dem vorgesehenen Agenten und jedem anderen unterscheiden, der die Zeichenfolge kopiert hat. RFC 6750, die Spezifikation zur Verwendung von OAuth-2.0-Bearer-Tokens, sagt, dass Bearer-Tokens vor der Offenlegung bei Speicherung und Übertragung geschützt werden müssen, weil der Besitz bereits zur Nutzung ausreicht. Das ist keine akademische Formulierung. Sobald ein Agent das Token in ein Build-Log schreibt, sieht der Dienst einen gültigen Aufrufer und keinen Fehler. Direkter Zugriff verwischt außerdem die Verantwortlichkeit. Service-Audit-Logs nennen möglicherweise ein Bot-Konto, zeigen aber selten, welcher Agentenlauf die Anfrage erstellt hat, welche Anweisungen er erhalten hatte, wer ihn gestartet hat oder ob ein Mensch die daraus entstandene Wirkung freigegeben hat. Du erhältst ein API-Ereignis im Nachhinein, aber keine Entscheidungsspur, die es erklärt. Ein direktes Token kann in einer wegwerfbaren lokalen Sandbox vertretbar sein, wenn alle folgenden Bedingungen erfüllt sind: - Das Token läuft schnell ab und besitzt nur die erforderlichen Berechtigungen außerhalb der Produktion. - Das Ziel enthält keine Kunden-, Mitarbeiter- oder Produktionsdaten. - Der Agent läuft in einer isolierten Umgebung, die du löschen kannst. - Ein Mensch kann die Zugangsdaten widerrufen, ohne gemeinsame Arbeit zu unterbrechen. Teams machen aus dieser Ausnahme eine Routine, weil das Kopieren eines Tokens schnell geht. Die Geschwindigkeit ist real. Ebenso real ist aber die Aufräumarbeit, wenn das Token in einem Artefakt landet oder ein Agent einer schädlichen Anweisung in einer Issue-Beschreibung folgt. ## Berechtigungsbereiche begrenzen Rechte, steuern aber keine Absicht OAuth-Scopes, API-Rollen und Repository-Berechtigungen beantworten die Frage «Was darf diese Identität tun?». Sie beantworten nicht die Frage «Soll diese Anfrage jetzt stattfinden?». Das sind unterschiedliche Kontrollen. Wer sie gleichsetzt, lässt eine große Lücke. Nimm ein Issue-Tracker-Token mit der Berechtigung, Issues in einem Projekt zu bearbeiten. Dieser Scope kann für einen Agenten, der mit der Fehler-Triage beauftragt ist, korrekt sein. Eine Prompt-Injection in einem importierten Issue kann den Agenten trotzdem auffordern, alle offenen Issues zu schließen, Prioritäten zu ändern oder irreführende Kommentare zu schreiben. Jede Anfrage liegt innerhalb des Scopes. Trotzdem ist jede davon falsch. Dasselbe Problem gibt es bei einer Deployment-Plattform. Ein Token, das auf eine Anwendung begrenzt ist, weiß nicht, ob der Agent den aktuellen Commit deployen, ein Release zurückrollen, eine Umgebungsvariable ändern oder eine Preview-Umgebung löschen soll. Der Dienst sieht autorisierte API-Aufrufe. Nur dein Workflow kann entscheiden, ob diese Aufrufe zur Aufgabe und zu einem vertretbaren Ziel passen. Die Best Current Practice der IETF für OAuth 2.0 Security empfiehlt kurzlebige Zugriffstokens, nach Möglichkeit an den Absender gebundene Tokens und engere Berechtigungen, um den Schaden durch Bearer-Tokens zu begrenzen. Das sind gute Praktiken. Sie verkürzen die Nutzungsdauer und verringern die Reichweite eines kopierten Zugangstokens. Sie fügen jedoch keine Freigabe für eine destruktive, korrekt eingeschränkte Aktion hinzu und erklären auch nicht die Absicht des Agenten. Reagiere darauf nicht mit einem riesigen Regelkatalog, der jeden Endpunkt und jedes Argument vorhersagen soll. Teams erstellen solche Kataloge und verbringen dann Monate damit, Ausnahmen für neue Service-APIs und ungewöhnliche Release-Verfahren zu pflegen. Eine enge Aktionsschnittstelle mit einer Freigabe durch einen Menschen zum richtigen Zeitpunkt hält der Praxis meist besser stand als eine Policy-Sprache, die niemand sicher lesen kann. ## Issue-Tracker brauchen Schreibwege, die menschliches Urteilsvermögen bewahren Issue-Tracker wirken risikoarm, bis ein Agent in großem Umfang Änderungen vornimmt. Das Schließen eines Issues kann einen Kundenbericht unterdrücken. Geänderte Labels können Triage-Berichte beschädigen. Ein Kommentar kann interne Überlegungen für externe Mitwirkende sichtbar machen. Einen Nutzer zu einem Ticket hinzuzufügen kann den Zugriff auf vertrauliche Zusammenhänge erweitern. Teile die Arbeit des Agenten in Beobachtung und Änderung auf. Lass ihn Issues abrufen, Labels suchen, verknüpfte Pull Requests prüfen und einen Änderungsvorschlag erstellen. Leite die endgültige Änderung über eine Aktion, die Projekt, Issue, geänderte Felder und Kommentartext nennt. Eine prüfende Person sollte den tatsächlichen Inhalt sehen, bevor der Dienst ihn erhält. Ein Anfragevertrag macht diese Grenze konkret. Der Agent sollte strukturierte Absichten senden und keine Befehlszeile mit Zugangsdaten zusammenbauen. ```json { "service": "issue-tracker", "action": "update_issue", "issue": "APP-184", "changes": { "labels_add": ["needs-reproduction"], "comment": "I reproduced this on the current release and attached the failing test." } } ``` Der Executor sollte seine eigenen Zugangsdaten einfügen und ein begrenztes Ergebnis zurückgeben: ```json { "ok": true, "issue": "APP-184", "updated_fields": ["labels", "comment"], "request_id": "service-request-id" } ``` Gib nicht den rohen Authorization-Header, einen vollständigen HTTP-Trace oder ein Debug-Objekt mit Geheimnissen zurück. Das klingt selbstverständlich, bis jemand während einer schwierigen Integration ausführliche HTTP-Diagnosen aktiviert. Halte Diagnosen hinter einem von Menschen bedienten Fehlerbehebungsweg und teste die Schwärzung, statt sie nur anzunehmen. Ein Agent kann auch nach der Freigabe einer Sitzung durch einen Menschen eine schlechte Entscheidung treffen. Deshalb verdienen destruktive Änderungen an Issues eine eigene Freigabeoption. Die Sitzungsautorisierung beantwortet, ob dieses laufende Programm die Integration überhaupt verwenden darf. Die Freigabe pro Aufruf beantwortet, ob genau diese Änderung stattfinden soll. Der Unterschied ist besonders wichtig, wenn der Agent nicht vertrauenswürdige Texte aus Tickets, Dokumenten oder Pull-Request-Kommentaren lesen kann. ## Deployment-APIs haben Folgen, die über den Release-Button hinausgehen Eine Deployment-API bietet oft mehr als «diese Version deployen». Sie kann Umgebungsvariablen ändern, Builds auslösen, Workloads neu starten, Domains erstellen, Versionen zurückrollen, Logs abrufen oder Ressourcen löschen. Ein weitreichendes Deployment-Token wird zur praktischen Fernbedienung für einen Agenten, der bereits einen falschen Plan erstellt hat. Verwende für Deployment-Arbeiten unterschiedliche Aktionskategorien. Einen Build-Status zu lesen oder öffentliche Metadaten eines Deployments abzurufen, ist meist Routine. Ein Artefakt in die Produktion zu befördern, ein Release zurückzurollen, eine Secret-Referenz zu ändern und eine Umgebung zu löschen, hat jeweils andere Folgen. Bündele sie nicht hinter einer einzigen Freigabe mit der Bezeichnung «Deployment-Zugriff». Eine sinnvolle Anfrage verlangt eine unveränderliche Artefakt-Referenz und ein ausdrückliches Ziel. Lehne vage Eingaben wie «latest» ab, wenn der Dienst einen Commit, Image-Digest oder eine Build-ID verwenden kann. Veränderliche Bezeichnungen schaffen eine zeitliche Lücke zwischen Freigabe und Ausführung: Die prüfende Person genehmigt eine Sache, während die Aktion eine andere ausführt. ```json { "service": "deployment-platform", "action": "promote_release", "application": "billing-api", "environment": "production", "artifact": { "git_commit": "8cf4f3a", "build_id": "build-4921" }, "reason": "Fixes the confirmed invoice retry failure" } ``` Der Executor sollte prüfen, ob die freigegebenen Kennungen mit der von ihm gesendeten Anfrage übereinstimmen. Er sollte außerdem die Antwortkennung des Dienstes und die Zielumgebung protokollieren. Nur «Deployment erfolgreich» zu speichern, hilft dir um zwei Uhr morgens kaum, wenn jemand wissen möchte, welches Artefakt verschoben wurde und wer es autorisiert hat. Lass den Agenten kein Web-Dashboard auslesen, nur um ein API-Design zu vermeiden. Browser-Automatisierung verbirgt Einzelheiten vor der Prüfung, fällt ohne Vorwarnung aus und kann auf einer veralteten Seitenansicht klicken. Wenn die Plattform eine API anbietet, nutze eine enge vermittelte Aktion über diese API. Wenn sie nur ein Dashboard anbietet, akzeptiere, dass manche Vorgänge vorerst menschliche Arbeit bleiben, bis du einen zuverlässigen Connector bauen kannst. ## Kundensupport-Tools brauchen vor der Automatisierung eine Datenminimierung Kundensupport-Systeme verbinden operative Aktionen mit personenbezogenen Daten. Ein Ticket kann Kontodaten, Kontaktinformationen, Anhänge, Bestellhistorie, Logs und emotional formulierte Nachrichten enthalten. Direkter Agentenzugriff wirft zwei Fragen auf: Kann der Agent Material lesen, das er nicht benötigt? Und kann er unter dem Namen deines Unternehmens eine schädliche Antwort senden? Löse das nicht, indem du dem Agenten standardmäßig vollständige Ticketverläufe schickst. Rufe nur die für die Aufgabe erforderlichen Felder ab. Wenn der Agent ein Ticket klassifizieren soll, braucht er möglicherweise Betreff, einen bereinigten Nachrichtentext und den Produktbereich. Wahrscheinlich braucht er nicht jede frühere interne Notiz, die Abrechnungshistorie oder jeden Anhang. Schreibaktionen brauchen eine strengere Prüfung als Klassifizierungen. Ein nützliches Muster lautet: zuerst Entwurf, dann Versand. Der Agent erstellt einen Antwortvorschlag mit Verweisen auf das Ticket und auf interne Quellen, die er verwendet hat. Eine Person prüft Ton, Tatsachenbehauptungen, kontospezifische Angaben und die Frage, ob die Antwort versehentlich interne Notizen offenlegt. Erst danach sollte ein Executor die Nachricht veröffentlichen. Auch das Schließen, Zusammenführen oder Zuweisen von Tickets braucht eine klare Aktionssemantik. «Ticket lösen» ist zu vage, wenn dabei stillschweigend eine Abschlussmail verschickt, eine Service-Level-Frist verändert oder ein Entwurf gelöscht wird. Dein Anfrageschema sollte die Nebenwirkung nennen, die der Support-Dienst ausführt. Hier ist ein weitreichendes Dienstkonto besonders verlockend. Es vermeidet Berechtigungsprobleme und erlaubt dem Agenten, jede Warteschlange zu bearbeiten. Gleichzeitig kann eine einzige fehlerhafte Anweisung Kontogrenzen überschreiten. Weise Dienstidentitäten Warteschlangen oder Teams zu, wenn der Anbieter das unterstützt, und begrenze die vermittelte Aktionsschnittstelle auf die Vorgänge, die dieses Team tatsächlich benötigt. ## SSH ist Ausführungsberechtigung und kein API-Zugang mit anderer Schreibweise SSH verdient eine eigene Betrachtung, weil ein privater Schlüssel zu einer Shell, Dateiübertragung, Port-Weiterleitung und zu Tools mit eigenen Zugangsdaten führen kann. Eine Deployment-API bietet möglicherweise eine begrenzte Zahl von Vorgängen. Eine Remote-Shell kann dagegen spontan neue Vorgänge kombinieren. Wenn du einem Coding-Agenten einen privaten SSH-Schlüssel gibst, entstehen zwei Risiken gleichzeitig. Der Schlüssel kann nach außen gelangen, und der Agent kann beliebige Remote-Befehle erzeugen. Die Einschränkung des Kontos hilft, aber ein eingeschränktes Konto mit Zugriff auf Deployment-Skripte, Cloud-CLI-Zugangsdaten oder Produktionskonfiguration kann weiterhin viel mehr tun, als die ursprüngliche Aufgabe vermuten ließ. Verwende einen Vermittler, der den privaten Schlüssel hält und einen angeforderten Host, Befehl und Argumente entgegennimmt. Die Aktion sollte den aufgelösten Host und den exakten Befehl nach der Argumentverarbeitung protokollieren. Genehmige keine Shell-Zeichenkette, die der Agent später durch verschachtelte Anführungszeichen, Befehlsersetzung oder ein aus einem nicht vertrauenswürdigen Branch geladenes Remote-Skript neu interpretieren kann. Bevorzuge auf sensiblen Hosts feste Remote-Vorgänge statt allgemeinen Shell-Zugriffs. Ein Befehl wie `release-status --service billing-api` ist leichter zu prüfen als `bash -lc '...'`. Wenn du einen allgemeinen Befehl zulassen musst, zeige ihn genau so an, wie er ausgeführt wird, und verlange eine Freigabe pro Aufruf. Behandle `sudo`, Paketinstallationen, das Lesen von Secret-Dateien, Shell-Umleitungen und Befehle zum Kopieren nach außen als risikoreichere Fälle und nicht als normale Wartung. Auch die SSH-Hostprüfung ist wichtig. Der Client muss den Hostschlüssel des Servers mit einem verwalteten known-hosts-Eintrag abgleichen. Einen neuen Host-Fingerprint automatisch zu akzeptieren, kann aus einem Netzwerk- oder DNS-Fehler ein Ereignis mit Zugangsdaten machen. Das würde den Sinn zunichtemachen, den privaten Schlüssel sorgfältig verborgen zu halten. ## Vermittelte Aktionen schützen Zugangsdaten und schaffen einen Entscheidungspunkt Ein System für vermittelte Aktionen bewahrt das SaaS-Token oder den privaten SSH-Schlüssel in einem Executor auf und gibt dem Agenten eine Schnittstelle, über die er definierte Arbeit anfordern kann. Der Executor hängt die Zugangsdaten an, stellt die Anfrage und gibt das Ergebnis zurück. Der Agent erhält niemals ein Geheimnis, auch keinen Platzhalter, den er versehentlich in einen Befehl einsetzen könnte. Dadurch ändert sich der Fehlermodus. Ein Agent mit direktem Zugriff, der eine schädliche Anweisung annimmt, kann eine Aktion mit einem wiederverwendbaren Zugangstoken zugleich auswählen und ausführen. Ein vermittelter Agent kann weiterhin eine schlechte Aktion anfordern, denn keine Sicherheitskontrolle macht das Urteilsvermögen eines Sprachmodells perfekt. Der Executor kann aber den Aufrufer identifizieren, die Freigabe durch einen Menschen verlangen, die Zugangsdaten für den Agenten unzugänglich halten und Anfrage sowie Ergebnis protokollieren. Sallyport verwendet dieses Modell für HTTP-API-Aufrufe und SSH-Befehle: Ein MCP-fähiger Agent verbindet sich über `sp mcp`, während die macOS-App API- und SSH-Zugangsdaten in ihrem verschlüsselten Tresor hält und die Aktionen selbst ausführt. Die Tresorsperre verweigert jede Aktion, solange der Tresor gesperrt ist. Das ist korrekt, wenn die verantwortliche Person nicht am Rechner ist. Verwechsle einen Vermittler nicht mit einem Man-in-the-Middle-Proxy. Ein Proxy beobachtet oder überträgt allgemeinen Datenverkehr. Ein Aktions-Gateway erhält eine konkrete Aktionsanfrage, wendet seine Autorisierungskontrollen an, nutzt eine von ihm verwahrte Zugangsdaten und gibt ein Ergebnis zurück. Diese engere Form ist nützlich, weil sie einen Freigabepunkt und einen Audit-Eintrag schafft, statt den gesamten Datenverkehr erst zu interpretieren, nachdem der Agent ihn bereits erstellt hat. Die besten vermittelten Schnittstellen sind bewusst unspektakulär. Sie bieten wenige verständliche Verben, akzeptieren strukturierte Parameter, lehnen mehrdeutige Ziele ab und melden genug Informationen, um die Wirkung zu überprüfen. Ein cleverer universeller Endpunkt, der beliebige URLs, Header und Bodies akzeptiert, kann den direkten Zugriff mit zusätzlichen Schritten unbemerkt wiederherstellen. ## Das Freigabedesign scheitert, wenn Menschen die Anfrage nicht beurteilen können Ein Freigabedialog soll einem Menschen bei der Entscheidung helfen und ihn nicht bloß unterbrechen. «Agent fordert Zugriff auf Support-Tool an» verlangt die Zustimmung zu einer unbekannten Zukunft. «Diese Antwort als Support-Team an Ticket 4821 senden» gibt der prüfenden Person eine konkrete Aktion. Bei einem ersten Aufruf durch einen neuen Agentenprozess sollten Prozessidentität und Codesignatur angezeigt werden. Die Prozessidentität ist keine Nebensache. Auf einem Entwicklungsrechner können mehrere Terminals, Erweiterungen und Hilfsprogramme dieselbe Integration anfordern. Vor einer Sitzungsfreigabe sollte klar sein, welches signierte Programm fragt. Wähle anschließend die passende Autorisierungsebene: - Nutze eine Sitzungsfreigabe für risikoarme Arbeit, die während eines Agentenlaufs wiederholte Lesevorgänge oder Routineaufrufe benötigt. - Nutze eine Freigabe pro Aufruf für externe Nachrichten, Zustandsänderungen, Deployments, Remote-Befehle und Aktionen mit irreversiblen Folgen. - Sperre den Zugangsdaten-Tresor, wenn du nicht am Rechner bist. So schlägt jede Aktion fehl, statt auf eine unbeaufsichtigte Freigabe zu warten. - Widerrufe die aktuelle Sitzung, wenn sich die Aufgabe ändert, der Agent sich merkwürdig verhält oder du den Prozess nicht mehr erkennst. Freigabe-Ermüdung ist ein Designfehler. Wenn ein Mensch jeden harmlosen Abruf bestätigen muss, gewöhnt er sich daran, alles durchzuklicken. Wenn eine Freigabe einem Agenten einen ganzen Nachmittag lang Produktionsänderungen erlaubt, hat die Oberfläche zu viel Berechtigung hinter Bequemlichkeit versteckt. Teile Aktionstypen nach ihrer Wirkung auf und lasse alltägliche Aktivität ruhig, folgenreiche Aktivität dagegen konkret erscheinen. Vermeide Freigabetexte, die lediglich die vage Beschreibung des Agenten wiederholen. Die Aktionsschicht verfügt bereits über strukturierte Felder. Nutze sie. Zeige Dienst, authentifiziertes Konto oder Rolle, Zielprojekt oder Host, Vorgang und alle für Menschen bestimmten Inhalte an, die das Unternehmen verlassen. Zugangsdaten und private Felder, die für die Prüfung nicht nötig sind, sollten geschwärzt werden. ## Logs müssen jeden externen Effekt mit einem Agentenlauf verbinden Logs des Dienstanbieters allein reichen für Agentenarbeit nicht aus, weil sie erst an der API-Grenze beginnen. Agentenprotokolle allein reichen ebenfalls nicht aus, weil sie die tatsächliche Anfrage auslassen können oder bearbeitet wurden. Du brauchst sowohl einen Datensatz auf Laufebene als auch einen Datensatz auf Aufrufebene, die zuverlässig miteinander verbunden sind. Ein Journal auf Laufebene sollte den Agentenprozess, Beginn und Ende der Sitzung, die Freigabe, die ihn autorisiert hat, und eine Möglichkeit zum sofortigen Widerruf nennen. Ein Journal auf Aufrufebene sollte Aktionsanfrage, Autorisierungsergebnis, Ausführungsergebnis, Ziel und, sofern vorhanden, die Anfragekennung des Dienstes protokollieren. Halte sensible Anfrageinhalte aus normalen Ansichten heraus, wenn sie Kundendaten enthalten, bewahre aber genügend geschützte Belege für die Untersuchung eines Vorfalls auf. Manipulationsnachweise sind wichtig, wenn Logs einen Streitfall klären sollen. Eine einfache lokale Textdatei kann eine nützliche Historie enthalten, aber ein Benutzer oder kompromittierter Prozess kann sie umschreiben. Bei einer Hash-Kette hängt jeder Datensatz vom vorherigen ab. Spätere Änderungen brechen dadurch die Prüfung. Das macht das Log nicht unfehlbar. Es erschwert unbemerkte Änderungen und gibt Ermittlern eine überprüfbare Integritätseigenschaft. Sallyport erzeugt seine Journale für Sessions und Activity aus einem schreibgeschützten, verschlüsselten und hashverketteten Audit-Log. Die Chiffretext-Kette lässt sich mit `sp audit verify` offline prüfen, ohne den Tresorschlüssel. Eine erfolgreiche Prüfung sollte ungefähr so aussehen: ```text Audit chain: valid Records checked: 184 First sequence: 1 Last sequence: 184 ``` Wenn die Prüfung eine unterbrochene Sequenz oder eine nicht passende Hash-Summe meldet, bewahre die Dateien auf und untersuche sie, bevor du dich auf das Journal verlässt. «Repariere» ein verdächtiges Log nicht, indem du den fehlerhaften hinteren Teil löschst. Dabei könnten die einzigen Belege dafür verschwinden, wann und wie der Datensatz geändert wurde. ## Eine Umstellung von direkten Tokens sollte mit dem riskantesten Zugangstoken beginnen Versuche nicht, jede Integration innerhalb einer Woche neu zu entwerfen. Beginne mit dem Zugangstoken, dessen Missbrauch die schwierigste Wiederherstellung verursachen würde: Berechtigung für Produktions-Deployments, weitreichender Kundensupport-Zugriff oder ein SSH-Schlüssel, der gemeinsame Systeme erreicht. Bei der Umstellung sollten verwendbare Geheimnisse aus dem Agenten entfernt werden, bevor du jeden Workflow perfektionierst. Gehe für jede Integration so vor: 1. Erfasse, woher der Agent die Zugangsdaten heute bezieht. Berücksichtige Umgebungsvariablen, Repository-Dateien, CI-Secrets, Shell-Profile, Tool-Konfigurationen und kopierte Prompts. 2. Liste die Vorgänge auf, die der Agent tatsächlich ausführt, und trenne Lesevorgänge, Entwürfe, Änderungen und Remote-Ausführung. Die meisten direkten Tokens erlauben weit mehr als diese Liste. 3. Erstelle strukturierte Aktionsanfragen für die benötigten Vorgänge. Verknüpfe jeden Schreibvorgang mit einem benannten Ziel und jedes Deployment mit einer unveränderlichen Artefakt-Referenz. 4. Verschiebe die Zugangsdaten in einen Executor, den der Agent nicht lesen kann. Ersetze das alte Token, nachdem du den neuen Weg erfolgreich getestet hast. 5. Teste Fehler absichtlich: Sperre den Tresor, lehne eine Freigabe ab, widerrufe eine Sitzung, sende ein ungültiges Ziel und führe die Audit-Prüfung aus. Eine Demo des Erfolgswegs beweist fast nichts. Der Austausch des alten Tokens deckt einen Fehler auf, den Teams ständig machen: Sie fügen einen Vermittler hinzu, lassen das ursprüngliche Token aber «für den Notfall» in der Umgebung des Agenten. Dadurch bleiben zwei Wege zur selben Berechtigung bestehen, und irgendwann wird der weniger kontrollierte verwendet. Entferne den Fallback. Wenn der vermittelte Weg einen erforderlichen Vorgang noch nicht unterstützt, dokumentiere die vorübergehende Ausnahme, begrenze ihren Umfang und ihre Laufzeit und benenne eine Person, die sie entfernt. Die direkte Übergabe eines Tokens ist einfach, weil sie die schwierige Entscheidung an eine Zeichenkette in der Prozessumgebung delegiert. Für wegwerfbare Sandboxes kann dieser Tausch vertretbar sein. Bei Diensten, die Kunden, Deployments oder gemeinsam genutzte Infrastruktur betreffen, sollten Zugangsdaten aus dem Agenten herausgehalten und die konkrete Aktion vor ihrer Ausführung sichtbar gemacht werden.