Reversible SaaS-Benutzerbereitstellung für KI-Agenten

Ein KI-Agent sollte einen SaaS-Benutzer nie mit einer undurchsichtigen Anweisung wie „Füge Priya mit dem üblichen Entwicklungszugriff zum Firmenkonto hinzu“ bereitstellen. Dieser Satz verbirgt mindestens drei Zustandsänderungen: eine Identität anlegen oder einladen, eine Rolle auf Kontoebene zuweisen und Gruppenmitgliedschaften hinzufügen. Jede Änderung hat ein anderes Risiko, eine andere Abschlussbedingung und eine eigene Gegenaktion.

Reversible SaaS-Benutzerbereitstellung beginnt damit, diese Grenzen zu erhalten. Der Agent schlägt eine Abfolge vor, führt jeweils einen Aufruf aus, speichert die zurückgegebenen Kennungen und hält an, sobald der beobachtete Zustand von der Erwartung abweicht. Einige zusätzliche API-Aufrufe sind günstig gegenüber dem Aufwand, nach einem Timeout, einer falschen Adresse oder einer zu weit gefassten Gruppe eine halb fertige Zugriffsvergabe zu rekonstruieren.

Einladung, Rolle und Mitgliedschaft sind verschiedene Zustände

Eine offene Einladung ist kein Benutzer, ein Benutzer ist keine Rolle und eine Rolle ist keine Gruppenmitgliedschaft. Bereitstellungssysteme vermischen diese Objekte oft, weil Anbieteroberflächen sie in einem Formular zeigen. Die API darunter stellt häufig getrennte Ressourcen oder Lebenszyklusaktionen bereit. Diese Trennung entscheidet, ob ein Agent einen Fehler sicher auflösen kann.

Eine Einladung beschreibt meist eine Absicht und einen Zustellungs- oder Annahmeprozess. Der Empfänger muss sie eventuell annehmen, kann eine andere Identität nutzen oder nie reagieren. Microsoft Graph dokumentiert das für externe Benutzer ausdrücklich: Das Erstellen liefert ein Einladungsobjekt, die eingeladene Person schließt danach einen interaktiven Vorgang ab. Bei GitHub bleibt die Organisationsmitgliedschaft ebenfalls offen, bis sie angenommen wird. Wenn ein Agent sofort „Benutzer erstellt“ protokolliert, hält er eine Hoffnung fest, keine Tatsache.

Eine Rolle ändert Befugnisse im Konto oder in der Organisation. Sie kann eine Person zum Eigentümer, Abrechnungsverantwortlichen, Administrator, Gast oder normalen Mitglied machen. Eine Gruppenmitgliedschaft gewährt häufig indirekten Zugriff auf Projekte, Repositorys, Kanäle, Anwendungen oder gemeinsame Daten. Das Entfernen der Gruppe kann diesen Zugriff aufheben, ohne die Kontorolle zu ändern. Eine Herabstufung kann gruppenbasierte Rechte bestehen lassen.

Modellieren Sie die Zustände getrennt, selbst wenn ein Anbieter einen bequemen Endpoint für alle drei in einem POST anbietet. Ein sinnvoller interner Datensatz sieht so aus:

{
  "subject": "[email protected]",
  "invitation": {"state": "pending", "id": "inv_8421"},
  "role": {"desired": "member", "observed": null},
  "groups": {
    "desired": ["engineering", "on-call-readers"],
    "observed": []
  }
}

Die Trennung beantwortet die unangenehme Betriebsfrage: Was muss genau rückgängig gemacht werden? Besteht die Einladung, wurde aber nicht angenommen, stornieren Sie sie. Hat das Konto die falsche Rolle, stellen Sie die vorige wieder her. Wurde eine Gruppe hinzugefügt und scheiterte der nächste Aufruf, entfernen Sie nur die in diesem Lauf erzeugte Mitgliedschaft. Den ganzen Benutzer zu löschen ist meist ein fahrlässiger Ersatz für die Kenntnis der tatsächlichen Änderung.

Die erste Entwurfsregel ist einfach: Eine protokollierte Aktion sollte einem aus der Ferne beobachtbaren Zustandswechsel entsprechen. Der Aufruf kann Nebenwirkungen wie eine E-Mail auslösen, aber Agent und Bediener müssen den Hauptwechsel benennen können, ohne „und außerdem…“ anzufügen.

Ein Bereitstellungsplan muss aus Daten bestehen

Der Agent sollte eine menschliche Anfrage in einen typisierten Plan übersetzen, bevor er den Anbieter aufruft. Der Plan macht mehrdeutige Annahmen sichtbar und gibt dem Ausführer stabile Eingaben. Freie Überlegungen gehören vor die Ausführung; an ihrer Grenze sollten unspektakuläre, genaue Daten stehen.

Mindestens erforderlich sind Subjektkennung, Zielmandant, Einladungsart, gewünschte Rolle und Gruppen, Vorbedingungen sowie eine Vorgangskennung. Der Plan muss auch sagen, ob eine E-Mail versendet werden darf. Die Zustellung ist eine äußere Folge, die eine Stornierung nicht zurückholt. Sie hinter einem Standardwert zu verstecken ist schlechte Praxis.

{
  "operation_id": "prov_2026_07_24_0187",
  "tenant": "acme-production",
  "subject": {"email": "[email protected]"},
  "steps": [
    {"kind": "invite", "send_email": false},
    {"kind": "wait_for_acceptance"},
    {"kind": "set_role", "role": "member"},
    {"kind": "add_group", "group": "engineering"},
    {"kind": "add_group", "group": "on-call-readers"}
  ],
  "preconditions": {
    "account_absent": true,
    "allowed_email_domain": "example.test"
  }
}

Behalten Sie jede Gruppenzuweisung als eigenen Schritt, statt eine Liste an einen breiten Endpoint zu senden. So kann der Ausführer jede Mitgliedschaft einzeln genehmigen, wiederholen und kompensieren. Der Plan zeigt auch die Reihenfolge. Kann die Rolle erst nach Annahme vergeben werden, ist wait_for_acceptance eine echte Zustandsschranke und kein Schlafbefehl.

Prüfen Sie den Plan anhand lokaler Grenzen, bevor ein Geheimnis offengelegt oder ein Netzaufruf ausgeführt wird. Der Mandant muss eine genaue bekannte Kennung sein. Normalisieren Sie die Domäne, ohne den lokalen Teil der Adresse zu verändern, lösen Sie lesbare Gruppennamen in unveränderliche Anbieter-IDs auf und lehnen Sie Eigentümer- oder Administratorrollen ohne ausdrückliche Anforderung ab. Der Agent sollte nicht mit einem mächtigen Token alle Konten nach einem passenden Mandanten durchsuchen.

Vorab-Lesevorgänge müssen den vorhandenen Zustand erfassen. Suchen Sie das Subjekt über das dokumentierte eindeutige Merkmal und lesen Sie direkte Rollen- und Mitgliedschaftsdatensätze. Unterscheiden Sie „nicht gefunden“ und „Lesen fehlgeschlagen“. Ein 403, Timeout oder eine abgeschnittene Seite beweist keine Abwesenheit. Bei später Konsistenz oder Seitennavigation muss vor dem Erstellen eine stärkere Abfrage folgen.

Nach der Genehmigung wird der Plan eingefroren. Ändert der Agent Adresse, Rolle, Gruppen-ID oder Zustellungsoption, erzeugt er eine neue Vorgangskennung und holt eine neue Entscheidung ein. Sonst können genehmigter Text und ausgeführte Aufrufe unbemerkt auseinanderlaufen.

Bereiten Sie die Einladung vor der Zugriffsvergabe vor

Erstellen oder senden Sie zuerst die Einladung und warten Sie, bis der Dienst den Ausgang belegt. Bündeln Sie privilegierte Rollen und sensible Gruppen nicht nur deshalb mit der Einladung, weil der Endpoint es erlaubt. Das beliebte Argument ist Effizienz: Eine Anfrage wirkt atomar und versendet eine Benachrichtigung. Die meisten SaaS-APIs versprechen jedoch keine Transaktion über Identität, Rolle, Nachricht und Gruppenweitergabe.

Der Endpoint für GitHub-Organisationseinladungen zeigt die Versuchung. Die Anfrage kann eine Rolle und Team-IDs enthalten. In der Oberfläche ist das bequem, doch ein autonomer Ausführer verliert Prüfpunkte, wenn er alles gemeinsam sendet. Ein Validierungsfehler kann alles ablehnen; eine verlorene Antwort nach der Verarbeitung lässt offen, welche Effekte eintraten. Eine Person kann auch lange nach Ende des Agentenlaufs annehmen und erst dann Zugriff aktivieren.

Wählen Sie die am wenigsten mächtige Einladung, die der Anbieter zulässt. Muss sie eine Rolle enthalten, verwenden Sie die normale Mitgliedsrolle und verschieben Sie die Erhöhung. Muss sie eine Gruppe oder einen Kanal enthalten, wählen Sie einen Ankunftsbereich ohne sensible Ressourcen und ergänzen Sie die vorgesehenen Mitgliedschaften erst nach Erreichen des erwarteten Zustands. Die dokumentierte Enterprise-Grid-Einladung von Slack verlangt zum Beispiel mindestens eine Kanal-ID. Das spricht für einen schwach berechtigten Ankunftskanal, nicht für alle Arbeitskanäle im ersten Aufruf.

Protokollieren Sie den Mailversand und erfassen Sie Einladungs-ID, Zustand, Erstellungszeit und das kanonische Subjekt aus der Antwort. Eine Annahme-URL gehört nicht in ein breit verfügbares Journal, weil sie wie eine Inhaberberechtigung wirken kann. Wird sie zur getrennten Zustellung geliefert, soll der kleinste vertrauenswürdige Baustein sie verarbeiten und aus agentensichtbaren Ergebnissen entfernen.

Eine vorbereitete Einladung braucht einen ausdrücklichen Endzustand. Nutzen Sie accepted, expired, cancelled und pending, wenn der Anbieter sie anbietet. Sonst leiten Sie den Zustand aus dokumentierten Feldern ab und kennzeichnen ihn als abgeleitet. „Der POST lieferte 201“ bedeutet nie „Der Empfänger kann auf Produktionsdaten zugreifen“.

Setzen Sie im lokalen Datensatz eine Frist. Lesen Sie nach ihrem Ablauf den Zustand und stornieren Sie eine noch offene Einladung, wenn die geschäftliche Anforderung nicht mehr gilt. Stornieren Sie nicht blind: Die Person könnte kurz zuvor angenommen haben. Erst lesen, dann vergleichen und handeln.

Eine Stornierung ist nur in engem Sinn reversibel. Sie kann eine spätere Annahme verhindern, aber keine E-Mail zurückrufen und kein Wissen über die Organisation beseitigen. Diese Grenze gehört auf die Genehmigungskarte. „Reversibel“ soll den fernen Berechtigungszustand beschreiben und nicht vorgeben, jede Folge lasse sich löschen.

Rollen folgen erst auf eine stabile Identität

Warten Sie, bis die Anfrage an eine stabile entfernte Benutzer-ID gebunden werden kann. E-Mail-Adressen helfen bei der Suche, sind aber schlechte dauerhafte Schlüssel: Adressen ändern sich, Aliasse kollidieren und Einladungen werden manchmal über ein bestehendes Konto angenommen. Die Anbieter-ID muss Ziel der folgenden Aufrufe werden.

Lesen Sie vor der Rollenänderung den aktuellen Wert und speichern Sie ihn als Kompensationswert. Entspricht er bereits dem Ziel, protokollieren Sie einen Leerlauf statt einer erneuten Schreiboperation. Das ist nützlicher Beleg: Der Ausführer hat geprüft und beansprucht keine Änderung, die bereits jemand anders vorgenommen hat.

Behandeln Sie eine Erhöhung anders als eine normale Mitgliedsrolle. Der Agent kann eine Standardrolle unter Sitzungsfreigabe zuweisen, während Eigentümer-, Administrator- oder Abrechnungsrechte eine Freigabe pro Aufruf verlangen. Die Kontrollgrenze folgt der Folge des Schlüsselgebrauchs, nicht der HTTP-Methode. PATCH /users/123 kann je nach Feld gewöhnlich oder verheerend sein.

Verwenden Sie Vergleichsbedingungen, wenn die API sie anbietet. Ein ETag mit If-Match, ein Versionsfeld oder eine Anbieterversion verhindert, dass eine menschliche Änderung nach der Vorablesung überschrieben wird. Lesen Sie bei einem Konflikt erneut und halten Sie zur Prüfung an. Erzwingen Sie nicht sofort den alten Plan; die konkurrierende Änderung kann genau die relevante Information sein.

Der Journaleintrag enthält alten, angeforderten und beobachteten Wert, entfernte Subjekt-ID, Antwortstatus und Konkurrenz-Token, aber nie das verwendete Bearer-Token. Ein minimaler Erfolg sieht so aus:

{
  "operation_id": "prov_2026_07_24_0187",
  "step": 3,
  "action": "role.set",
  "subject_id": "usr_1938",
  "before": "guest",
  "requested": "member",
  "observed": "member",
  "http_status": 200,
  "undo": {"action": "role.set", "value": "guest"}
}

Ein erfolgreicher Aktualisierungsaufruf schließt die Rollenänderung nicht ab. Lesen Sie die Ressource erneut und bestätigen Sie den wirksamen Wert. APIs können 202 Accepted liefern, Änderungen asynchron anwenden oder offene und aktive Einträge trennen. Das Journal bleibt bei requested, bis eine Lesung observed belegt.

Soll die Herabstufung kompensieren, klären Sie, ob sie selbst eine Freigabe braucht. guest nach versehentlicher Eigentümerschaft wiederherzustellen ist oft sicherer als zu warten, doch eine automatische Rücknahme kann einer menschlichen Korrektur widersprechen. Erlauben Sie sie nur, solange die gespeicherte Version der durch diesen Vorgang erzeugten entspricht. Sonst anhalten und die Abweichung zeigen.

Jede Gruppe erhält einen eigenen Aufruf

Jede Gruppenmitgliedschaft braucht einen eigenen Schritt, eine Ziel-ID, ein Ergebnis und eine Gegenanweisung. In Gruppen verstecken sich oft weitreichende Zugriffe. Ein Name wie engineering kann Repositorys, Bereitstellungskonsolen, Störungskanäle und synchronisierte Anwendungen steuern. Der Agent darf diese Reichweite nicht aus einem freundlichen Namen ableiten.

Lösen Sie Gruppen über einen außerhalb des Prompts gepflegten Freigabekatalog auf. Er ordnet Anzeigenamen unveränderlichen IDs des Mandanten zu und beschreibt direkte, verschachtelte, dynamische oder synchronisierte Mitgliedschaft. Gleiche Namen müssen zum Abbruch führen. Bei regelgesteuerten Gruppen darf der Agent die Regel nicht mit wiederholten direkten Schreibvorgängen bekämpfen.

Die Directory API des Google Admin SDK macht die Ressourcengrenze deutlich. Sie bietet getrennte Endpoints zum Hinzufügen, Ändern und Entfernen per DELETE. Die Dokumentation warnt außerdem, dass verschachtelte Mitgliedschaft verzögert sichtbar sein kann, und lehnt Zyklen ab. Daher muss beobachteter Zustand geprüft werden, statt sofortige Konsistenz anzunehmen.

SCIM bietet ein weiteres hilfreiches Verhalten. Im PATCH-Beispiel von RFC 7644 soll das Hinzufügen eines bereits vorhandenen Mitglieds nichts ändern und trotzdem erfolgreich sein. Das hilft bei Wiederholungen, aber nicht jede SCIM-Implementierung folgt dem Beispiel vollkommen. Testen Sie den Anbieter und behalten Sie eine Abfrage zur Abstimmung.

Ein Gruppenschritt unterscheidet added, already_present, rejected und unknown. Bei already_present darf keine Gegenaktion entstehen, weil eine Rücknahme sonst früheren Zugriff löscht. Unknown bedeutet, dass der Schreibvorgang gelungen sein könnte, aber Antwort oder Prüfung fehlen. Das verlangt Abstimmung, keine optimistische Wiederholung.

Verarbeiten Sie Gruppen mit steigender Berechtigung. Fügen Sie die normale Zusammenarbeit vor der Produktionsadministration hinzu. Ein Fehler wird dadurch nicht folgenlos, lässt beim Abbruch aber weniger Zugriff bestehen. An jeder als sensibel markierten Grenze ist eine neue Freigabe nötig, auch wenn frühere Gruppen erfolgreich waren.

Parallelisieren Sie Mitgliedschaften nicht nur für geringere Latenz. Parallele Aufrufe verwischen Belege, erschweren Ratenbegrenzungen und können nachgelagerte Systeme in unbekannter Reihenfolge auslösen. Einige sequenzielle Aufrufe sind billiger als die Untersuchung einer Lizenz, die vor der Zustimmung zu beschränkten Daten vergeben wurde.

Lesen Sie nach jedem Hinzufügen die direkte Mitgliedschaft und keine abgeflachte Ansicht wirksamer Rechte. Wirksame Mitgliedschaft kann aus einer übergeordneten Gruppe stammen und nach Entfernung der direkten Kante bestehen bleiben. Der Rücknahmebeleg muss die von diesem Vorgang erzeugte Kante nennen.

Sichere Wiederholungen beginnen mit beobachtetem Zustand

Eine Wiederholungsrichtlinie macht einen beliebigen POST nicht sicher. RFC 9110 definiert PUT, DELETE und sichere Methoden anhand ihrer beabsichtigten Wirkung als idempotent. Nicht idempotente Anfragen sollen nur automatisch wiederholt werden, wenn ihre Semantik tatsächlich idempotent ist oder feststeht, dass die ursprüngliche Anfrage nie angewandt wurde.

Gefährlich ist ein Timeout nach dem Senden einer Einladung. Der Server könnte Einladung und E-Mail vor dem Verbindungsfehler erzeugt haben. Ein weiterer POST kann beides duplizieren. Lesen Sie zuerst anhand von Subjekt und Mandant. Übernehmen Sie danach das passende entfernte Objekt, wiederholen Sie nur bei bewiesener Abwesenheit oder halten Sie bei Mehrdeutigkeit an.

Nutzen Sie einen Idempotenzschlüssel, wenn die API ihn dokumentiert. Leiten Sie ihn aus unveränderlicher Vorgangskennung und Schrittnummer ab, speichern Sie ihn und verwenden Sie ihn für denselben logischen Versuch erneut. Ein neuer Schlüssel nach Timeout bezeichnet für den Server eine neue Aktion.

Ohne solchen Schlüssel braucht jeder Schreibvorgang eine Abstimmungsfunktion, bevor ein Agent ihn erhält. Sie muss das Objekt ohne unscharfe Suche finden. Adresse und Mandant identifizieren eine Einladung, Benutzer- und Gruppen-ID eine Kante. Bietet die API keine genaue Abfrage, verlangt ein unsicheres Ergebnis menschliche Bestätigung.

Wiederholungen brauchen ein Budget. Beachten Sie Retry-After, nutzen Sie begrenzte zunehmende Wartezeiten für vorübergehende Serverfehler und stoppen Sie bei Validierungs-, Berechtigungs- oder Konfliktfehlern. Ein 403 ist kein langsamer 200. Wiederholt dieselbe abgelehnte Karte vorzulegen, gewöhnt Bediener außerdem an ungelesene Freigaben.

Ein verlässlicher Ausführer verwendet diese Tabelle:

Trennen Sie Transportversuche von logischen Schritten. Fünf HTTP-Versuche können eine einzige Gruppenaufnahme darstellen. Das Hauptjournal zeigt das logische Ergebnis, verknüpfte Versuche behalten Status und Zeit. Sonst kann eine Prüfung Wiederholungen für mehrfache Vergaben halten.

Rücknahme bedeutet Kompensation

SaaS-Bereitstellung bietet selten eine verteilte Transaktion. Rücknahme heißt daher, Gegenaktionen rückwärts auszuführen: in diesem Lauf erzeugte Mitgliedschaften entfernen, vorige Rolle wiederherstellen und die noch offene Einladung stornieren. Jede Gegenaktion ist ein echter API-Aufruf, der scheitern, eine Freigabe brauchen oder auf konkurrierende Änderungen treffen kann.

Bauen Sie den Kompensationsstapel aus bestätigten Änderungen, nicht aus geplanten Schritten. Eine bereits vorhandene Gruppe wird nicht entfernt. Eine Rolle, die den Server nie erreichte, wird nicht wiederhergestellt. Bei unbekannter Prüfung wird erst abgestimmt, nicht geraten.

Ein sinnvoller Beleg enthält genug Daten, um die Gegenaktion auszuführen und zu begrenzen:

{
  "action": "group.add",
  "target": {"user_id": "usr_1938", "group_id": "grp_77"},
  "result": "added",
  "remote_version_after": "W/\"9012\"",
  "compensation": {
    "action": "group.remove",
    "only_if_direct_membership_matches": true
  }
}

Die Versionsgrenze ist wichtig. Fügt der Agent Priya hinzu und bestätigt ein Vorgesetzter diese Mitgliedschaft danach unabhängig in der Konsole, könnte eine blinde Rücknahme eine inzwischen eigenständig verantwortete Entscheidung löschen. Lässt sich die Bedingung nicht im DELETE ausdrücken, lesen Sie Kante und Metadaten, zeigen den Konflikt und fragen einen Menschen.

Nicht jede Nebenwirkung hat eine Gegenaktion. E-Mails lassen sich nicht zurückholen, Auditereignisse sollten nicht gelöscht werden, Lizenzen können Abrechnung auslösen und nachgelagerte Identitätsdienste eine Gruppenänderung verspätet weitergeben. Kennzeichnen Sie solche Reste, statt eine uneingeschränkt vollständige Rücknahme zu behaupten.

Auch die Rücknahme braucht Frist und Eskalationsweg. Schlüssel laufen ab, Dienste fallen aus und der ursprüngliche Prozess endet. Speichern Sie Belege außerhalb des Agentenkontexts, damit ein anderer vertrauenswürdiger Ausführer fortfahren kann. Der Bediener muss rollback_pending sehen, nicht eine freundliche Fehlermeldung im Transkript.

Testen Sie Gegenaktionen in einem Nichtproduktionsmandanten: Einladung erstellen, stornieren und den Link prüfen; direkte Kante hinzufügen, entfernen und wirksamen Zugriff kontrollieren; schwache Rolle ändern und unter einem Konkurrenzkonflikt wiederherstellen. Die Dokumentation beschreibt Absicht, solche Proben zeigen das wirkliche Verhalten.

Das Journal muss Ursache und Wirkung belegen

Ein gutes Journal beantwortet, wer die Änderung verlangte, welcher Prozess sie ausführte, welche Schlüsselgrenze sie erlaubte, welches entfernte Objekt sich änderte und wie der Ausführer das Ergebnis prüfte. Ein Werkzeugtranskript reicht nicht. Agentenerzählungen können falsch und HTTP-Inhalte zu sensibel oder groß sein.

Vergeben Sie stabile Kennungen für Vorgänge und Schritte. Speichern Sie Plan-Hash, genauen Mandanten, normalisiertes Subjekt, entfernte IDs, Entscheidung, Anfragefingerabdruck, Antwortstatus, Prüflesung und Kompensation. Geschwärzte Antwortauszüge sind nur sinnvoll, wenn sie das Ergebnis erklären. Ein Hash erlaubt spätere Vergleiche ohne Kopie personenbezogener Daten.

Trennen Sie Behauptungen und Beobachtungen. requested_role: member beschreibt Absicht, response_status: 200 den Transport und observed_role: member einen geprüften fernen Zustand. Ein boolesches success für alle drei vernichtet den Beleg, der bei einem Vorfall gebraucht wird.

Die Befehlszeilenansicht muss einen Teilerfolg klar zeigen:

$ provision status prov_2026_07_24_0187
STEP  ACTION                 RESULT            UNDO
1     invitation.create      accepted          unavailable
2     acceptance.wait        observed          n/a
3     role.set               changed           ready: guest
4     group.add engineering  added             ready
5     group.add on-call      denied            none
STATE partial_failure

Die Ausgabe zeigt: Konto vorhanden, Rolle geändert, eine Gruppe hinzugefügt, letzte Gruppe verweigert. Sie macht daraus nicht bloß „Bereitstellung fehlgeschlagen“. Diese Unterscheidung leitet sowohl die Kompensation als auch eine Fortsetzung nach korrigierter Berechtigung.

Schützen Sie das Journal vor dem handelnden Agenten. Kann er seine Belege umschreiben, sind sie wenig wert. Sallyport stellt Sitzungen und einzelne Aufrufe als zwei Ansichten eines verschlüsselten, hashverketteten Logs dar; sp audit verify prüft diese Kette offline über dem Chiffretext ohne Schlüssel. Anbieterprotokolle ersetzt das nicht, gibt dem lokalen Bediener aber eine unabhängige Aufruffolge.

Verknüpfen Sie lokale Schritt-IDs mit Anfrage-IDs des Anbieters. Im Supportfall findet die Anbieter-ID Servertraces, während der lokale Datensatz Absicht und Freigabe erklärt. Bewahren Sie Zeitstempel auf, ordnen Sie aber nach einer monotonen lokalen Folge, weil Uhren und asynchrone Ereignisse abweichen können.

Für die Aufbewahrung ist eine bewusste Richtlinie nötig. Belege können Adressen, Gruppennamen und Rollenverlauf enthalten. Speichern Sie nur notwendige Felder, verschlüsseln Sie sie, begrenzen Sie Leser und lassen Sie Hilfsantworten früher ablaufen als den Kerndatensatz, wenn die Richtlinie das erlaubt.

Genehmigung gehört an die Wirkungsgrenze

Menschliche Genehmigung funktioniert, wenn eine Karte eine konkrete Folge beschreibt. „Bereitstellung erlauben“ ist zu breit. „[email protected] ohne E-Mail zu acme-production einladen“ ist prüfbar. „usr_1938 von guest zu member ändern“ und „usr_1938 zu production-deployers hinzufügen“ verdienen bei unterschiedlichem Risiko getrennte Entscheidungen.

Zeigen Sie aufgelöste Kennungen und aktuellen Zustand, nicht nur Agentenworte. Die Karte enthält Mandant, kanonisches Subjekt, Aktion, Vorher- und Nachherwert sowie mögliche Gegenaktion. Bei einer Einladung nennt sie den Mailversand, bei einer Gruppe die unveränderliche ID neben dem Namen.

Eine Sitzungsfreigabe kann wiederholte schwache Aufrufe abdecken, während sensible Schlüssel oder Aktionen Zustimmung bei jeder Verwendung verlangen. Die feste Entscheidungsleiter von Sallyport trennt das: Der Tresor muss offen sein, ein neuer Agentenprozess bekommt standardmäßig eine Sitzungsfreigabe, und ein Kennzeichen pro Schlüssel kann jeden Aufruf genehmigungspflichtig machen. Platzieren Sie privilegierte Bereitstellungsschlüssel an der strengen Grenze, statt das Modell um Selbstkontrolle zu bitten.

Eine Genehmigung entschuldigt keine schwache Ausführungssemantik. Ein Mensch kann die richtige Gruppe erlauben und nach Timeout dennoch einen doppelten POST erleben. Der Ausführer bleibt für Idempotenz, Prüfung und Kompensation zuständig. Ebenso macht ein perfektes Journal einen übermächtigen Schlüssel nicht sicher.

Vermeiden Sie Ermüdung, indem Sie Karten ohne echte Entscheidung entfernen. Begrenzte Lesevorgänge können in die Sitzungsfreigabe passen. Exakte Leerlaufschritte werden protokolliert, ohne eine nicht stattfindende Änderung „genehmigen“ zu lassen. Gruppieren Sie gleiche schwache Mitgliedschaften nur, wenn die Oberfläche jedes Ziel zeigt und die Rücknahme getrennte Belege behält.

Ein Widerruf muss künftige Schritte stoppen, ohne fertige Schritte als rückgängig auszugeben. Widerruft der Bediener nach Schritt vier, storniert der Ausführer wartende Aufrufe, markiert den Vorgang als unterbrochen und bietet den Kompensationsplan an. Er wechselt nicht heimlich den Schlüssel und startet keine neue Sitzung.

Ein fehlgeschlagener Lauf muss verständlich bleiben

Ein Agent soll eine Auftragnehmerin mit normalem Konto und zwei Gruppen aufnehmen. Die Vorablesung findet kein Konto. Der Einladungsaufruf läuft nach Übertragung in ein Timeout; die Abstimmung findet eine offene Einladung und übernimmt ihre ID. Die Person nimmt an, die Rolle wird geändert, die erste Gruppe hinzugefügt, und die zweite liefert 403, weil dem Token die Befugnis fehlt.

Das ist ein Teilergebnis, kein undifferenzierter Fehler. Nun bestehen ein aktives Konto und eine direkte Gruppenmitgliedschaft. Der Agent muss anhalten, den verweigerten Schritt zeigen und zwei gültige Optionen anbieten: den bestätigten Zustand behalten, bis die restliche Befugnis vorliegt, oder die erste Mitgliedschaft kompensieren und die Rolle vor weiterer Kontobearbeitung wiederherstellen.

Er darf den Benutzer nicht löschen. Das könnte Daten entfernen, eine angenommene Identität ungültig machen oder mit nachgelagerter Bereitstellung kollidieren. Er darf den 403 nicht wiederholen, die zugestellte E-Mail nicht als rücknehmbar bezeichnen und die verweigerte Gruppe nicht durch eine breitere ersetzen.

Das Journal ermöglicht eine sichere Fortsetzung. Ein neuer Ausführer lädt unveränderlichen Plan und Belege, liest den fernen Zustand und prüft Konto, Rolle und erste Gruppe. Stimmen sie überein, holt er nur für die restliche Mitgliedschaft eine Freigabe ein. Hat ein Vorgesetzter die Rolle geändert, ist der Plan veraltet und braucht eine neue Entscheidung.

Das Muster gilt auch für Austritte. Sitzungswiderruf, Gruppenentfernung, Rollenänderung, Sperrung und Löschung haben unterschiedliche Dringlichkeit und Umkehrbarkeit und bleiben getrennt. Lizenzzuweisung bleibt ebenfalls getrennt, wenn der Anbieter sie separat anbietet. Die Regel bleibt: bedeutende Zustandsgrenzen des fernen Systems müssen im Agentenplan und in den Belegen erhalten bleiben.

Die zusätzlichen Aufrufe sind beabsichtigte Reibung. Sie schaffen Stellen, an denen Identität geprüft, Befugnis begrenzt, bei Abweichung angehalten und nur die eigene Änderung zurückgenommen wird. Ein autonomer Agent verdient mehr Freiheit, wenn seine Arbeit an diesen Grenzen prüfbar ist. Erzwingt eine API mehrere Folgen in einem unumkehrbaren Aufruf, muss er ehrlich so eingestuft und einem Menschen vorgelegt werden.