Die gängige Annahme: Ein KI-Agent kann nur dann im Namen eines Nutzers handeln, wenn er dessen OAuth-Access-Token selbst besitzt. Das lässt sich anders bauen. Delegierter Zugriff funktioniert auch so, dass die Agenten-Runtime nie ein Provider-Token sieht. Auf den ersten Blick wirkt das wie ein Architekturdetail. Tatsächlich entscheidet es darüber, ob ein manipulierter Agent einen peinlichen Fehler produziert oder einen Schlüssel mitnimmt, der noch Wochen später gültig ist.
Ein Bild trägt den ganzen Text: eine Rezeption mit Schlüsselverwaltung. Bisher bekommt jeder, der irgendwo im Gebäude etwas zu tun hat, einen Generalschlüssel für alle Türen — man weiß ja vorher nie, welche Tür er öffnen wird. Künftig bleibt der Schlüsselbund hinter der Rezeption. Der Mitarbeiter meldet nur an, in welchen Raum er will und für wen er unterwegs ist, die Rezeption holt den passenden Schlüssel, schließt auf, und der Mitarbeiter sieht vom Schlüssel nie mehr als das Loch in der Tür. Wer diesen Wechsel einmal verstanden hat, versteht auch, warum die Frage nach dem Zugriff auf fremde APIs neu gestellt werden muss.
Der Beitrag stammt von Maria Paktiti (10. August 2026) und beschreibt am Beispiel von WorkOS Relay, einem Proxy im Early Access, wie delegierter Zugriff konkret aussieht. Es geht hier nicht um Produktwerbung, sondern um die Mechanik: wo Tokens in Agenten-Runtimes landen, warum engere Scopes das Problem nur verschieben und was ein Credential-Proxy leistet — und was nicht. Wer Agenten betreibt, die im Namen von Nutzern auf GitHub, Slack oder andere Dienste zugreifen, ist in jedem Abschnitt betroffen.
Warum die Grenze zwischen Code und Eingabe bei Agenten verschwindet
Anwendungssicherheit hat immer einen sauberen Schnitt gezogen: hier der vertrauenswürdige Code, dort die nicht vertrauenswürdige Eingabe. Der eigene Server durfte alles, der Request-Body durfte nichts. Jede Verteidigungslinie, die wir in den letzten zwanzig Jahren gebaut haben, sitzt auf dieser Grenze — Eingabevalidierung, parametrisierte Queries, Output-Encoding. Sie alle gehen davon aus, dass zwischen Daten und Anweisungen ein Unterschied besteht.
Eine Agenten-Runtime löst diesen Unterschied auf. Ein Support-Ticket, eine gescrapte Webseite, ein hochgeladenes PDF, ein Kommentar im Quellcode eines Repositories, das der Agent prüfen soll: Alles davon landet im selben Kontextfenster wie der System-Prompt und bekommt dieselbe Aufmerksamkeit. Du führst also nicht mehr nur Code aus, den du geschrieben hast. Du führst deinen Code aus — und dazu das, was das Modell aus einem Absatz Text ableitet, den irgendjemand dort abgelegt hat.
In der Rezeptions-Metapher: Der Mitarbeiter liest unterwegs Zettel, die an den Türen kleben, und hält sie für Anweisungen der Hausverwaltung. Manche sind es. Manche hat jemand mit einem Filzstift hingekritzelt. Der Punkt ist nicht, dass der Mitarbeiter dumm wäre. Der Punkt ist, dass seine Umgebung keine Möglichkeit vorsieht, den Unterschied zu erkennen. Damit ist Agenten-Sicherheit ein anderes Problem als klassische Anwendungssicherheit.
Wo ein Access-Token in der Agenten-Runtime tatsächlich landet
Die Formulierung „das Token liegt in der Umgebung“ klingt abstrakt, bis man die Kopien zählt. Ein Provider-Token in einer Agenten-Runtime existiert an deutlich mehr Stellen, als die Person beabsichtigt hat, die es dort deponiert hat. Die erste ist das Kontextfenster selbst: Sobald der Agent seine eigene Konfiguration liest, einen ausgehenden Request inspiziert oder einen fehlschlagenden Aufruf debuggt, steht das Token im Prompt — und ist von dort nur eine Zusammenfassung davon entfernt, irgendwo anders hingeschrieben zu werden.
Die zweite sind die Argumente der Tool-Aufrufe. Die werden in der Regel wörtlich von der Observability-Schicht protokolliert, weil Tool-Eingaben oft das Einzige sind, womit sich ein Agent überhaupt debuggen lässt. Die dritte sind die Logs des Modell-Providers, sofern das Token auf seinem Weg irgendwo durch einen Prompt lief. Die vierte sind stdout und stderr, denn ein selbst zusammengebauter curl-Befehl weiß nicht, dass er seine Header redigieren müsste.
Die fünfte Stelle ist das Error-Reporting: Ein fehlgeschlagener HTTP-Request serialisiert in vielen Bibliotheken die Request-Header in die Exception-Payload. Die sechste sind Scratch-Dateien und Memory-Stores, also die Mechanismen, mit denen Agenten Zustand über mehrere Schritte hinweg halten — und die fast nie als schützenswertes Material behandelt werden. Die siebte ist der Exfiltrationspfad selbst, und der braucht keinen Bug: Ein Agent mit Token und Netzzugang lässt sich überreden, beides gemeinsam woandershin zu schicken. Das ist keine Schwachstelle im Code, das ist die Funktion, die arbeitet wie entworfen. Sieben Kopien aus einem einzigen Token, und jeder dieser Wege ist normales Agentenverhalten. Wer Token-Leaks vermeiden will, muss deshalb nicht die Fehler zählen, sondern die normalen Betriebszustände.
Ein Token-Leck braucht keinen Bug, sondern einen Absatz
Die Autorin führt ein Beispiel durch, das sich in vielen Teams nachbauen ließe: ein Agent, der GitHub-Issues triagiert und dafür das Token eines Nutzers hält, um Repositories zu lesen und zu kommentieren. Jemand eröffnet ein Issue, dessen Text mit einer Zeile endet, die nicht an die Entwickler adressiert ist, sondern an den Agenten — mit der Bitte, den Authorization-Header in einen Diagnose-Request an eine fremde URL zu packen. Ob das Modell mitspielt, hängt vom Modell ab, vom Prompt und vom Tag.
Damit hängt Credential-Sicherheit von Wahrscheinlichkeiten ab, nicht von einer festen Eigenschaft. Ein Modell, das neunzehn von zwanzig solchen Versuchen widersteht, ist immer noch keine Kontrolle, die man irgendwo sonst im Stack akzeptieren würde. Dazu kommt, dass sich der Fehler nicht nach dem gewohnten Muster reparieren lässt: Ein geleaktes Access-Token ist keine Session, die man auf der eigenen Seite ungültig machen kann. Es ist ein Bearer-Credential für eine fremde API, gültig bis zum Ablauf oder bis der Nutzer die Freigabe zurückzieht — und es funktioniert von überall.
Die beiden naheliegenden Reflexe sind engere Scopes und kürzere Laufzeiten. Beides ist sinnvoll, und beides trifft nicht den Kern. Scopes sind grob geschnitten, weil OAuth-Scopes für Anwendungen entworfen wurden, nicht für Agenten: Ein Token, das die Repositories lesen darf, die ein Agent braucht, darf meist alle Repositories lesen, die dieser Nutzer sieht. Und Rotation verkürzt das Zeitfenster, ohne es zu schließen, denn wer ein Token einmal erreichen konnte, erreicht es meist wieder — der Leak-Pfad ist eine Eigenschaft der Runtime, kein Moment. Ein Refresh-Flow macht es sogar schlimmer, weil die Runtime dann zusätzlich Refresh-Material hält, das mehr wert ist als das Access-Token. Der eigentliche Angriffspunkt ist die Prämisse, dass das Token überhaupt in der Umgebung des Agenten liegen muss.
Wie sicherer delegierter API-Zugriff ohne Token im Agenten aussieht
Die Alternative: Das Credential wird gar nicht erst an den Code ausgeliefert, der es benutzen möchte. Stattdessen beschreibt der Code nur den Aufruf, den er im Namen eines bestimmten Nutzers machen will. Im beschriebenen WorkOS-Beispiel schickt die Agenten-Runtime ihren Request an den Proxy, benennt Provider und handelnden Nutzer, und der Proxy hängt das Credential auf dem Weg nach draußen an. Die Runtime hält dann nur noch den eigenen API-Key.
Konkret trägt ein solcher Proxy-Request den WorkOS-API-Key im Authorization-Header, die Ziel-URL in einem eigenen Header, die Nutzer-ID in einem weiteren und optional die Organisation, unter der die Verbindung autorisiert wurde. Der Provider wird aus dem Host der Ziel-URL aufgelöst; ein optionaler Override existiert für den Fall, dass der Host mehrdeutig ist. Der Proxy prüft den Key, sucht das verknüpfte Konto des Nutzers, holt das Credential aus dem Store, erneuert es bei Bedarf, entfernt seine eigenen Steuer-Header, setzt das Provider-Token ein und reicht die Antwort unverändert zurück. Methode, Body und Content-Header bleiben gleich — der Umbau eines direkten Aufrufs in einen delegierten ist ein Header-Edit, keine Neuimplementierung.
Zwei Details kommen hinzu. Erstens die Fehlersemantik: Bei einem reinen Durchlauf-Proxy wäre ein eigenes 401 nicht von einem 401 des Providers zu unterscheiden. Deshalb bekommt ein Nutzer, der den Dienst nicht verbunden hat oder dessen Freigabe entzogen wurde, eine 402 mit einem Code, der auf eine erforderliche Autorisierung hinweist, plus einer URL, an die man ihn schicken kann. Jede Antwort trägt zusätzlich den Upstream-Status, sodass ein GitHub-404 und ein 404 eines unbekannten Providers nicht mehr gleich aussehen.
Zweitens liegt das Token nun hinter einer Grenze, die der Agent nicht überschreiten kann, selbst wenn er es wollte. Requests dürfen nur erlaubte Hosts eines unterstützten Providers treffen, Redirects werden nicht verfolgt — was wichtiger ist, als es klingt, weil ein gefolgter Redirect genau der Weg ist, auf dem ein eingesetztes Credential bei einem nicht freigegebenen Host landet. Cookie- und Hop-by-Hop-Header werden entfernt, das Upstream-Timeout liegt bei dreißig Sekunden, Bodies laufen byteweise bis fünf Megabyte durch. Ein kompromittierter Agent kann damit Aufrufe machen, die er nicht machen sollte. Er kann aber kein Credential mitnehmen. Access-Tokens in der Agenten-Runtime schützt man am besten, indem man sie dort gar nicht erst lagert — nicht, indem man sie besser versteckt.
Was ein Credential-Proxy ausdrücklich nicht repariert
Prompt Injection bleibt unberührt. Nichts an einem Proxy macht einen Agenten besser darin, Anweisungen zu ignorieren, die in den Daten stecken, die er liest. Ein Agent, den man überreden kann, eine unerwünschte Slack-Nachricht zu posten, wird weiterhin überredet werden können. Der Proxy verändert, was ein Angreifer mitnimmt, nicht ob er Einfluss nehmen kann. Wer das verwechselt, baut auf einer Annahme, die nicht trägt.
Zweitens bleibt der API-Key des Proxy-Anbieters selbst in der Runtime. Er authentifiziert jeden Aufruf der Umgebung, und er verschwindet nicht dadurch, dass ein anderes Secret verschwunden ist. Er gehört zur Laufzeit injiziert und nicht in agentensichtbaren Code oder Prompts gebacken, und er muss rotiert werden, wenn eine Runtime kompromittiert wurde. Ein Secret außer Reichweite zu bringen und dabei ein mächtigeres liegen zu lassen, ist ein Seitwärtsschritt und keine Verbesserung.
Drittens bleiben Provider-Berechtigungen Provider-Berechtigungen. Delegierte Aufrufe sind durch erlaubte Hosts eingeschränkt, nicht dadurch, was ein bestimmter Agent eigentlich tun dürfte. Feingranulare Autorisierung für Agentenaktionen ist eine echte Lücke; ein Chokepoint ist der natürliche Ort, an dem man sie irgendwann schließt, aber dass der Chokepoint existiert, ist nicht dasselbe wie eine Policy. Wer heute einen Agenten mit einem Token losschickt, sollte sich deshalb nicht die Frage stellen, ob der Prompt robust genug ist. Die Frage ist, was an dem Tag passiert, an dem er es nicht ist.
Was sich real ändert: die Schadensfläche
Ein solcher Umbau liefert eine veränderte Schadensfläche. Ein geleaktes Token ist eine dauerhafte, portable, offline nutzbare Fähigkeit: Es funktioniert von einem fremden Rechner, zu einer beliebigen Uhrzeit, ohne dass jemand etwas merkt. Eine gekaperte Agenten-Session ist dagegen ein laufender Prozess, den man beenden kann, mit Aufrufen, die durch einen einzigen Punkt fließen, an dem man sie beobachten und abschneiden kann. Das sind sehr unterschiedliche Vorfälle, und einer davon endet in dem Moment, in dem jemand hinsieht.
Der Gedanke ist nicht neu, und das spricht für ihn. Im Zahlungsverkehr ist er längst Standard: Card Vaults und Tokenisierung existieren, weil der schnellste Weg, den Umfang eines Audits zu verkleinern, darin besteht, den sensiblen Wert gar nicht erst in die eigenen Systeme zu lassen. Dieselbe Logik gilt für OAuth-Access-Token-Sicherheit in Agenten-Runtimes, und zwar aus demselben Grund: Man kann nicht leaken, was man nie gehalten hat. In der Rezeptions-Metapher bleibt der Generalschlüssel dort, wo jemand auf ihn achtgibt, und der Mitarbeiter bekommt jedes Mal nur die eine Tür geöffnet, für die er einen Auftrag hat.
Die belastbare Version dieses Prinzips hängt an keinem bestimmten Produkt. Sie lautet, dass Credentials in die am schwersten erreichbare Komponente gehören, die die Aufgabe noch erledigen kann — und Agenten-Runtimes sind in den meisten Architekturen inzwischen die am leichtesten erreichbare. Sie lesen von Angreifern kontrollierten Text, sie protokollieren alles, sie speichern Zustand, um voranzukommen, und sie handeln nach eigenen Schlüssen. Das ist ein guter Ort, um eine Entscheidung zu treffen. Es ist ein schlechter Ort, um einen Schlüssel aufzubewahren. Wenn du morgen einen Agenten mit einem Token ausstattest: Der Proxy besiegt keine Prompt-Injection. Er sorgt dafür, dass aus einem monatelang gültigen Diebstahl ein Vorfall wird, der endet, sobald du ihn bemerkst.
Quelle: workos.com
