# API-Scopes für autonome Coding-Agenten, die Risiken begrenzen Ein autonomer Coding-Agent sollte Zugangsdaten für eine klar definierte Aufgabe erhalten, nicht Zugangsdaten, die zufällig alle Fehler verschwinden lassen. Die schwierige Frage ist nicht, eine Scope-Bezeichnung wie `write` zu finden. Entscheidend ist der Nachweis, dass das Token eine bestimmte Aufgabe erledigen kann, während benachbarte Aktionen außerhalb dieser Aufgabe scheitern. Ich habe erlebt, wie Teams mit einem persönlichen Token begannen, weil der Agent «erst einmal loslegen» sollte. Wochen später konnte dieses Token jedes Repository lesen, mit dem der Entwickler jemals gearbeitet hatte, Deployment-Einstellungen ändern und destruktive Anfragen senden, die mit der ursprünglichen Aufgabe nichts zu tun hatten. Der Agent hatte dieses Risiko nicht geschaffen. Die nachlässig gesetzte Berechtigungsgrenze hatte es getan. ## Eine Aufgabe ist enger als eine Rolle Eine Agentenaufgabe beschreibt ein Ergebnis und eine begrenzte Menge von Zustandsänderungen. Eine Rolle beschreibt eine Person oder einen Dienst in groben Begriffen. Wenn du den Zugriff aus der Rolle ableitest, gewährst du fast immer mehr, als die Aufgabe verlangt. Nehmen wir eine Anfrage wie: «Aktualisiere eine Abhängigkeit im Zahlungsdienst, führe die Tests aus und eröffne einen Pull Request.» Der Agent muss möglicherweise ein Repository lesen, einen Branch erstellen, Commits in diesen Branch pushen und einen Pull Request erstellen. Vielleicht braucht er Lesezugriff auf Build-Logs, wenn der Testdienst sie über eine API bereitstellt. Er muss weder die Organisation verwalten, Regeln für geschützte Branches ändern, Deployment-Zugangsdaten rotieren noch seine eigene Arbeit mergen. Formuliere Aufgabenverträge als Verben für benannte Ressourcen. Schreibe nicht «Repository schreiben». Schreibe, was der Agent tatsächlich tun darf: - Quellcode, Issues und vorhandene Pull Requests im Repository `payments-service` lesen. - Branches erstellen und aktualisieren, deren Namen mit `agent/` beginnen. - Einen Pull Request von diesem Branch zum festgelegten Ziel-Branch erstellen. - Status und Logs des Workflows lesen, den dieser Pull Request gestartet hat. - Einen Kommentar mit dem Testergebnis veröffentlichen. Das ist keine Bürokratie. Die Liste macht offene Entscheidungen sichtbar. Darf der Agent ein Issue schließen? Darf er den Pull Request einer anderen Person bearbeiten? Darf er einen teuren Workflow erneut starten? Muss er ein Paket aus einer privaten Registry abrufen? Für jedes Verb wird eine Berechtigung vergeben oder das Verb gestrichen. Ein Aufgabenvertrag unterscheidet außerdem zwischen einem notwendigen Nebeneffekt und einem bequemen. Ein Agent möchte vielleicht nach dem Eröffnen eines Pull Requests ein Issue-Label aktualisieren. Das kann nützlich sein, macht die Abhängigkeitsaktualisierung aber nicht möglich. Lass es aus dem ersten Berechtigungssatz heraus. Füge es erst hinzu, wenn jemand die Wirkung akzeptiert und die Grenze getestet hat. Behandle wiederkehrende Jobs als getrennte Aufgaben, auch wenn ein Prozess sie alle ausführt. Eine nächtliche Abhängigkeitsprüfung, die Freigabe eines Releases und ein Rollback in der Produktion haben unterschiedliche Folgen. Eine Identität mit einem angesammelten Stapel von Berechtigungen macht alle drei Aufgaben schwerer zu prüfen und sauber zu widerrufen. ## Scope-Namen sind keine Berechtigungsgrenzen Ein Scope-String ist eine Eingabe für die Autorisierung, kein Beweis dafür, dass ein API-Aufruf sicher ist. Anbieter verwenden das Wort «Scope» für verschiedene Mechanismen: OAuth-Strings, Repository-Berechtigungen, Projektrollen, Installationsfreigaben und Tokens, die auf eine Ressourcenliste beschränkt sind. Diese Mechanismen sind nicht austauschbar. OAuth 2.0 RFC 6749 definiert Scope als eine durch Leerzeichen getrennte Menge von Strings, die den Zugriff eines Access-Tokens begrenzt. Die Bedeutung jedes Strings überlässt der Standard bewusst dem Autorisierungsserver. Diese Flexibilität ist für Anbieter nützlich. Sie bedeutet aber auch, dass `repo:write`, `projects.write` und `api` kaum etwas aussagen, bevor du die Endpoint-Dokumentation des Anbieters geprüft und das Token getestet hast. RFC 8707 ergänzt Resource Indicators. Ein Client kann ein Token für eine bestimmte geschützte Ressource anfordern, statt jeden Endpoint hinter einem Autorisierungsserver als ein gemeinsames Ziel zu behandeln. Das hilft, wenn ein Aussteller diese Funktion unterstützt. Es repariert jedoch keinen Anbieter, der einen einzigen weit gefassten Scope auf jedes Projekt oder jeden destruktiven Endpoint innerhalb dieser Ressource abbildet. Halte diese drei Ebenen in deinen Designnotizen getrennt: | Ebene | Welche Frage sie beantwortet | Fehler bei einer Verwechslung | |---|---|---| | Token-Scope | Welche Berechtigungsbezeichnungen hat der Aussteller in dieses Token aufgenommen? | Du gehst davon aus, dass eine freundliche Bezeichnung eine enge Aktion bedeutet. | | Ressourcenfreigabe | Welche Repositories, Projekte, Konten oder Umgebungen kann diese Identität erreichen? | Das Token kann auf eine benachbarte Ressource zugreifen. | | Endpoint-Regel | Welche Methode und welcher Pfad werden von der API für diese Anfrage akzeptiert? | Eine Schreibfreigabe erlaubt Löschen oder Verwaltung. | Die häufige schlechte Empfehlung lautet: «Verwende nur read und write.» Sie ist beliebt, weil sie in eine Einrichtungsanleitung passt und oft beim ersten Versuch funktioniert. Sie ist falsch, weil write häufig mehrere voneinander unabhängige Verben abdeckt. Das Erstellen eines Pull Requests, das Löschen eines Repositories, das Ändern eines Webhooks und das Bearbeiten der Zugriffskontrolle können alle hinter derselben weit gefassten Freigabe liegen. Wenn ein Anbieter nur einen breiten Scope anbietet, tu nicht so, als hättest du Least Privilege durch eine sorgfältige Benennung erreicht. Begrenze stattdessen die Ressourcenebene. Erstelle ein eigenes Repository, Projekt, eine eigene Umgebung oder ein eigenes Servicekonto mit Zugriff nur auf das Ziel. Wenn der Agent eine einzelne Aktion in der Produktion braucht, gib ihm dafür eine separate Identität und verlange eine ausdrückliche Genehmigung. Das grobe Modell des Anbieters bleibt grob, aber das Credential kann weniger erreichen. ## Vor der Token-Ausgabe ein Endpoint-Verzeichnis erstellen Ein Endpoint-Verzeichnis verwandelt eine vage Anfrage in ein prüfbares Berechtigungsdesign. Es hält jeden Aufruf fest, den der Agent ausführen darf, den Grund dafür, die erreichbare Ressource und die genaue Berechtigung, die ihn ermöglicht. Beginne mit der Aktionsfolge, nicht mit der Berechtigungsseite des Anbieters. Ein Agent, der einen Pull Request eröffnet, braucht oft mehr Aufrufe als erwartet: Er liest die Basisrevision, erstellt eine Referenz, erstellt oder aktualisiert Dateien, ruft den Workflow-Status ab und übermittelt einen Pull Request. Eine Berechtigungsseite zeigt selten, welcher dieser Aufrufe für deinen konkreten Ablauf zwingend nötig ist. Verwende ein Verzeichnis wie dieses. Ersetze die Beispielpfade durch die Pfade, die dein Anbieter tatsächlich dokumentiert. ```yaml task: update dependency and open pull request resource: org/payments-service calls: - method: GET path: /repos/org/payments-service/contents/package-lock.json purpose: read current dependency lockfile permission: contents:read - method: POST path: /repos/org/payments-service/git/refs constraint: "ref starts with refs/heads/agent/" purpose: create working branch permission: contents:write - method: PUT path: /repos/org/payments-service/contents/package-lock.json constraint: "branch starts with agent/" purpose: commit updated lockfile permission: contents:write - method: POST path: /repos/org/payments-service/pulls constraint: "base is main; head starts with agent/" purpose: request review permission: pull_requests:write forbidden_calls: - DELETE /repos/org/payments-service - PATCH /repos/org/payments-service/branches/main/protection - POST /repos/org/organization-hooks - GET /repos/org/another-service/contents/secrets.yml ``` Das Feld `constraint` ist wichtig, weil Endpoint-Berechtigungen häufig hinter Aufgabenberechtigungen zurückbleiben. Eine API kann das Erstellen von Branches erlauben, aber keine native Einschränkung auf das Präfix `agent/` anbieten. Halte diese Lücke fest. Du brauchst möglicherweise einen vorgeschalteten Aktionsdienst, ein separates Repository oder eine Prüfstufe, weil ein Scope die gewünschte Branch-Regel nicht erzwingen kann. Verlasse dich nicht auf eine Agentenaufforderung, um die Einschränkungen einzuhalten. Ein Prompt kann das gewünschte Branch-Präfix beschreiben, aber er kann eine an `main` gesendete Anfrage nicht zurückweisen. Die Durchsetzung muss beim API-Anbieter, in den Einstellungen der Zielressource oder in einem Aktions-Gateway liegen, das die Anfrage vor dem Versand prüft. Das Verzeichnis sollte Leseaufrufe ebenso ernst nehmen wie Schreibaufrufe. Das Lesen eines Deployment-Geheimnisses, eines Kundendatenexports, einer Sicherheitswarnung oder eines zweiten Repositories kann mehr offenlegen als ein fehlerhafter Commit. Die meisten Berechtigungsprüfungen konzentrieren sich auf Schreibzugriffe, weil diese sichtbar sind. Der Kontext, den der Agent erhält, macht weit gefasste Lesezugriffe ebenfalls gefährlich. ## Discovery- und Änderungszugriff trennen Discovery- und Änderungszugriff sollten normalerweise über unterschiedliche Credentials laufen, weil ein Agent häufiger breiten Kontext als weitreichende Befugnis zur Zustandsänderung braucht. Ein Planungsagent muss vielleicht Code durchsuchen, Issues prüfen, Build-Ausgaben untersuchen und Versionen in mehreren Repositories vergleichen. Ein Patch-Agent muss möglicherweise nur in einem Branch eines Repositories schreiben. Wenn beide Aufgaben dasselbe Token verwenden, erbt der Patch-Agent die große Leseoberfläche des Planers und der Planer eine Schreibfähigkeit, die er nie braucht. Teile die Arbeit in Stufen auf, wenn der Anbieter das zulässt. Die Discovery-Phase erzeugt einen begrenzten Plan oder Patch-Vorschlag. Ein zweiter Prozess erhält dieses Artefakt und ein engeres Credential, um die gewünschte Änderung vorzunehmen. Wenn die Änderung einen geschützten Bereich betrifft, kann ein Mensch die Übergabe prüfen. Diese Trennung fängt einen praktischen Fehler auf, den Prompts nicht verhindern können. Angenommen, ein Planer durchsucht eine Organisation nach Verweisen auf ein Paket und findet ein altes internes Repository mit Deployment-Notizen. Wenn dasselbe Token in jedes gelesene Ergebnis pushen kann, kann ein späterer, falscher Tool-Aufruf das falsche Repository ändern. Das Modell kann die Aufgabe vollständig verstehen und trotzdem den falschen Bezeichner auswählen. Wird der Schreiber auf das vorgesehene Repository beschränkt, wird dieser Fehler zu einer abgelehnten Anfrage. Teile Tokens nicht nur auf, um mehr Tokens zu erzeugen. Teile sie auf, wenn sich erlaubte Ressourcen oder Verben unterscheiden. Ein einzelnes Lese-Token kann eine zusammenhängende Untersuchung unterstützen. Ein einzelnes Schreib-Token kann eng verwandte Änderungen in einem Ziel ermöglichen. Der Zweck besteht darin, die Antwort jedes Tokens auf die Frage «Was kann dieser Prozess tun?» so kurz zu halten, dass ein Entwickler sie ohne Vermutungen prüfen kann. Trenne bei der Quellcodeverwaltung die Schreibberechtigung für Branches möglichst von der Merge-Berechtigung. Ein Branch ist eine vorgeschlagene Änderung. Ein Merge verändert die gemeinsame Grundlage und löst häufig Deployments, Releases oder nachgelagerte Automatisierung aus. Der Agent kann einen nützlichen Pull Request eröffnen, ohne die Berechtigung zum Mergen zu erhalten. ## Die Ressource begrenzen, bevor du den Scope verfeinerst Ein enger Scope an einem organisationsweit gültigen Credential ist oft schlechter als ein breiter Scope an einem vergänglichen, isolierten Ziel. Der Scope kontrolliert Verben. Ressourcengrenzen bestimmen, wo diese Verben wirken. Du brauchst beides, aber Ressourcengrenzen machen Fehler meist überlebbar. Gib autonomen Agenten Service-Identitäten statt persönlicher Tokens. Persönliche Zugriffstokens übernehmen häufig alte Mitgliedschaften eines Menschen, vorübergehende Administratorrechte und Zugriffe auf Projekte, an die bei der Einrichtung niemand gedacht hat. Der spätere Widerruf kann außerdem unabhängige Arbeit unterbrechen, weshalb Teams ihn aufschieben. So werden vorübergehende Ausnahmen zu dauerhaftem Zugriff. Eine eigene Identität sollte ohne Zugriff beginnen und nur die im Endpoint-Verzeichnis aufgeführten Ressourcenfreigaben erhalten. Arbeitet ein Agent an einem Repository, gib ihm dieses Repository statt der ganzen Organisation. Aktualisiert er ein Staging-Deployment, gib ihm die Staging-Umgebung statt aller Umgebungen. Schreibt er Datensätze für ein Kundenkonto, gib ihm dieses Konto statt eines globalen API-Credentials. Verwende getrennte Nichtproduktionsziele, um Berechtigungen zu testen. Ein Token durch echte Schreibvorgänge in der Produktion zu testen, zeigt zwar, ob es funktioniert, beweist aber nicht, dass es angemessen begrenzt ist. Ein Test-Repository oder -Projekt erlaubt dir, Erstellen, Aktualisieren, Fehlschlagen, Widerruf und Audit-Verhalten auszuführen, ohne Bereinigungsarbeiten in einem Live-System zu hinterlassen. Ressourcenisolation gleicht auch APIs mit ungünstigen Scope-Modellen aus. Manche Dienste stellen ein Token mit einem einzigen Scope `api` und ohne Granularität auf Endpoint-Ebene aus. Du kannst trotzdem ein eigenes Projekt mit nur den erlaubten Ressourcen erstellen, die Organisationsverwaltung verweigern und für jede Umgebung eine eigene Identität verwenden. Das ist weniger elegant als eine fein abgestufte API, aber deutlich besser, als einem Prozess, der Anfragen dynamisch erstellt, ein universelles Token zu geben. Gib einem Agenten nicht nur deshalb Zugriff auf die Produktion, weil der von ihm geänderte Code später in die Produktion gelangt. Das Releasesystem sollte diesen Übergang über einen genehmigten, separat autorisierten Weg steuern. Wenn die Aufgabe tatsächlich eine Produktionsaktion umfasst, schreibe dafür einen eigenen Vertrag. Er sollte Zielumgebung, erlaubte Methode, zulässige Parameter, Rollback-Verhalten und die genehmigende Person nennen. ## Erfolg und Ablehnung als gemeinsamen Vertrag testen Ein Berechtigungssatz ist erst vollständig, wenn du zwei Dinge nachweist: Der Agent kann seine Aufgabe abschließen, und nahe liegende, nicht zugewiesene Aktionen scheitern. Nur den Erfolgsfall zu testen, beweist Bequemlichkeit, nicht Begrenzung. Verwende für jede Berechtigungsänderung eine saubere Testidentität. Bestehende Credentials haben oft zwischengespeicherte Freigaben, geerbte Rollen oder einen zweiten Authentifizierungsweg, der einen Test aus dem falschen Grund erfolgreich erscheinen lässt. Halte vor dem Lauf Subject, vorgesehene Ressourcen, ausgestellte Scopes und Ablaufzeit des Tokens fest. Eine praktische Testfolge sieht so aus: 1. Erstelle eine vergängliche Zielressource und ein Credential mit den vorgeschlagenen Freigaben. 2. Führe den Agenten oder ein deterministisches Anfrage-Fixture durch jeden erlaubten Aufruf im Verzeichnis. 3. Prüfe den erwarteten Zustand, etwa Branch, Pull Request, Kommentar oder aktualisierten Datensatz. 4. Sende jeden verbotenen Aufruf mit demselben Credential und erwarte eine Ablehnung. 5. Entferne das Credential oder widerrufe die Sitzung. Führe dann einen zuvor erlaubten Aufruf erneut aus und erwarte eine Ablehnung. Verwende neben einem Agentenlauf direkte Anfragen. Sie entfernen die Unsicherheit bei der Tool-Auswahl und zeigen, ob der Anbieter selbst die Grenze durchsetzt. Dieses Shell-Fixture zeigt die Struktur eines solchen Tests. Es setzt eine API voraus, die JSON zurückgibt und `403` für eine authentifizierte Identität verwendet, der die Berechtigung fehlt. ```sh base="https://api.example.internal" auth="Authorization: Bearer $AGENT_TOKEN" curl -sS -o allowed.json -w "%{http_code}\n" \ -H "$auth" \ -X POST "$base/repos/acme/payments-service/pulls" \ -H "Content-Type: application/json" \ -d '{"head":"agent/dependency-bump","base":"main","title":"Update parser"}' # Expected output: 201 curl -sS -o denied.json -w "%{http_code}\n" \ -H "$auth" \ -X DELETE "$base/repos/acme/payments-service" # Expected output: 403 cat denied.json # Expected shape: {"message":"Resource not accessible by integration"} ``` Prüfe nicht nur den Statuscode. Untersuche bei erlaubten Aktionen den resultierenden Zustand. Manche APIs akzeptieren eine Anfrage und verarbeiten sie asynchron oder geben Erfolg zurück, obwohl sie ein vom Agenten benötigtes Feld ignorieren. Bei Ablehnungen musst du `401` und `403` unterscheiden. Ein `401` kann bedeuten, dass das Test-Credential fehlerhaft oder abgelaufen ist. Ein `403` nach erfolgreicher Authentifizierung zeigt besser, dass die Autorisierung den Aufruf blockiert hat. Da sich Anbieter unterscheiden, dokumentiere ihre Semantik in deinem Fixture. Halte für jede gefährliche Berechtigungsgrenze einen negativen Test vor. Wenn ein Agent ein Deployment erstellen darf, teste, dass er es nicht freigeben darf. Wenn er in einem Issue kommentieren darf, teste, dass er Labels oder Zuständige nicht ändern kann. Wenn er einen Secret-Wert in Staging schreiben darf, teste, dass er ihn nicht zurücklesen kann, sofern die API Schreiben ohne Lesen unterstützt. Diese Tests verhindern, dass eine spätere Scope-Änderung den Zugriff unbemerkt erweitert. ## Ein fehlgeschlagenes 403 sollte Aufgabe oder Freigabe ändern Eine Antwort `403 Forbidden` liefert Hinweise zum Vertrag. Sie sollte eine Entscheidung auslösen, nicht automatisch die breiteste Berechtigung des Anbieters. Ich habe dieses Muster häufig gesehen. Ein Agent erstellt einen Branch und committet eine Korrektur, wird aber beim Eröffnen eines Pull Requests abgewiesen. Jemand stellt fest, dass die Pull-Request-Berechtigung des Anbieters auch das Verwerfen von Reviews oder umfassendere Änderungen an Diskussionen erlaubt. Diese Berechtigung wird vergeben, weil der Agent fertig werden soll. Einige Tage später beginnt derselbe Agent, veraltete Pull Requests «aufzuräumen» und Arbeiten außerhalb seines Auftrags zu bearbeiten. Die erste Ablehnung enthielt eine Designfrage: Erfordert das Eröffnen eines Pull Requests tatsächlich diese umfassendere Fähigkeit, und kann das Team die Nebeneffekte akzeptieren? Es gibt mehrere ehrliche Antworten: - Vergib die Berechtigung, nachdem du die gesamte Endpoint-Oberfläche getestet und das akzeptierte Risiko festgehalten hast. - Ändere die Aufgabe so, dass der Agent einen Branch vorbereitet und ein Mensch den Pull Request eröffnet. - Verwende eine andere Anbieteridentität oder Ressource, bei der die breite Freigabe nur das vorgesehene Repository erreicht. - Schalte einen engen Aktionsdienst vor die API des Anbieters, der nur die Erstellung eines Pull Requests mit festen Ressourcen- und Branch-Grenzen akzeptiert. Die falsche Antwort ist, jeden Scope hinzuzufügen, der rote Antworten in grüne verwandelt. Damit werden Autorisierungsfehler zu verzögerten Vorfällen. Auch Anfragekörper verdienen Prüfung. Viele API-Berechtigungsmodelle autorisieren einen Endpoint, unterscheiden aber nicht zwischen sicheren und schädlichen Werten. `POST /deployments` kann unter derselben Berechtigung `staging` und `production` akzeptieren. `PATCH /projects/{id}` kann eine harmlose Beschreibung und eine gefährliche Sichtbarkeitsänderung erlauben. Wenn der Anbieter diese Vorgänge nicht trennen kann, muss die Grenze oberhalb des Endpoints liegen. Verlange eine menschliche Genehmigung, verwende ein eigenes Ziel oder stelle statt des direkten API-Zugriffs eine zweckgebundene Aktion bereit. Halte den abgelehnten Aufruf zusammen mit dem Grund im Verzeichnis fest, aus dem du ihn entweder hinzugefügt oder abgelehnt hast. In sechs Monaten erklärt dieser Eintrag, warum der Agent einen Branch erstellen, aber kein Repository umbenennen darf. Ohne ihn wird jemand die Grenze bei einer eiligen Korrektur als willkürlich betrachten und erweitern. ## Genehmigungsstufen fangen die verbleibenden folgenreichen Aufrufe ab Enge Anbieterberechtigungen reduzieren, was ein Agent versuchen kann. Genehmigungsstufen helfen bei erlaubten Aktionen, die trotzdem eine menschliche Entscheidung verdienen, etwa einer externen Zahlung, einem SSH-Befehl auf einem wichtigen Host oder einem Schreibzugriff auf einen Produktionsdienst. Verwende Genehmigungen nicht als Grund, dem Agenten weitreichende Credentials zu geben. Eine Bestätigung mit einem Klick kann einen offensichtlich falschen Aufruf stoppen, aber Menschen bestätigen wiederkehrende Karten schnell, besonders wenn ein Agent mehrere Routineaufrufe für eine Aufgabe braucht. Die Berechtigungsgrenze muss ganze Handlungskategorien abweisen, bevor überhaupt eine Genehmigungskarte erscheint. Setze Genehmigungen dort ein, wo menschlicher Kontext die Entscheidung verändert. Ein Deployment kann technisch autorisiert, während eines Vorfalls aber ungeeignet sein. Das Löschen eines Branches kann erlaubt, aber falsch sein, wenn ein anderer Entwickler ihn gerade verwendet. Eine Genehmigungsanfrage kann das tatsächliche Ziel und die angeforderte Aktion in dem Moment zeigen, in dem die Person sie beurteilen kann. Sallyport bewahrt API- und SSH-Zugangsdaten in seinem verschlüsselten macOS-Tresor auf und führt die angeforderte Aktion aus, ohne das Geheimnis dem Agenten zugänglich zu machen. Seine Sitzungsautorisierung und Genehmigungssteuerung pro Credential können eine Person in den Ablauf von Aufrufen einbinden, die eine Genehmigung verdienen. Die Scope-Gestaltung auf Anbieterseite entscheidet jedoch weiterhin, was ein genehmigtes Credential erreichen kann. Führe Audit-Aufzeichnungen, die zwei getrennte Fragen beantworten: Welcher Agentenprozess erhielt die Berechtigung zu handeln, und welche einzelnen API-Aufrufe führte er aus? Das sind unterschiedliche Aufzeichnungen. Eine Prozessfreigabe beweist, dass ein Mensch diesem Lauf die Verwendung eines Credentials erlaubt hat. Sie erklärt nicht, ob der Lauf einen Pull Request erstellt, eine Umgebungsvariable geändert oder einen fehlgeschlagenen Löschversuch unternommen hat. Prüfe beides nach einer Berechtigungsänderung und nach einem Vorfall. ## Scope-Prüfungen brauchen einen Anlass, keine Kalenderzusage Berechtigungsprüfungen funktionieren, wenn ein Ereignis in der Entwicklung sie auslöst. Eine vage vierteljährliche Erinnerung findet meist alte Tokens, nachdem sich niemand mehr an ihren Zweck erinnert. Verknüpfe die Prüfung mit Aufgabenänderungen, neuen Endpoints, einer Erweiterung der Ressourcen, Änderungen der Anbieterberechtigungen und Anpassungen am Agentenablauf. Bewahre das Endpoint-Verzeichnis gemeinsam mit dem Code auf, der den Agenten aufruft. Wenn ein Pull Request die Tool-Anweisungen eines Agenten ändert oder einen API-Aufruf hinzufügt, muss auch das Verzeichnis mit seinen positiven und negativen Tests aktualisiert werden. So steht die Berechtigungsentscheidung direkt neben dem Verhalten, das sie benötigt. Prüfe den Widerruf, bevor du ihn brauchst. Entferne ein Test-Credential und bestätige, dass ein zuvor erlaubter Aufruf scheitert. Deaktiviere die Service-Identität und bestätige, dass ein laufender Agent nicht über eine zwischengespeicherte Sitzung weitermachen kann. Prüfe, ob der Anbieter Refresh-Tokens oder doppelte Credentials ausgegeben hat, die denselben Zugriff erhalten. Teams entdecken solche Wege oft erst während eines Vorfalls, wenn die Erkenntnis am wenigsten nützt. Achte auf schleichende Berechtigungserweiterungen in kleinen Änderungen. Eine Anfrage zum Lesen von Workflow-Logs kann sich in die Berechtigung verwandeln, Jobs erneut auszuführen. Eine Anfrage zum Aktualisieren eines einzelnen Issues kann zu einer organisationsweiten Issue-Verwaltung werden. Der Zugriff auf eine Umgebung kann zu einem Produktions-Fallback «für alle Fälle» werden. Jeder neue Aufruf muss dieselbe Frage bestehen: Kann der Agent seine ausdrücklich genannte Aufgabe ohne ihn abschließen? Wenn die Antwort nein lautet, füge die kleinste Freigabe hinzu, die den Aufruf ermöglicht, und ergänze einen Ablehnungstest für den nächsten schädlichen Nachbarn. Wenn die Antwort ja lautet, lass ihn weg. Diese Disziplin macht Fehler von Agenten kurzfristig sichtbarer. Sie verhindert außerdem, dass eine fehlerhafte Anweisung, ein verwirrtes Modell oder ein kompromittierter Prozess ungewollt Befugnisse erbt.