Sicherheit bei API-Versionsupgrades für KI-Agents

Ein API-Versionsupgrade kann die Befugnisse eines Agents erweitern, ohne dass sich auch nur eine Zeile seiner Anweisungen ändert. Die gefährlichen Änderungen wirken in Release Notes meist harmlos: Ein Standardwert verschiebt sich, ein Endpunkt kommt hinzu, ein veraltetes Token erhält einen Kompatibilitätsweg oder eine Antwort enthält Datensätze, die die alte Version ausgelassen hat.

Von Menschen bediente Integrationen überstehen solche Unklarheiten manchmal, weil jemand einen unbekannten Bildschirm bemerkt oder vor einer merkwürdigen Anfrage innehält. Ein autonomer Programmier-Agent legt diese Pause nicht ein. Wenn er Anfragen aus Dokumentation bilden, Fehler untersuchen und Alternativen erneut versuchen kann, wird jede neu erreichbare Operation Teil seiner praktischen Befugnisse.

Versionsbezeichnungen messen keine Befugnisse

Eine Versionsnummer beschreibt das Kompatibilitätsversprechen eines API-Anbieters, nicht die Berechtigungsänderung, die ein Agent erlebt. Behandle jedes API-Upgrade als Berechtigungsprüfung, bis du verglichen hast, was das Credential vorher und nachher tun konnte.

Die Spezifikation Semantic Versioning sieht eine Änderung der MAJOR-Version vor, wenn eine inkompatible Änderung an der öffentlichen API erfolgt. Das hilft Bibliotheksautoren zu entscheiden, ob Aufrufer möglicherweise nicht mehr funktionieren. Es bedeutet nicht, dass ein MINOR-Release keinen neuen Administrationsendpunkt hinzufügen, einen Standardfilter erweitern oder ein Zugriffstoken für eine andere Zielgruppe akzeptieren kann. Alle drei Änderungen können kompatibel bleiben und trotzdem erweitern, was ein Agent erreichen kann.

Diese Unterscheidung ist wichtig, weil Teams oft die falsche Frage stellen: «Läuft unser Code weiterhin?» Die Frage, die das Konto schützt, lautet: «Welche Operationen kann dieser bestehende Agent jetzt erfolgreich ausführen, gegen welche Ressourcen und mit welchem Credential?»

Ein API-Upgrade hat vier getrennte Angriffsflächen:

• Anfragekompatibilität: Methoden, Pfade, Parameter und Format der Nutzdaten.
• Ressourcenzugriff: Konten, Projekte, Repositories, Dateien oder Datensätze, an die eine Anfrage gerichtet werden kann.
• Aktionszugriff: Lese-, Schreib-, Lösch-, Deployment-, Abrechnungs- und Identitätsoperationen, die abgeschlossen werden können.
• Credential-Akzeptanz: Welche Tokens, Schlüssel, Signaturen, Zielgruppen und Scopes der Anbieter akzeptiert.

Ein erfolgreicher Test der Anfragekompatibilität sagt über die anderen drei Bereiche fast nichts aus. Deshalb kann eine Änderung eine herkömmliche Regressionstestsuite bestehen und einem Agent trotzdem einen neuen Weg zu Produktionsdaten eröffnen.

Gehe nicht davon aus, dass eine datierte API-Version dieses Problem löst. Ein Anbieter kann eine datierte Oberfläche stabil halten und gleichzeitig einen gemeinsamen Authentifizierungsdienst ändern, optionale Felder hinzufügen, die ein Agent entdeckt, oder Standardwerte außerhalb des Endpunktpfads verändern. Eine festgelegte Version ist sinnvoll. Sie als Berechtigungsgrenze zu betrachten, ist fahrlässig.

Die Befugnisse vorher und nachher abbilden

Ein Upgrade lässt sich nicht allein anhand eines Changelogs prüfen. Erstelle eine kompakte Übersicht der Anfragen, die der Agent ausführen darf, und vergleiche anschließend das beobachtete Verhalten in der alten und der neuen Version.

Beginne mit echtem Datenverkehr, nicht mit dem vorgesehenen Design. Agents nutzen häufig mehr Endpunkte, als die ursprüngliche Aufgabe vermuten lässt: Discovery-Aufrufe, Wiederholungen nach Validierungsfehlern, Seitennavigation, Suchendpunkte, die Namen in IDs übersetzen, und Komfort-APIs, die Fehlermeldungen vorschlagen. Nimm diese Aufrufe auf, weil sie Ressourcenkennungen offenlegen oder einen umfassenderen Weg als die geplante Aktion eröffnen können.

Halte für jede Anfragefamilie Folgendes fest:

Die Übersicht sollte die Ressourcengrenze in klarer Sprache benennen. «Kann die Deployments-API aufrufen» ist zu vage. «Kann Deployments nur im Sandbox-Projekt erstellen» lässt sich testen. Wenn der Anbieter nicht genügend Einzelheiten offenlegt, um diese Grenze zu formulieren, nutze für den Agent eine separate Testidentität, bis du sie festlegen kannst.

Erstelle danach einen Vergleich mit zwei Spalten. Führe denselben Korpus von Anfragen gegen die alte und die neue Version aus. Verwende dazu ein isoliertes Konto mit bewusst getrennten Ressourcen: mindestens ein erlaubtes Projekt, ein verbotenes Projekt, einen inaktiven Datensatz und, sofern der Dienst Mandanten unterstützt, ein Konto aus einem anderen Mandanten. Die Testdaten brauchen eindeutige Namen, damit versehentliche Überschneidungen in den Ergebnissen auffallen.

Vergleiche nicht nur Statuscodes. Eine 200-Antwort kann den entscheidenden Unterschied verbergen: doppelt so viele Datensätze, ein neuer next_page-Link über eine Grenze hinweg, ein zusätzliches Credential-Feld oder eine Objektkennung, mit der der Agent später einen privilegierten Endpunkt aufrufen kann. Vergleiche Antwortstruktur und Kennungen und prüfe neue Felder auf nachgelagerte Befugnisse.

Geänderte Standardwerte schaffen unerwünschte Zugangswege

Ein ausgelassener Parameter ist weiterhin eine Autorisierungsentscheidung, wenn der Server seine Bedeutung festlegt. Geänderte Standardwerte verdienen dieselbe Prüfung wie ein neuer Schreibendpunkt.

Der bekannte Fehler beginnt mit einer harmlos wirkenden Listenanfrage. Version eins verlangt project_id und gibt nur aktive Datensätze zurück. Version zwei erlaubt die Anfrage ohne project_id und definiert das Weglassen als «alle für dieses Token sichtbaren Projekte». Der Quellcode des Agents hat sich nicht geändert, wenn er dieses optionale Feld bereits weggelassen hatte. Seine erreichbaren Daten haben sich dennoch erweitert.

Andere Standardwerte führen zum gleichen Ergebnis:

• Ein Listenendpunkt nimmt plötzlich archivierte, gelöschte oder geerbte Objekte auf.
• Die Seitennavigation wechselt von einer kleinen festen Ergebnismenge zu einer Cursor-Navigation mit einer next-URL.
• Ein Erstellungsendpunkt wählt den Standardarbeitsbereich des Aufrufers, statt eine fehlende Workspace-ID abzulehnen.
• Ein Aktualisierungsendpunkt behandelt ausgelassene Felder als «aktuellen Wert beibehalten», statt eine explizite Versionsnummer zur Konfliktprüfung zu verlangen.
• Ein Suchendpunkt beginnt, Inhalte verbundener Dienste zu indexieren.

Anbieter nennen solche Änderungen Verbesserungen, weil sie den Aufwand auf Client-Seite verringern. Für einen Agent bedeutet weniger Aufwand oft weniger Reibung, bevor eine Aktion ein größeres Ziel erreicht.

Prüfe Standardwerte mit bewusst unvollständigen Anfragen. Sende für jeden optionalen Parameter eine Anfrage ohne diesen Parameter, eine Anfrage mit leerem Wert, sofern die API das erlaubt, und eine Anfrage mit einem ausdrücklich sicheren Wert. Vergleiche die Zielmenge und den Serverfehler. Ein Agent, der Anfragen erzeugt, wird ausgelassene Felder ganz natürlich verwenden, besonders wenn er ein Dokumentationsbeispiel sieht, in dem sie fehlen.

Verlasse dich nicht auf Prompt-Text wie «Verwende nur Projekt A». Prompt-Anweisungen beeinflussen die Auswahl der Anfrage, aber die API entscheidet, ob eine Anfrage Projekt B berühren kann. Verankere die Projektgrenze im Credential, im Endpunktdesign oder in einem Gateway, das die Anfrage prüft, bevor sie den Rechner verlässt.

Neue Endpunkte machen weitreichende Credentials noch weiter

Ein neuer Endpunkt erweitert die Befugnisse eines bestehenden Credentials, wenn dieses Credential sich dort authentifizieren kann. Der Agent muss den Endpunkt vor dem Upgrade nicht aufgerufen haben, damit das Risiko entsteht.

Teams nehmen neue Endpunkte häufig aus der Prüfung, weil sie sie als «neue Funktionalität» bezeichnen. Das funktioniert nur, wenn ein menschlicher Benutzer ein neues UI-Steuerelement erhält und ein Administrator den Zugriff separat gewährt. Es scheitert, wenn ein Bearer-Token mit weitreichendem Scope automatisch an der neuen Route funktioniert.

Angenommen, ein Agent hat ein Token mit der Bezeichnung projects:write. In Version eins kann dieses Token Projektmetadaten erstellen und bearbeiten. Version zwei fügt POST /projects/{id}/exports hinzu, das einen herunterladbaren Export erstellt und denselben Scope verwendet. Der Scope-String hat sich nicht geändert, aber die Wirkung seines Besitzes schon. Der Agent kann den Endpunkt über ein API-Schema, einen generierten Client, einen Fehlerhinweis oder die normale Dokumentation entdecken.

Ordne neue Endpunkte nach ihrer Wirkung ein, nicht nach dem HTTP-Verb. GET-Endpunkte können Quellcode, Geheimnisse, Audit-Historien, personenbezogene Daten oder signierte Download-URLs offenlegen. POST-Endpunkte können nicht rückgängig zu machende Kosten verursachen oder externe Abläufe auslösen. Eine DELETE-Route kann weniger gefährlich sein als eine GET-Route, die ein anderweitig nutzbares Credential offenlegt.

Prüfe jede neue Route anhand von vier Fragen:

1. Kann sich ein bestehendes Agent-Credential erfolgreich authentifizieren?
2. Welche vorhandenen Scopes, Rollen oder API-Schlüsselklassen erlauben den Zugriff?
3. Kann die Ausgabe Kennungen, URLs oder Tokens für eine weitere Operation liefern?
4. Kann der Agent den Endpunkt über die Clientbibliothek, ein Discovery-Dokument oder bereitgestellte Dokumentation erreichen?

Die letzte Frage deckt eine häufige schlechte Empfehlung auf: «Wir werden dem Agent den neuen Endpunkt nicht nennen.» Das wirkt praktisch, weil Agents meistens ihrem Arbeitskontext folgen. Es ist aber keine Kontrolle. Agents können Schemas untersuchen, übliche Pfade ableiten oder durch eine spätere Aufgabe angewiesen werden. Ein Server muss eine nicht freigegebene Operation ablehnen, selbst wenn der Client ihre genaue URL kennt.

Wenn der Anbieter die neue Route nicht von einem alten, weitreichenden Scope trennen kann, erstelle vor dem Upgrade eine engere Integrationsidentität. Ein Token für einen einzigen, begrenzten Ablauf sollte nicht jede zukünftige Bedeutung erben, die ein Anbieter einem freundlich benannten Scope gibt.

Änderungen an der Authentifizierung sind Berechtigungsänderungen

Das Authentifizierungsverhalten gehört in die Upgrade-Prüfung, weil eine andere Akzeptanz eines Credentials verändert, wer handeln kann. Teams testen häufig die erfolgreiche Anmeldung und überspringen die Ablehnungsfälle, in denen ein Upgrade seinen Schaden anrichtet.

OAuth 2.0 definiert Zugriffstokens als Credentials, die eine Autorisierungsgewährung darstellen. RFC 9700, die OAuth 2.0 Security Best Current Practice, fordert einen exakten Abgleich der Redirect-URI und beschreibt Schutzmaßnahmen gegen Token-Wiederverwendung sowie sendergebundene Tokens. Die praktische Lehre geht über OAuth hinaus: Das Format eines Tokens bestimmt nicht allein seinen vorgesehenen Empfänger, Absender oder Scope. Der Ressourcenserver muss diese Eigenschaften bei jeder akzeptierten Anfrage durchsetzen.

Versionsänderungen berühren diese Durchsetzung oft indirekt. Ein Anbieter kann einen neuen Aussteller einführen, für eine verwandte API bestimmte Tokens akzeptieren, eine Token-Exchange-Route hinzufügen, die Rotation von Refresh-Tokens ändern oder einen alten API-Schlüssel neben einem Token mit Scope zulassen. Kompatibilitätsdruck macht solche Änderungen verlockend. Er schafft aber auch alternative Wege, die Entwickler vergessen zu testen.

Teste Akzeptanz und Ablehnung. Pro Credential-Klasse solltest du die erlaubte Operation, dieselbe Operation gegen eine verbotene Ressource, ein abgelaufenes Credential, ein Token mit falscher Zielgruppe, ein Token ohne erforderlichen Scope und ein widerrufenes Credential ausprobieren. Wenn der Anbieter Refresh-Tokens unterstützt, teste, ob eine Aktualisierung die alte Berechtigung beibehält, ihre Zielgruppe ändert oder stillschweigend Scopes erhält, die während einer späteren Zustimmungsabfrage gewährt wurden.

Ein hilfreicher Prüfdatensatz sieht so aus:

credential: build-agent-sandbox
request: POST /v3/projects/prod-42/deployments
expected: 403 forbidden
old version: 403 {"error":"insufficient_scope"}
new version: 201 {"id":"dep_...","environment":"production"}
review result: block upgrade and revoke credential

Der Antworttext ist wichtig. Wenn aus 403 ein 404 wird, kann das eine beabsichtigte Änderung zum Verbergen von Informationen sein. Wenn aus 403 ein 201 wird, ist das eine Erweiterung der Befugnisse, selbst wenn das Changelog sie als bessere Kompatibilität bezeichnet.

Prüfe auch das Verhalten von Headern. Benutzerdefinierte Header können eine API-Version, eine Organisation oder einen vertretenen Benutzer auswählen. Wenn die neue API einen fehlenden Header als Standardorganisation behandelt, kann ein Wiederholungsversuch des Agents nach einem Formatierungsfehler in der falschen Organisation landen. Erfasse in Tests die exakten Header, entferne Geheimnisse und teste das Weglassen separat.

Agent-Verhalten macht aus kleinen Abweichungen vollständige Abläufe

Ein Agent kann einzelne, gewöhnliche Aufrufe zu einem Ergebnis verketten, das der API-Entwickler nie als eine einzige Berechtigung geprüft hat. Die Versionsprüfung muss solche Ketten berücksichtigen.

Ein neues Listenfeld kann eine Repository-ID offenlegen. Diese ID kann an einen Download-Endpunkt weitergereicht werden. Die Download-Antwort kann eine signierte URL enthalten. Die URL kann ein Artefakt offenlegen, dessen Konfiguration den Endpunkt eines weiteren Dienstes enthält. Jeder Aufruf kann für sich genommen erlaubt wirken. Die gesamte Sequenz kann die Aufgabe des Agents überschreiten.

Deshalb ist eine Autorisierungsprüfung pro Endpunkt notwendig, aber nicht vollständig. Ergänze Workflow-Tests für die Aktionen, die der Agent ausführen soll, und für nahe liegende Aktionen, die ausgeschlossen bleiben sollen. Verfolge den Fluss von Kennungen zwischen Aufrufen: IDs, Cursor, Speicherorte, vorab signierte URLs, Job-IDs und Fehlermeldungen, die gültige Ressourcennamen verraten.

Halte die Tests konkret. Wenn der Agent ein Issue in einem Repository aktualisieren soll, teste, ob er:

• das vorgesehene Issue lesen und seine erlaubten Felder ändern kann;
• scheitert, wenn er die ID eines Issues aus einem anderen Repository verwendet;
• scheitert, wenn er Repository-Einstellungen oder Webhooks ändern will;
• scheitert, wenn er einem Link zu einem Export, einer Mitgliederliste oder einer Tokenverwaltung folgt.

Der Fehlerpfad ist genauso wichtig wie der Erfolgsweg. Ein Agent verarbeitet Fehler als Informationen. Eine ausführliche Ablehnung, die einen alternativen Endpunkt nennt, kann einen unbeabsichtigten Weg leichter auffindbar machen. Für menschliche Entwickler mag dieser Tausch akzeptabel sein. Vor dem Einsatz einer autonomen Anwendung solltest du aber wissen, dass er existiert.

Begrenze Wiederholungen während der Upgrade-Tests. Eine Wiederholungsrichtlinie, die bei einer idempotenten Anfrage harmlos war, kann doppelte Aktionen erzeugen, wenn die neue Version die Idempotenzbehandlung ändert oder nach abgeschlossener Arbeit eine Zeitüberschreitung meldet. Prüfe, ob die API einen Idempotenzschlüssel verwendet, wie lange sie ihn speichert und ob sich durch das Upgrade der Headername oder die Regeln zum Hashen der Anfrage ändern.

Ein Berechtigungsvergleich entdeckt Änderungen, die normale Tests übersehen

Ein Berechtigungsvergleich ist ein wiederholbarer Test. Er fragt, welche Anfragen ein Credential abschließen kann, nicht bloß, ob deine Anwendung weiterhin erwartete Daten erhält. Halte ihn klein genug, um ihn für jeden Versionskandidaten auszuführen.

Erstelle einen Anfragekorpus in einem Repository ohne Produktionsgeheimnisse. Verwende Umgebungsvariablen für Testtokens und richte die Anfragen nur an ein wegwerfbares Konto. Das folgende Shell-Muster erfasst die Teile, die veränderte Befugnisse sichtbar machen, ohne Zugangsdaten auszugeben:

curl -sS -D headers.txt -o body.json \\
  -H "Authorization: Bearer $TEST_TOKEN" \\
  -H "X-API-Version: 2025-01-01" \\
  "https://api.example.test/v1/projects?limit=2"

printf 'status: ' && head -n 1 headers.txt
printf 'headers:\n' && grep -Ei '^(link|location|x-request-id|www-authenticate):' headers.txt
printf 'identifiers:\n' && jq -r '.. | objects | (.id? // empty)' body.json | sort -u

Führe den Korpus einmal pro Version aus und vergleiche Status, ausgewählte Header und normalisierte Kennungen. Vergleiche nicht blind vollständige JSON-Dokumente. Zeitstempel, Anfrage-IDs und Reihenfolgen erzeugen Rauschen, durch das Prüfer lernen, Unterschiede zu ignorieren. Normalisiere diese Felder zuerst, behalte aber Navigationslinks, Ressourcen-IDs, Rollennamen und jedes Feld, das eine spätere Anfrage steuern kann.

Der Korpus sollte erfolgreiche Anfragen, erwartete Ablehnungen, ausgelassene optionale Parameter sowie die erste Seite und einen Folgeaufruf zur Seitennavigation enthalten. Ergänze für jede neu dokumentierte Route, die zu einem bestehenden Agent-Scope zu passen scheint, einen Aufruf. Es geht nicht darum, den gesamten Anbieter aufzuzählen. Es geht darum, jede Operation abzudecken, die der Agent realistisch entdecken oder kombinieren kann.

Eine einfache Ergebnisdatei macht Entscheidungen überprüfbar:

{
  "case": "forbidden-production-deploy",
  "credential": "build-agent-sandbox",
  "request": "POST /v3/projects/prod-42/deployments",
  "expected_status": 403,
  "observed_status": 403,
  "observed_resource_ids": [],
  "version": "2025-01-01"
}

Fordere für jeden Unterschied eine ausdrückliche Entscheidung eines Prüfers. «Das ist erwartbar, weil der Anbieter es geändert hat» ist keine Entscheidung. Der Prüfer muss angeben, ob das neue Verhalten innerhalb der freigegebenen Befugnisse des Agents bleibt und wo diese Befugnisse durchgesetzt werden.

Logs belegen, was passiert ist, nicht was hätte passieren sollen

Anfrageprotokolle helfen bei der Untersuchung eines Upgrades, ersetzen aber keine vorherige Berechtigungsprüfung. Sie beantworten unterschiedliche Fragen.

Vor dem Upgrade zeigt der Berechtigungsvergleich, ob der Anbieter eine unerwünschte Anfrage akzeptieren wird. Nach dem Upgrade zeigen Logs, ob der Agent sie tatsächlich versucht hat, welcher Prozess den Versuch ausgelöst hat und ob du das Konto eindämmen musst. Du brauchst beides, weil eine heute abgelehnte Anfrage nach einer serverseitigen Änderung morgen akzeptiert werden kann.

Protokolliere den Versionsselektor, die normalisierte Operation, die Zielgrenze, die Credential-Bezeichnung, die Entscheidung, den Status und die Korrelations-ID. Protokolliere keine Bearer-Tokens, vollständigen Authorization-Header, vollständigen Anfragekörper oder geheimnishaltige Antwortfelder. Ein Sicherheitslog, das das zu schützende Credential speichert, verschiebt den Angriff nur.

Trenne einen Sitzungseintrag von einem Aktionsdatensatz. Die Sitzung zeigt, welcher Agent-Prozess während eines Laufs die Betriebserlaubnis erhalten hat. Der Aktionsdatensatz zeigt, welche einzelne Anfrage er gestellt hat. Diese Unterscheidung wird wichtig, wenn ein langfristig laufender Agent mit einer geprüften Version startet und später eine Umgebungsänderung oder eine neu erzeugte Clientbibliothek erhält.

Sallyport führt ein Sitzungsjournal und ein Aktivitätsjournal, die aus einem einzigen verschlüsselten, Hash-verknüpften Audit-Log erstellt werden. So kann ein Operator sowohl den Agent-Lauf als auch jede HTTP- oder SSH-Aktion prüfen. Die Offline-Prüfung sp audit verify kann die Kette ohne Zugriff auf den Tresor verifizieren, was nützlich ist, wenn eine Upgrade-Prüfung zu einer Untersuchung eines Vorfalls wird.

Verwechsle Manipulationsnachweise nicht mit Prävention. Ein intaktes Audit-Log kann belegen, dass ein neuer Endpunkt genutzt wurde. Es kann exportierte Daten aber nicht von einem entfernten Dienst zurückholen. Halte sensible Aktionen hinter Credentials und Freigaben, die scheitern, bevor die Anfrage den Rechner verlässt.

Eine Freigabe muss an einen Prozess gebunden sein, nicht an eine vage Aufgabe

Eine menschliche Freigabe kann ein ungeprüftes Upgrade nur stoppen, wenn sie dem Menschen mitteilt, welches ausführbare Programm die Befugnis anfordert. «Agent möchte API-Zugriff» ist zu wenig Information, wenn mehrere lokale Prozesse dasselbe Protokoll verwenden können.

Binde die Sitzungsautorisierung an die Codesignatur des anfragenden Prozesses, sofern das Betriebssystem diese Information bereitstellt. So lässt sich ein häufiger Austauschfehler erkennen: Ein vertrauenswürdiger Agent startet eine Sitzung, danach versucht ein nicht vertrauenswürdiger Helfer oder eine kopierte Binärdatei, denselben Credential-Weg zu verwenden. Eine Prozessidentität beweist nicht, dass jede künftige Anfrage sinnvoll ist. Sie gibt dem Operator aber ein konkretes Objekt, das freigegeben oder widerrufen werden kann.

Verwende eine Freigabe pro Aufruf für Credentials, deren Wirkung sich grundsätzlich schwer begrenzen lässt, etwa Produktionsdeployments, Kontoverwaltung oder Datenexporte. Wenn eine Person jeden harmlosen Lesezugriff bestätigen muss, gewöhnt sie sich daran, Freigabekarten einfach durchzuklicken. Freigabemüdigkeit ist ein Designfehler, kein Fehler des Benutzers.

Sallyport verwendet eine feste Entscheidungskette mit drei Kontrollen: Der gesperrte Tresor verweigert alle Aktionen, ein neuer Agent-Prozess fordert standardmäßig eine Sitzungsautorisierung an, und eine Einstellung pro Schlüssel kann für jede Nutzung eine separate Freigabe verlangen. Dieses enge Modell bildet nicht jede Organisationsregel ab, verhindert aber, dass Berechtigungsänderungen in einer Vielzahl von Richtliniensyntaxen verborgen werden.

Wenn ein API-Upgrade den effektiven Scope eines Credentials ändert, widerrufe die aktuelle Sitzung und erzwinge nach der Prüfung eine neue Freigabe. Lass eine für die Endpunkte von gestern genehmigte Sitzung nicht stillschweigend in eine breitere Oberfläche von morgen übergehen.

Die Berechtigungsprüfung als Release-Gate einsetzen

Ein API-Versionsupgrade sollte das Release-Gate nicht passieren, wenn ein aktuelles Credential eine ungeklärte erfolgreiche Anfrage hinzugewinnt, eine abgelehnte Anfrage erlaubt wird oder eine Antwort eine neue Kennung offenlegt, die einen verbotenen Ablauf ermöglicht.

Führe die Prüfung im selben Änderungsdatensatz wie Dependency-Updates und Änderungen an generierten Clients. Dokumentiere alte und neue API-Selektoren, die Release Notes des Anbieters, die Ausgabe des Berechtigungsvergleichs, die geprüften Credential-Klassen und die Person, die jeden beabsichtigten Unterschied akzeptiert hat. Diese Arbeit ist unspektakulär. Genau deshalb wird sie oft übersprungen, bis der erste merkwürdige Audit-Eintrag auftaucht.

Warte nicht auf eine große API-Version. Starte die Prüfung, wenn der Anbieter eine API-Version, einen Authentifizierungsdienst, OAuth-Anwendungseinstellungen, ein generiertes SDK, ein Discovery-Schema, einen Standardheader oder eine Scope-Definition ändert. Auch eine Änderung außerhalb der URL kann die Entscheidung des entfernten Servers verändern.

Beginne mit dem Credential, dessen Schaden am größten wäre, wenn es eine zusätzliche Route erhielte. Gib ihm ein isoliertes Testkonto, formuliere fünf erlaubte und abgelehnte Anfragen und führe sie gegen die vorgeschlagene Version aus. Wenn du nicht erklären kannst, warum jeder Erfolg zur Aufgabe des Agents gehört, ist die Integration noch nicht für den autonomen Einsatz bereit.