So funktioniert die Zuordnung gemeinsamer API-Konten über Agentensitzungen hinweg

Ein gemeinsames API-Konto kann manchmal die richtige Lösung sein. Anbieter stellen möglicherweise ein Organisationstoken aus, Ratenlimits können an dieses Konto gebunden sein, und der Ersatz durch eine Sammlung fast identischer Schlüssel schafft womöglich nur mehr Geheimnisse, ohne die Kontrolle zu verbessern.

Der Fehler liegt darin, dieses Konto als Akteur zu behandeln. Es ist ein externer Credential-Principal, also die Identität, die der Anbieter erkennt. Wenn mehrere lokale Agenten es verwenden, brauchst du einen zweiten Datensatz. Er muss festhalten, welcher lokale Prozess jede Anfrage ausgelöst hat, wozu er autorisiert war und wie er die Berechtigung zur Nutzung der Zugangsdaten erhalten hat. Wenn du diese Informationen nicht bereits bei der Ausführung sammelst, kannst du später nur noch raten.

Das ist weniger spektakulär, als jedem Agenten einen Namen und ein farbenfrohes Dashboard zu geben. Es hält aber auch dann stand, wenn zwei Agenten gleichzeitig arbeiten, einer einen Wiederholungsversuch startet, ein Mensch einen Lauf halbwegs abbricht und die Audit-Seite des Anbieters nur automation-service anzeigt.

Ein Anbieter-Konto und ein Akteur sind unterschiedliche Identitäten

Ein gemeinsames Anbieter-Konto beantwortet die Frage: „Welche Zugangsdaten hat der Anbieter akzeptiert?“ Die Zuordnung zum Akteur beantwortet dagegen: „Welcher lokale Principal hat diese konkrete Operation ausgelöst?“ Die Antworten unterscheiden sich häufig. Werden sie in ein einziges Feld gezwängt, entstehen schlechte Audit-Spuren.

Halte mindestens vier Identitäten getrennt:

• Externes Konto: der Anbieter-Mandant, der Dienstbenutzer, der OAuth-Client oder die API-Schlüsselidentität, die für die entfernte API sichtbar ist.
• Ausführungssitzung: ein gestarteter Agentenprozess mit einer neuen, nicht erratbaren Sitzungs-ID.
• Initiierender Principal: die Person, der CI-Job oder der übergeordnete Dienst, der diese Sitzung gestartet hat.
• Arbeitsreferenz: das Issue, der Änderungsantrag, das Deployment, das Repository oder die konkrete Aufgabe, die erklärt, warum der Aufruf erfolgte.

Das externe Konto kann monatelang stabil bleiben. Die Ausführungssitzung sollte das nicht. Eine Aufgabenreferenz kann in mehreren Sitzungen vorkommen. Der Initiator kann eines Tages eine Person an der Tastatur und am nächsten Tag ein automatisierter Build sein. Jedes Feld hat eine eigene Lebensdauer und beantwortet eine andere Frage.

Diese Unterscheidung ist keine reine Begriffssache. Angenommen, vendor-prod löscht ein entferntes Deployment. Der Anbieter kann wahrheitsgemäß sagen, dass vendor-prod die Löschung ausgeführt hat. Dein lokaler Datensatz muss zeigen, ob die Sitzung s_7f3... von einem Release-Agenten stammte, den Maya gestartet hat, ob sie für diesen Lauf genehmigt war und ob die Löschung direkt oder nach einem Timeout als Wiederholungsversuch erfolgte. Ein einzelnes Feld actor=vendor-prod verbirgt alle Fakten, die die Reaktion auf den Vorfall verändern könnten.

RFC 8693 beschreibt im OAuth-Kontext eine verwandte Unterscheidung bei Delegation. Es trennt das Subject, in dessen Namen eine Berechtigung besteht, vom aktuellen Akteur, der den JWT-Claim act verwendet. Außerdem heißt es dort, dass Ressourcenserver Zugriffsentscheidungen anhand der Claims auf der obersten Token-Ebene und des aktuellen Akteurs treffen sollten, nicht anhand historischer, verschachtelter Akteure. Das ist auch für lokale Agentensysteme eine sinnvolle Grenze: Bewahre die Herkunft für Untersuchungen auf, aber triff Autorisierungsentscheidungen anhand einer klaren aktuellen Sitzungsidentität statt anhand einer langen, mehrdeutigen Geschichte früherer Aufrufe.

Nenne ein Anbieter-Konto nicht „den Agenten“. Das Konto kann von Agenten, Skripten, Notfalladministratoren und Migrationsjobs verwendet werden. Gib ihm einen präzisen Namen wie external_principal und mache die lokale Sitzung zum Akteur in deinem eigenen Audit-Protokoll.

Die Sitzungsidentität muss vom Starter kommen

Der Prozess, der einen Agenten startet, sollte seine Sitzungsidentität erzeugen, bevor der Agent eine externe Aktion anfordern kann. Lass nicht den Agenten darüber entscheiden. Ein Agent, der session_id=release-approved wählen kann, macht eine spätere Prüfung möglicherweise irreführend.

Ein praktischer Sitzungseintrag enthält genug Informationen, um die ausführbare Datei zu identifizieren und die Arbeit zu erklären:

{
  "session_id": "ses_01JQ6EXAMPLE3K5A",
  "started_at": "2026-07-22T15:04:18Z",
  "initiator": {
    "kind": "human",
    "id": "[email protected]"
  },
  "agent": {
    "process_id": 48192,
    "binary_authority": "signed-local-agent",
    "launch_path": "/workspace/payments"
  },
  "work": {
    "kind": "change_request",
    "id": "CR-1842"
  },
  "parent_session_id": null
}

Die genauen Feldnamen sind weniger wichtig als die Zuständigkeit. Der Starter verwaltet session_id, Startzeit, Identität der ausführbaren Datei und übergeordnete Sitzung. Eine Person oder das aufrufende System liefert die Arbeitsreferenz, aber das Gateway sollte festhalten, wer sie geliefert hat. Der Agent kann eine Beschreibung seiner Aufgabe vorschlagen. Dieser Text darf jedoch niemals die vom Starter gelieferte Identität ersetzen.

Prozess-IDs allein sind schwache Belege. Betriebssysteme verwenden sie wieder, Protokolle überdauern Prozesse, und eine Prozess-ID sagt wenig darüber aus, wer die Binärdatei gestartet hat. Die Signaturinstanz ist auf einem lokalen Entwicklerrechner nützlicher, weil sie die Genehmigungsentscheidung an die signierte Prozessfamilie bindet. Trotzdem solltest du, wenn möglich, den Pfad der ausführbaren Datei und den Startkontext aufzeichnen. Eine bekannte Signatur beweist nicht, dass jeder Aufruf denselben Zweck hatte.

Verwende für jeden neuen Agentenprozess eine neue Sitzung. Eine Sitzung wiederzuverwenden, nur weil die Aufgabennummer gleich ist, verwandelt die Genehmigung für ein kurzes Experiment in einen dauerhaften Berechtigungsbereich. Für langlebige Agenten braucht es eine ausdrückliche Entscheidung: Entweder du behältst eine Sitzung bei und machst ihre Dauer sichtbar, oder du wechselst die Sitzung an einer festgelegten Grenze, etwa bei einer neuen Pull-Anfrage oder nach einer fortgesetzten Terminal-Sitzung. Tu nicht stillschweigend beides.

Die Zuordnung muss vor dem Einfügen der Zugangsdaten erfasst werden

Am sichersten wird ein Akteur unmittelbar vor der Anfrage an diese gebunden, wenn eine vertrauenswürdige Komponente die gemeinsamen Zugangsdaten einfügt und die Anfrage sendet. Alles, was früher geschieht, kann der Agent ändern. Alles, was später geschieht, kann beim Anbieter fehlen, zusammengefasst oder überschrieben worden sein.

Baue einen Aufrufumschlag, den der Agent nicht vollständig selbst erstellen kann. Der Agent liefert die gewünschte Aktion. Das Gateway ergänzt Sitzungsidentität, Autorisierungsentscheidung, Aufruf-ID und Referenz auf die externen Zugangsdaten. Speichere den Umschlag vor der Übertragung und ergänze das Ergebnis nach der Rückkehr.

{
  "call_id": "call_01JQ6F9K4W7D",
  "session_id": "ses_01JQ6EXAMPLE3K5A",
  "external_principal": "vendor-prod",
  "channel": "http",
  "request": {
    "method": "POST",
    "host": "api.vendor.example",
    "path_template": "/v1/deployments/{id}",
    "operation": "create_deployment"
  },
  "authorization": {
    "vault_unlocked": true,
    "session_authorized": true,
    "per_call_approval": false
  },
  "work_id": "CR-1842",
  "attempt": 1,
  "created_at": "2026-07-22T15:08:34Z"
}

Was fehlt, sind Bearer-Token, der vollständige Anfragekörper und die frei formulierte Behauptung, dass der Agent vertrauenswürdig sei. Ein Protokoll, das Geheimnisse speichert, um die Zuordnung zu beweisen, hat seine wichtigste Aufgabe verfehlt. Ein Protokoll, das jedes Byte eines Körpers aufzeichnet, kann außerdem Kundendaten, Quellcode oder regulierte Datensätze offenlegen. Erfasse einen normalisierten Operationsnamen, eine Routenvorlage, ausgewählte nicht geheime Kennungen und einen Inhaltsdigest, wenn der Inhalt selbst für eine Prüfung relevant ist.

Dieses Design trennt außerdem Absicht und Ergebnis. Ein Agent kann create_deployment anfordern, während der entfernte Dienst einen Validierungsfehler zurückgibt. Das Aufrufjournal sollte beide Tatsachen bewahren. Später kannst du feststellen, ob der Agent die Aktion versucht hat, ohne zu behaupten, sie sei erfolgreich gewesen.

Sallyport verwendet diese Platzierung: Der Agent verbindet sich über seinen MCP-Shim, während die App das Geheimnis behält und die HTTP- oder SSH-Aktion ausführt. Die entstehenden Sitzungs- und Aktivitätseinträge können daher einen lokalen Lauf mit der Nutzung eines gemeinsamen Zugangsschlüssels verbinden, ohne den Zugangsschlüssel in den Agentenkontext zu legen.

Von Agenten gelieferte Header sind Belege, aber kein Beweis

Teams fügen oft Header wie X-Agent-Name, X-Task-ID oder X-Run-ID hinzu und betrachten das Problem damit als gelöst. Diese Felder können bei der Zuordnung entfernter Protokolle helfen. Ein Agent, der die Anfrage kontrolliert, kann sie jedoch auch weglassen, ändern oder wiederholen. Sie sind Bezeichnungen, keine Autorisierungsgrenze.

Du kannst Zuordnungs-Header weiterleiten, wenn der Anbieter sie akzeptiert, sofern das Gateway drei Regeln befolgt. Erstens müssen vom Agenten gelieferte Versionen reservierter Header entfernt werden. Zweitens müssen die endgültigen Werte aus der aufgezeichneten Sitzung und dem Aufrufumschlag erzeugt werden. Drittens darf der Eingang des Headers beim Anbieter nur als ergänzender Beleg gelten, nicht als maßgebliche Quelle.

Reserviere beispielsweise dieses kleine Header-Set im Gateway:

X-Execution-Session: ses_01JQ6EXAMPLE3K5A
X-Action-Call: call_01JQ6F9K4W7D
X-Work-Reference: CR-1842

Setze keine E-Mail-Adresse, keinen Prompt, keinen Branch-Namen mit Kundendaten und keinen rohen Befehl in einen Header, nur weil es bequem ist. Header laufen durch Proxys, Tracing-Systeme, Fehlerberichte und Support-Werkzeuge des Anbieters. Verwende undurchsichtige IDs und löse sie anschließend in deinem geschützten lokalen Journal auf.

Manche Anbieter lehnen unbekannte Header ab, entfernen sie oder zeigen sie nicht in ihren Audit-Ansichten an. Das ist normal. Die entfernte API muss nicht zu deinem Identitätssystem werden. Dein Gateway sollte auch dann funktionieren, wenn der Anbieter nur sein gewöhnliches Autorisierungsschema akzeptiert.

Eine weitere Falle: Ein signierter Header ersetzt kein lokales Protokoll. Eine Anfrage-Signatur kann beweisen, dass ein Gateway eine bestimmte Anfrage signiert hat. Sie bewahrt aber weder die menschliche Genehmigung noch Prozessidentität, Aufgabenkontext oder Ergebnis, solange du diese Details nicht lokal aufzeichnest. Signaturen schützen Transportangaben. Sie erzeugen allein kein Untersuchungsprotokoll.

Wiederholungsversuche brauchen eine Herkunftskette statt eines einzelnen Zeitstempels

Autonome Agenten starten Wiederholungsversuche. HTTP-Clients tun das ebenfalls. SSH-Befehle können nach einer getrennten Terminalverbindung erneut ausgeführt werden. Wenn deine Audit-Spur nur eine Zeile pro beabsichtigter Aktion schreibt, verbirgt sie die Abläufe, die doppelte Änderungen verursachen. Wenn sie nur Rohdaten der Anfragen schreibt, sieht eine einzelne beabsichtigte Aktion wie mehrere unabhängige Entscheidungen aus.

Bilde beide Ebenen ab. Gib der beabsichtigten Operation eine operation_id und jedem Netzwerkversuch eine eigene call_id. Verknüpfe Wiederholungen mit dem vorherigen Versuch und zeichne den Grund für die Wiederholung auf.

{
  "operation_id": "op_01JQ6F8P0Z",
  "call_id": "call_01JQ6F9K4W7D",
  "attempt": 2,
  "retries_call_id": "call_01JQ6F79S2M1",
  "retry_reason": "connection_closed_before_response",
  "idempotency_key": "idem_94c2e1",
  "vendor_request_id": "req_8d71"
}

Der retry_reason ist wichtig. Eine Antwort mit 429 bedeutet, dass der Anbieter die erste Anfrage erhalten und wegen einer Überschreitung des Ratenlimits abgelehnt hat. Bei einem Timeout, nachdem Bytes dein Gateway verlassen haben, weißt du nicht, ob der Anbieter die Aktion abgeschlossen hat. Diese Fälle erfordern unterschiedliche Reaktionen und sollten nicht beide zu failed zusammengefasst werden.

Verwende für Operationen, die beim Anbieter einen Zustand anlegen oder ändern, Idempotenzschlüssel, wenn der Anbieter sie unterstützt. Erzeuge den Schlüssel im vertrauenswürdigen Gateway oder lass ihn vom Starter zusammen mit dem Arbeitsdatensatz bereitstellen. Lass kein Modell bei jeder Überarbeitung seines eigenen Plans einen neuen Schlüssel erzeugen, sonst kannst du eine wiederholte Operation nicht mehr erkennen.

Ein typischer Fehler sieht so aus: Sitzung A fordert die Erstellung eines Deployments an, die Verbindung bricht ab und der Client versucht es erneut. Kurz darauf beginnt Sitzung B mit derselben Aufgabenreferenz, sieht kein sichtbares Deployment und fordert die Erstellung erneut an. Beim Anbieter existieren nun zwei Deployments. Ein gutes Journal zeigt zwei Sitzungen, zwei beabsichtigte Operationen, ihre einzelnen Versuche und einen eventuell gemeinsamen Idempotenzschlüssel. Ein schwaches Journal zeigt vier Zeilen mit POST /deployments unter einem Dienstkonto und überlässt es dem Team, den Rest anhand von Zeitstempeln zu rekonstruieren.

Eine Genehmigung muss an einen Prozess gebunden sein, nicht an einen freundlichen Namen

Eine Eingabeaufforderung wie „Release-Agent Zugriff auf die Produktionsumgebung erlauben?“ klingt sinnvoll, bis es zwei Release-Agenten gibt: einer wurde aus einem vertrauenswürdigen Repository gestartet, der andere aus einem kopierten Verzeichnis. Ein Name ist Präsentationstext. Die Genehmigung muss an die Ausführungssitzung und die Prozessinstanz gebunden werden, die sie erzeugt hat.

Eine Genehmigung pro Sitzung ist für Agenten, die mehrere zusammengehörige Aufrufe ausführen, ein guter Standard. Die Bedienperson kann sehen, wer die Anfrage stellt, und muss nicht für eine kurze Aufgabe eine Reihe identischer Dialoge bestätigen. Die Genehmigung sollte ablaufen, sobald der Prozess beendet wird. Ein neuer Prozess muss erneut fragen, selbst wenn sein Aufgabentext gleich ist.

Verwende eine Genehmigung pro Aufruf für Operationen mit hohen Auswirkungen oder ungewöhnlich großem Umfang. Sie ersetzt keine Genehmigung pro Sitzung, sondern beantwortet eine engere Frage: Soll diese konkrete Nutzung dieser Zugangsdaten jetzt fortgesetzt werden? Ein Team, das für jeden harmlosen Lesezugriff eine Einzelgenehmigung verlangt, bringt Menschen dazu, Bestätigungen ungelesen anzuklicken. Das ist absichtlich erzeugte Genehmigungsmüdigkeit und kein menschliches Versagen.

Zeichne die Entscheidung als Ereignis mit einer stabilen Referenz auf:

{
  "approval_id": "apr_01JQ6G3C",
  "session_id": "ses_01JQ6EXAMPLE3K5A",
  "scope": "session",
  "decision": "approved",
  "decided_at": "2026-07-22T15:06:11Z",
  "process_authority": "signed-local-agent"
}

Zeichne nicht bei jedem Aufruf nur einen booleschen Wert auf und behaupte, damit sei die Zustimmung bewiesen. Der boolesche Wert sagt, dass eine Genehmigung existierte. Das Genehmigungsereignis zeigt Prüfern, wann sie erteilt wurde, was sie abdeckte und welche Sitzung sie autorisierte. Wenn eine Bedienperson die Sitzung später widerruft, bewahre diesen Widerruf als neues Ereignis auf. Das alte Genehmigungsereignis zu löschen macht den Datensatz zwar sauberer, aber den Vorfall schwerer verständlich.

Audit-Protokolle des Anbieters sollten deinen Datensatz bestätigen

Protokolle des Anbieters sind nützlich, beschreiben aber normalerweise dessen Identitätsmodell und nicht deines. Ein gemeinsames Token kann als Dienstbenutzer, OAuth-Anwendung, Token-Hash, Installation oder IP-Adresse erscheinen. Das kann bestätigen, dass ein externer Aufruf stattgefunden hat. Es sagt jedoch selten, welche lokale Agentensitzung die Aktion ausgewählt hat.

Die Dokumentation von GitHub zeigt diese Unterscheidung konkret. Aufrufe mit einem GitHub-App-User-to-Server-Token können den Benutzer als Audit-Akteur anzeigen und gleichzeitig den programmatischen Zugriffstyp als diese Tokenform ausweisen. Audit-Ereignisse von GitHub Enterprise stellen für viele Ereignistypen außerdem Felder wie Akteur, Tokeninformationen, Anfrage-ID und User-Agent bereit. Das sind nützliche Belege auf Anbieterseite. Die Bedeutung dieser Felder gehört aber zum Autorisierungsmodell von GitHub und nicht zu deinem Modell lokaler Agentensitzungen.

Verbinde entfernte und lokale Datensätze nach Möglichkeit über stabile Zuordner:

• Speichere eine vom Anbieter zurückgegebene Anfrage-ID aus einem Antwort-Header oder dem Antworttext.
• Speichere deine ausgehende Aufruf-ID und einen normalisierten Operationsnamen.
• Zeichne Antwortstatus, Abschlusszeit und sichere Ressourcenkennungen auf.
• Bewahre den für den Aufruf verwendeten externen Principal auf.
• Behandle die lokale Sitzungs-ID als maßgebliche Ausführungsidentität.

Vermeide es, Datensätze hauptsächlich über die Zeit zusammenzuführen. Zeitabweichungen, asynchrone Verarbeitung beim Anbieter, Wiederholungen und Warteschlangen machen einen ähnlichen Zeitstempel schwächer, als er wirkt. Zeitstempel helfen weiterhin dabei, eine Suche einzugrenzen. Wenn aber eine Anfrage-ID oder ein Idempotenzschlüssel vorhanden ist, sollten sie über die Zuordnung entscheiden.

Einige Anbieter können kurzlebige delegierte Tokens, OAuth-Tokens im Namen eines Benutzers oder App-Installation-Tokens ausstellen. Nutze diese Möglichkeiten, wenn sie dem Anbieter eine aussagekräftige Sicht auf den Akteur geben und zu deinem Berechtigungsmodell passen. GitHub dokumentiert beispielsweise den Unterschied zwischen einer App, die im Namen eines Benutzers handelt, und anderen Formen programmatischen Zugriffs. Das ist eine bessere Zuordnung auf Anbieterseite als ein gemeinsames statisches Token. Trotzdem musst du weiterhin den lokalen Prozess identifizieren, der den Aufruf ausgelöst hat.

Trenne Zugangsdaten nur, wenn dadurch eine echte Grenze entsteht

Der übliche Rat lautet: „Gib jedem Agenten seinen eigenen API-Schlüssel.“ Das ist beliebt, weil es leicht zu erklären ist und eine Anbieter-Auditseite übersichtlicher aussehen lässt. Es ist aber nicht immer die richtige Kontrolle.

Getrennte Zugangsdaten rechtfertigen ihren betrieblichen Aufwand, wenn sie eine sinnvolle Grenze schaffen. Das können unterschiedliche Berechtigungsumfänge für einen Agenten zur schreibgeschützten Erkundung und einen Deployment-Agenten, ein unabhängiger Widerruf beim Anbieter, getrennte Abrechnung oder ein Anbieterprotokoll sein, das den unterschiedlichen Principal für Einsatzteams sichtbar macht. Wenn jeder Schlüssel denselben weitreichenden Umfang, denselben Verantwortlichen für die Rotation und denselben lokalen Ausführungspfad hat, hast du vor allem den Bestand an Geheimnissen vergrößert, nicht die Zuordnung verbessert.

Prüfe vor dem Anlegen einer weiteren Anbieteridentität:

1. Kann die neue Zugangsdaten weniger Berechtigungen erhalten als die gemeinsame?
2. Kannst du sie widerrufen, ohne unabhängige Arbeiten zu unterbrechen?
3. Wird der Anbieter sie als eigenständigen Akteur erfassen, den Einsatzteams nutzen können?
4. Kannst du sie rotieren und ausmustern, ohne vergessene Kopien in lokalen Werkzeugen zurückzulassen?
5. Entfernt sie eine wichtige Autorisierungsentscheidung aus dem lokalen Gateway?

Wenn die meisten Antworten „Nein“ lauten, behalte das gemeinsame externe Konto und verbessere den lokalen Akteur-Datensatz. So erhalten Einsatzteams genau die Informationen, die sie brauchen: Welche Agentensitzung hat den Aufruf getätigt, wer hat ihn initiiert, für welches Arbeitselement, mit welcher Genehmigung und mit welchem Ergebnis?

Dieses Argument hat eine Grenze. Wenn ein Zugangsschlüssel die Administration der Produktionsumgebung erlaubt und ein experimenteller Agent diese Berechtigung nicht braucht, darfst du ihn nicht nur deshalb gemeinsam nutzen, weil deine Protokolle gut sind. Die Zuordnung erklärt eine Aktion im Nachhinein. Der Berechtigungsumfang begrenzt, welche Aktionen überhaupt stattfinden können.

Ein manipulationssicheres Journal muss Reihenfolge und Verweigerungen bewahren

Ein Audit-Datensatz, der nur erfolgreiche Aufrufe beim Anbieter speichert, erzählt nur einen Teil der Geschichte. Verweigerte Aufrufe, Versuche bei gesperrtem Tresor, abgelehnte Genehmigungen und widerrufene Sitzungen erklären oft, warum ein Vorfall nicht schlimmer wurde. Sie zeigen auch, dass ein Agent eine Aktion weiter angefordert hat, nachdem er seine Berechtigung verloren hatte.

Schreibe ein Ereignis, wenn die Sitzung startet, wenn eine Autorisierungsentscheidung getroffen wird, wenn ein Aufruf vorbereitet wird, wenn die externe Aktion endet und wenn eine Sitzung widerrufen wird oder endet. Verknüpfe die Datensätze über IDs, statt ein großes veränderliches Objekt in jede Zeile zu kopieren. Die Kette sollte die Reihenfolge sichtbar machen, ohne dass jeder Leser den Zustand aus Fließtext rekonstruieren muss.

Manipulationssicherheit ist wichtig, weil die lokale Zuordnung oft die einzige Quelle ist, die zwischen gleichzeitig arbeitenden Agenten mit demselben Anbieter-Konto unterscheiden kann. Wenn eine Person mit lokalem Zugriff einen Aufrufdatensatz nach einem Vorfall ändern kann, hat das Team dasselbe Vertrauensproblem nur eine Ebene näher am eigenen System nachgebaut. Hashverkettete Protokolle helfen Prüfern, Änderungen zu erkennen. Sie entscheiden aber nicht, welche Felder erfasst werden müssen. Dafür brauchst du weiterhin ein vollständiges Ereignismodell.

Sallyport erstellt seine Journale für Sitzungen und Aktivitäten aus einem einzigen verschlüsselten, hashverketteten Audit-Protokoll und kann diese Kette offline mit sp audit verify prüfen. Entscheidend ist nicht der Befehlsname. Entscheidend ist, dass eine Sitzungsfreigabe, eine einzelne Aktion und ein späterer Widerruf anhand desselben geordneten Datensatzes überprüft werden können.

Verwende nicht die Bezeichnung eines Anbieter-Kontos als endgültige Antwort, wenn ein Prüfer nach dem Urheber einer Aktion fragt. Folge dem Datensatz vom externen Principal zur Aufruf-ID, von der Aufruf-ID zur Ausführungssitzung, von der Sitzung zum Initiator und zur Genehmigung und anschließend von der Antwort zur eigenen Anfrage-ID des Anbieters. Wenn eine dieser Verbindungen fehlt, verbessere diesen Erfassungspunkt, bevor der nächste gemeinsame Zugangsschlüssel zum Rätsel wird.