Vertiefende Analyse · Etwa 5 Min. Lesezeit
Vercel will dauerhafte Agentenschlüssel durch begrenzte Identitäten ersetzen
OIDC-Werkzeuge, Token-Austausch zur Laufzeit und geplante Marketplace-Regeln setzen passende Vertrauensrichtlinien und Benutzerrechte voraus.
- Hier veröffentlicht
- Datum der Quelle
- Quelle geprüft
In einem technischen Beitrag vom 22. Oktober 2026 erläutert Vercel-CTO Malte Ubl den Wechsel von wiederverwendbaren Geheimnissen zu kurzlebigen Dienstidentitäten. Es geht um den Zugriff von KI-Agenten, dessen Prüfung durch Anbieter und Anreize zur Umstellung ihrer Integrationen.
Nachrichten anhören
Diesen Artikel vorlesen oder mit den Nachrichten fortfahren.
Vorlesen wird vorbereitet…
Gerätestimme
Browser oder Gerät verarbeiten die Sprache. AISubHub sendet den Text nicht an eine Audio-API. Stimmen und Wiedergabe bei gesperrtem Bildschirm hängen vom Gerät ab.
Beim Fortsetzen kann sich ein kurzer Satzteil wiederholen.
Auf einen Blick
- Vercel nennt 8,4% Unterstützung sicherer Authentifizierung in einer Umfrage unter mehr als 1000 SaaS-Anbietern; das ist keine Sicherheitsbewertung der Branche.
- Geplant sind Marketplace-Warnungen bis zum 30. November 2026 und die Entfernung von Anbietern ohne die angekündigte sichere Authentifizierung bis Januar 2027.
1. Eine kürzere Laufzeit begrenzt ein bestimmtes Risiko
Ein Agent, der mehrere Dienste aufruft, kann Schlüssel mit mehr Rechten erhalten, als seine aktuelle Aufgabe benötigt. Eine gestohlene Kopie kann nach Gesprächsende weiter funktionieren. Ubl nennt Repositories, Chats, kompromittierte Abhängigkeiten und Prompt-Injection als mögliche Offenlegungswege. Verschlüsselung gespeicherter Geheimnisse verhindert nicht, dass Schadcode auf Zugangsdaten einer laufenden Anwendung zugreift. Entscheidend sind sowohl der Umfang als auch die Dauer der Berechtigung.
Vercel befragte nach eigenen Angaben mehr als 1000 SaaS-Anbieter; 8,4% unterstützten die als sicher bezeichneten Methoden. Angaben zu Stichprobe und Klassifizierung reichen im Beitrag nicht für eine repräsentative Branchenschätzung aus. Gemessen wird gemeldete Unterstützung, nicht Einbruchswahrscheinlichkeit oder tatsächliche Bereitstellungsqualität. Auch die von Vercel geschilderten Tausenden Entwicklungsstunden für vorsorgliche Schlüsselrotationen sind keine gemessene Einsparung für jeden Kunden.
2. Die Identität muss zur Vertrauensgrenze passen
Bei OpenID Connect, kurz OIDC, signiert ein vertrauenswürdiger Aussteller ein temporäres Token zur Identifizierung der Anwendung. Der empfangende Dienst prüft es und entscheidet dann über erlaubte Aktionen. Projekt- und Umgebungsregeln begrenzen akzeptierte Bereitstellungen; die Audience bezeichnet den vorgesehenen Empfänger. Eine gültige Signatur allein beweist weder, dass dieses Token an diese API gehört, noch dass jede Aktion erlaubt ist.
Ein offengelegtes temporäres Token bleibt bis zum Ablauf innerhalb seiner Rechte nutzbar. Die kurze Laufzeit begrenzt diese Kopie, verhindert aber weder das Leck noch Ersatzanforderungen einer kompromittierten Anwendung. Laut Vercel ist die Föderation seit 2024 allgemein verfügbar und tauscht Bereitstellungsidentität gegen temporäre AWS-, Google-Cloud- und Azure-Zugangsdaten. Blob, AI Gateway und Sandbox sind bestehende Beispiele, keine mit diesem Beitrag erstmals eingeführten Dienste.
3. Connect und OIDC UI bedienen unterschiedliche Seiten
Vercel Connect fordert zur Laufzeit mit der Bereitstellungsidentität ein Anbieter-Token an. Im Linear-Beispiel werden ein Benutzer und Lesezugriff angegeben. Vorausgesetzt sind ein konfigurierter, mit dem Projekt verbundener Connector, das verbundene Benutzerkonto und vom Anbieter unterstützte Scopes. Ein Funktionsaufruf erschließt somit nicht beliebige Konten, ersetzt keine Kontoverbindung und vereinheitlicht nicht die Berechtigungsmodelle aller Anbieter.
OIDC UI richtet sich an API-Anbieter: Die shadcn/ui-Registry liefert Formulare für Vertrauensrichtlinien und serverseitigen Prüfcode. Die gezeigte Oberfläche trennt Aussteller, Team, Projekt, Umgebung und Audience. Das kann wiederholte Entwicklungsarbeit verringern. Unsere Analyse: Die richtige Vertrauensgrenze wählt das Werkzeug nicht. Zu breit akzeptierte Projekte oder eine falsche Audience bleiben Richtlinienfehler, auch wenn Formular und Prüfer erfolgreich erzeugt werden.
4. Der Austausch bleibt von Netzwerkaufrufen abhängig
Der Beitrag unterscheidet das Lesen eines vorhandenen Tokens vom Austausch. Vercel Functions erhält ein Plattform-Identitätstoken im Request-Header, das das SDK ohne erneuten Abruf lesen kann. Die Plattform verwendet nicht abgelaufene Tokens erneut; Connect speichert Anbieter-Tokens im Prozess und erneuert sie nahe dem Ablauf. Benutzerdefinierte Audiences und Anbieter-Austauschvorgänge benötigen weiter Netzwerkaufrufe. Das ist keine Zusage zusätzlicher Latenz von null für sämtliche Authentifizierung.
Das Cosmos-DB-Beispiel zeigt die Schritte: Azure muss dem Vercel-Projekt und der Standard-Audience vertrauen; ClientAssertionCredential legt das Vercel-Token für den Austausch gegen ein Azure-Zugriffstoken vor; CosmosClient nutzt das Ergebnis. Erneuerung und Anbieter-Verfügbarkeit sind neben dem ersten erfolgreichen Aufruf zu prüfen. Ein unabhängiger Latenzvergleich oder die Garantie, dass Caching Authentifizierungsausfälle verhindert, fehlt.
5. Marketplace-Fristen sollen Anreize setzen
Ubl nennt drei Hürden: schwierige Einrichtung, zusätzliche Latenz im Anfragepfad und schwache Anbieteranreize. Die dritte adressiert Vercel über den Marketplace. Bis zum 30. November 2026 sollen Einträge von Anbietern ohne OIDC-Authentifizierung aus Vercel, die weiter langlebige Geheimnisse nutzen, als “Not secure” gekennzeichnet werden. Anbieter ohne sichere Authentifizierung sollen bis Januar 2027 entfernt werden.
Das sind angekündigte künftige Anforderungen im Vercel-Ökosystem, keine bereits abgeschlossene Durchsetzung und kein universelles Gesetz. Ein genauer Januartag oder Ausführungszeitpunkt wird nicht genannt. Vercel will API und native Integrationen am gleichen Maßstab messen; die automatische Einrichtung beim Verbinden von Diensten ist noch in Arbeit. Prüfen Sie die tatsächliche Unterstützung jeder Integration, statt jede Marketplace-Verbindung bereits als föderiert anzusehen.
6. Eine Migration muss Berechtigungen prüfen
Als Lehrbeispiel dient ein Agent, der nur die Linear-Aufgaben eines Benutzers liest. Wir empfehlen, dauerhafte Schlüssel zu erfassen und je Dienst Bereitstellung, Benutzer und nötige Rechte zuzuordnen. Nach Einrichtung von Vertrauen und Benutzerverbindung sollte der erlaubte Lesezugriff gelingen, ein anderes Projekt, eine andere Umgebung, Audience oder unerlaubte Aktion dagegen abgewiesen werden. Dies ist eine vorgeschlagene Prüfmethode, kein AISubHub-Test und kein zusätzliches Vercel-Versprechen.
Vor dem Entfernen des alten Schlüssels sind Ablauf, Erneuerung, Cache und Austauschfehler mit einem ausdrücklichen Wiederherstellungsplan zu prüfen. Ein erfolgreich ausgestelltes Token kann übermäßige Rechte oder eine fragile Erneuerung verdecken. Der nützliche Wechsel betrifft begrenzte, erneuerbare Autorität mit nachvollziehbaren Grenzen. Er macht Agenten nicht zugangsdatenfrei, löst Prompt-Injection nicht und garantiert keine Protokollunterstützung aller nachgelagerten Anbieter.
Warum es wichtig ist
Unsere Analyse: Bereitstellungsidentitäten können die Verteilung langlebiger Anbieterschlüssel reduzieren, müssen aber vom Empfänger akzeptiert und begrenzt werden. Marketplace-Anreize könnten die Unterstützung verbreitern; Konfiguration und Benutzerautorisierung bleiben nötig.
Grenzen und Verfügbarkeit
Analyse des offiziellen Beitrags und seiner Konfigurationsabbildung, ohne unabhängiges Sicherheitsaudit oder Leistungstest. Die Umfragemethode ist unvollständig; geplante Fristen sind keine vollzogene Durchsetzung. Konten, Integrationen oder Produktionskonfigurationen wurden nicht geändert.
Quellen und Belege
Datum der Quelle: · Quelle geprüft:
KI-gestützte redaktionelle Beiträge, anhand der genannten Primärquellen geprüft. Anbieterangaben werden zugeordnet; eine Aufnahme ist keine Empfehlung.