So begrenzt Vercel Agent den Produktionszugriff mit genehmigten Plänen und eng gefassten Tokens

Pläne statt breitem Zugriff oder ständiger Rückfragen

Vercel beschreibt bei den Berechtigungen von Agenten einen Zielkonflikt. Bei breitem Zugriff kann ein Fehler unbeteiligte Ressourcen treffen. Bei Freigaben für jeden einzelnen Schritt bestätigen Nutzer einzelne Aktionen, noch bevor sie wissen, wie der Agent das Problem lösen will, und wiederholte Abfragen können dazu führen, dass die Prüfung zur Klickgewohnheit wird.

Vercel Agent geht einen anderen Weg. Bei einem fehlerhaften Produktions-Deployment kann er etwa aktuelle Deployments und Build-Logs prüfen und das fehlgeschlagene Deployment mit dem letzten bekannt funktionierenden vergleichen. Lesezugriff erlaubt es, diese Untersuchung automatisch laufen zu lassen. Führt sie zu dem Vorschlag, neu zu deployen, fordert der Agent den zusätzlichen Zugriff in einem Plan an, den der Nutzer in einer einzigen Entscheidung genehmigen kann.

Der Zugriff wird über Scopes definiert, also benannte Berechtigungen, die das Autorisierungssystem von Vercel kennt. In Vercels Beispiel braucht die Untersuchung read:deployment, das Neu-Deployen des letzten bekannten funktionierenden Builds dagegen read-write:deployment. Die schreibgeschützte Basis umfasst derzeit alle registrierten Scopes, die mit read: beginnen. Pläne brauchen eine Genehmigung, wenn sie Zugriff über diese Basis hinaus anfordern oder unterstützte externe Aktionen enthalten, etwa das Öffnen eines GitHub-Pull-Requests. Vercel weist zudem darauf hin, dass auch rein lesende Vorgänge sensible Informationen offenlegen können, die automatische Freigabe also nicht bedeutet, dass die Arbeit harmlos ist.

Tokens, die durch die eigenen Rechte des Nutzers begrenzt sind

Vercel Agent läuft als Vercel App, die der Nutzer autorisiert, in seinem Namen innerhalb eines Teams zu handeln. Diese Autorisierung ist durch die bestehenden Berechtigungen des Nutzers begrenzt, sodass die Genehmigung eines Plans keinen Zugriff gewähren kann, den der Nutzer nicht hat. Der Vercel-OAuth-Dienst tauscht die Autorisierung gegen kurzlebigere Tokens mit bestimmten Scopes ein, und die Vercel-APIs prüfen das Token bei jeder Anfrage.

Vercel betont, dass Scopes weiter gefasst sind als eine einzelne Aufgabe. Schreibzugriff auf Deployments umfasst mehr als ein Neu-Deployen, und die Nennung von Deployment X in einem Plan beschränkt das Token für sich genommen nicht auf dieses Deployment. Das Bearbeiten von Umgebungsvariablen, das Ändern von Domains und die Verwaltung von Team-Mitgliedschaften erfordern jeweils eigene Berechtigungen.

• Die schreibgeschützte Untersuchung nutzt ein Basis-Token mit Nur-Lese-Scopes.
• Genehmigte Vercel-Änderungen nutzen ein Token mit den Basis-Scopes plus den genehmigten zusätzlichen Scopes.
• Externe Aktionen nutzen Zugangsdaten und Berechtigungen, die für den jeweiligen Anbieter spezifisch sind.

Die Anweisungen des Modells legen fest, wann es einen Plan vorschlagen soll. Versucht es eine Operation außerhalb der Berechtigungen des Tokens, lehnen die Vercel-APIs die Anfrage ab, selbst wenn das Modell die Aktion für nötig hält. Ein einzelner Plan kann Vercel-Änderungen und einen GitHub-Pull-Request kombinieren. Der GitHub-Zugriff ist an einen Eigentümer und ein Repository gebunden, sodass die Genehmigung für acme/storefront nicht für acme/payments gilt, das eine eigene Genehmigung bräuchte.

Ein Scope-Register und wiederaufnehmbare Genehmigungen

Vercel zufolge führte man zunächst eine separate Berechtigungsliste für den Agenten, die vom OAuth-Dienst, der die Tokens ausstellt, abweichen konnte. Inzwischen nutzt man dieselben Scope-Definitionen. Beim Einrichten der Sitzung lädt der Agent sie aus dem Vercel-Scope-Register in einen In-Memory-Katalog, der für die Validierung von Plänen, die Genehmigung und die Token-Vorbereitung verwendet wird. Unbekannte oder fehlerhafte Scope-Namen werden abgelehnt, bevor ein Plan gespeichert oder angezeigt wird. Fordert eine Aufgabe einen veralteten Scope an, liefert das System gültige Scopes zurück, damit der Agent den Plan korrigieren kann, statt auf breiteren Zugriff auszuweichen. Weil das Abrufen des Registers Latenz und eine Dienstabhängigkeit mit sich bringt, wird der Katalog zwischengespeichert, und Prüfungen beruhen auf den gecachten Definitionen, bis er aktualisiert wird.

Die Genehmigung kann eintreffen, nachdem die ursprüngliche Chat-Anfrage beendet ist, oder der Agent kann vor einem genehmigten Neu-Deployment die Verbindung verlieren. Der gespeicherte Plan hält seinen Status fest, wer ihn genehmigt hat, wann, welche Aufgaben er enthält und welche Berechtigungen angefordert wurden. Vor der Wiederaufnahme lädt die Laufzeitumgebung den Plan neu und prüft, ob er aktiv ist. Ein gestoppter Plan besteht diese Prüfung nicht, selbst wenn sein Token noch Restlaufzeit hat. Treffen Genehmigung und Stopp-Anfrage gleichzeitig ein, wechselt der Plan nur dann in den Status aktiv, wenn der Stopp seinen Status nicht bereits geändert hat. Ein Ersatzplan, der erhöhten Zugriff anfordert, braucht eine eigene Genehmigung.

Was das für Teams bedeutet, die Agenten in Produktion einsetzen

Für Nutzer bedeutet das Design: Der Agent kann mit Lesezugriff eigenständig untersuchen, während jede Änderung auf einen prüfbaren Plan wartet. Die Genehmigung kann die eigenen Rechte des Nutzers nicht übersteigen, und die APIs setzen Grenzen auch dann durch, wenn das Modell sich irrt. Vercel ergänzt, dass man die Zugriffsregeln für Aktionen mit mehreren Ressourcen oder unterschiedlichen Folgen nachbessern musste, als der Agent mehr Teile der Plattform erreichte. Das Zuweisen einer Domain kann sowohl Domain- als auch Projektberechtigungen erfordern, und das Vorbereiten einer Firewall-Regel sowie ihre Veröffentlichung brauchen unterschiedliche Zugriffsstufen.