Sollte die Fortsetzung einer Agent-Sitzung die alte Genehmigung behalten?

Eine fortgesetzte Agent-Unterhaltung sollte niemals deshalb Autorität erben, weil sie Text geerbt hat. Das Modell kann weiterhin denselben Plan, dieselbe Werkzeughistorie und denselben selbstsicheren Ton haben. Nichts davon zeigt, ob der Prozess, der Zugriff anfordert, derselbe ist, den du genehmigt hast, ob der Zugangsdaten-Tresor verfügbar ist oder ob das Gateway noch einen vertrauenswürdigen Genehmigungseintrag besitzt.

Behandle die Fortsetzung als eine Behauptung von Kontinuität, die geprüft werden muss, nicht als ein Recht, das der Client selbst geltend machen darf. Wenn sich Prozessidentität, Tresorstatus oder Gatewaystatus geändert haben, ist die alte Entscheidung beendet. Fordere vor der nächsten geschützten Aktion eine neue Genehmigung an.

Das klingt streng, bis man sieht, wie Neustarts in der Praxis ablaufen. Ein Coding-Agent aktualisiert sich selbst. Ein Editor startet seinen Helfer nach einem Absturz neu. Ein Benutzer beendet einen festgefahrenen Prozess und startet ihn erneut. Ein Laptop geht in den Ruhezustand, während der Tresor gesperrt wird. Eine Menüleisten-App startet sich nach einem Upgrade neu. Die Unterhaltung verbindet sich oft so reibungslos wieder, dass der Benutzer einen einzigen ununterbrochenen Verlauf sieht. Sicherheitscode, der diesen Verlauf als Autorität behandelt, führt verschiedene Ausführungen unbemerkt zu einer einzigen Genehmigung zusammen.

Eine fortgesetzte Unterhaltung überträgt keine Autorität

Eine Unterhaltung liefert Kontext, während eine Autorisierung eine Entscheidung über einen aktuell handelnden Akteur und eine aktuelle Aktion ist. Beides muss getrennt bleiben.

Agent-Systeme speichern oft eine langlebige Unterhaltungskennung, ein Transkript und vielleicht eine Historie von Werkzeugaufrufen. Das hilft, nach einer Unterbrechung weiterzuarbeiten. Daraus geht hervor, was der Agent tun wollte, welche Dateien er geändert hat und welche API-Anfrage auf halbem Weg fehlgeschlagen ist. Daraus geht nicht hervor, welcher Betriebssystemprozess gerade mit den Werkzeugen verbunden ist.

Betrachte eine typische Abfolge. Ein Agent bereitet eine Deployment-Anfrage vor und erhält eine Sitzungsgenehmigung. Das Gateway startet neu, bevor die Anfrage gesendet wird. Der Agent-Client verbindet sich wieder, lädt das alte Transkript und erklärt, dass er denselben Lauf fortsetzt. Wenn das Gateway diese Aussage akzeptiert und die frühere Genehmigung wiederherstellt, gilt sie nun für einen Prozess, den das Gateway seit seinem Neustart nicht geprüft hat.

Der neue Prozess kann harmlos sein. Es kann sich aber auch um einen neu installierten Build, eine Wrapper-Datei aus einem anderen Verzeichnis oder einen zweiten Werkzeug-Client handeln, der ein zwischengespeichertes Fortsetzungstoken gefunden hat. Durch das Lesen der Unterhaltung lassen sich diese Fälle nicht unterscheiden.

Deshalb ist «Der Benutzer hat diese Aufgabe bereits genehmigt» die falsche Prüfung. Ein Benutzer genehmigt einen identifizierbaren Agent-Lauf unter festgelegten Bedingungen. Die Genehmigung endet, sobald diese Bedingungen nicht mehr gelten oder nicht mehr nachgewiesen werden können.

Das Model Context Protocol macht diese Unterscheidung besonders deutlich. In der Transportdokumentation steht, dass der Client bei stdio den Server als Unterprozess startet und JSON-RPC-Nachrichten über die Standard-Ein- und -Ausgabe austauscht. Das ist eine Beziehung zwischen laufenden Prozessen und keine dauerhafte Freigabe, die in einem Transkript gespeichert wird. Im MCP-Changelog wurden Protokollsitzungen außerdem aus der neueren Arbeit an Streamable HTTP entfernt. Zustandsbehaftete Server sollen stattdessen explizite, vom Server ausgestellte Handles verwenden. Diese Änderung löst die Autorisierung nicht allein, verhindert aber die Annahme, eine Transport-Sitzungskennung sei ein Identitätsnachweis.

Halte die Begriffe in deinem Design auseinander:

• Eine Unterhaltung ist ein Anwendungsdatensatz, der Prozesse überleben kann.
• Ein Prozess ist eine Betriebssysteminstanz mit begrenzter Lebensdauer.
• Eine Sitzungsgenehmigung ist eine Freigabe für einen identifizierten Prozess während dieser Lebensdauer.
• Die Verwendung von Zugangsdaten ist eine Aktion, die aktuelle Bedingungen im Tresor und im Gateway erfüllen muss.

Teams vermischen diese Begriffe, weil in einer reibungslosen Demo alle vier scheinbar gemeinsam weiterlaufen. Produktionsneustarts trennen sie.

Prozessidentität besteht aus mehreren Teilen

Eine Prozess-ID allein reicht für eine dauerhafte Bindung der Genehmigung nicht aus, weil Betriebssysteme IDs nach dem Ende eines Prozesses wiederverwenden können. Ein Prozesspfad allein ist ebenfalls zu schwach, weil sich eine Datei an diesem Pfad ändern kann. Auch eine Codesignatur allein reicht nicht, weil dasselbe signierte Programm an mehreren Orten gleichzeitig laufen kann.

Erstelle die Identität, die du anzeigst und bindest, aus mehreren Fakten, die du zum Zeitpunkt der Genehmigung sammelst. Unter macOS sind der laufende Prozess, seine Identität als ausführbare Datei und seine Codesignaturinstanz ein sinnvoller Ausgangspunkt. Apple beschreibt sogenannte designated requirements als die Code-Anforderung, die signierten Code identifiziert. Sie wird häufig aus der Signaturinstanz und der eingebetteten Kennung gebildet, wenn die App keine ausdrückliche Anforderung bereitgestellt hat. Damit erhält der Benutzer etwas, das er besser prüfen kann als eine bloße PID.

Verwandle eine Signaturinstanz trotzdem nicht in eine magische Antwort. Zwei getrennte Prozesse mit derselben designated requirement sind weiterhin zwei getrennte Prozesse. Ein signierter Agent kann einen unsignierten Helfer starten. Eine lokal erstellte Entwicklungs-Binärdatei kann eine Ad-hoc-Signatur haben. Ein Angreifer, der den genehmigten Prozess nach der Genehmigung kontrolliert, wird nicht sicher, nur weil die ursprüngliche Signatur korrekt aussah.

Verwende für die Prozessbindung mehrere Fakten, die gemeinsam aussagekräftig sind:

approval_subject = {
  process_id: 48192,
  process_start_time: "2026-07-22T14:18:03Z",
  executable_file_id: "volume:.../inode:...",
  executable_hash: "sha256:...",
  signing_requirement: "anchor ... and identifier ...",
  parent_process_id: 48001,
  launch_nonce: "random-128-bit-value"
}

Die genauen Felder unterscheiden sich je nach Plattform. Die Regel bleibt gleich: Das Gateway braucht genügend Belege, um eine alte Genehmigung abzulehnen, sobald das alte Subjekt verschwunden ist. Die Start-Nonce ist wichtig, weil sie vom Gateway erzeugt wird, nachdem es den neuen Prozess geprüft hat. Ein Client kann sie nicht sicher aus einem lokalen Cache wiederherstellen und das als Kontinuität ausgeben.

Du musst dem Benutzer nicht jedes Feld zeigen. In der Praxis wird die Genehmigungskarte dadurch meist schlechter. Zeige die Signaturinstanz, den Namen der ausführbaren Datei und eine klare Beschreibung des Aktionskanals. Bewahre die vollständige Bindung zur späteren Prüfung im Journal auf.

Eine harte Grenze sollte man klar benennen. Wenn dein Gateway den Prozess, der die Anfrage stellt, weder sehen noch attestieren kann, kann es keine prozessspezifische Genehmigung erteilen. Es kann weiterhin eine kleinere Genehmigung ausstellen, die an ein anderes vertrauenswürdiges Subjekt gebunden ist. Es sollte jedoch nicht behaupten, den Prozess überprüft zu haben. Einen vom Client gelieferten Prozessnamen als «Identität» zu bezeichnen, verleiht schwachen Designs nur offiziell klingende Begriffe.

Ein Prozessneustart beendet eine Sitzungsgenehmigung

Eine Sitzungsgenehmigung sollte enden, sobald ihr Prozess beendet wird, selbst wenn der Ersatzprozess identischen Code, identische Argumente und dieselbe Gesprächshistorie besitzt.

Diese Regel erfasst Fälle, die harmlos wirken, bis sie Schaden anrichten. Angenommen, ein Agent läuft unter einer Editor-Erweiterung. Die Erweiterung stürzt ab, ihre Aufsicht startet einen Ersatzprozess und dieser lädt den alten Aufgabenstatus. Der neue Prozess hat dasselbe Projektverzeichnis und wahrscheinlich dasselbe Benutzerkonto. Er besitzt nicht die Autorität, die dem abgestürzten Prozess erteilt wurde.

Dasselbe gilt, wenn ein Agent weitere Prozesse startet. Ein Elternprozess kann eine Genehmigung erhalten und anschließend einen Helfer für Shell-Befehle oder Netzwerkaufrufe starten. Gilt die Genehmigung nur für den Elternprozess, muss der Helfer entweder über eine kontrollierte Delegation durch den Elternprozess handeln oder eine eigene Genehmigung anfordern. Ein Bearer-Token durch den Prozessbaum weiterzugeben, macht die Genehmigung genau auf die Weise übertragbar, die du vermeiden willst.

Versuche nicht, dieses Problem mit einer langen Ablaufzeit zu beheben. Eine fünfminütige Genehmigung, die jeder Ersatzprozess fortsetzen kann, ist keine fünfminütige Sitzungsgenehmigung. Sie ist ein fünfminütiger Bearer-Schlüssel mit einer freundlichen Bezeichnung.

Eine bessere Regel ist einfach:

if current.process_id != approved.process_id:
    deny("approval belongs to a different process")

if current.process_start_time != approved.process_start_time:
    deny("process lifetime changed")

if current.launch_nonce != approved.launch_nonce:
    deny("gateway has not bound this run")

Das Gateway sollte diese Prüfung durchführen, bevor es entscheidet, ob eine Anfrage für eine Sitzungsgenehmigung infrage kommt. Prüfe dies nicht nur bei der Wiederverbindung des Agents. In einer Client-Architektur, die Arbeit multiplexed, kann sich ein Prozess verändern. Auch ein veraltetes Genehmigungsobjekt kann länger als erwartet im Speicher bleiben.

Ein Benutzer mag einwenden, dass der Ersatz offensichtlich derselbe Agent ist. Meist ist das ein Wunsch nach einer reibungsloseren Genehmigungskarte und kein Grund, die Grenze aufzuheben. Erkläre, dass der Agent neu gestartet wurde, und zeige die neue Signaturinstanz. Ein bewusster Klick ist günstiger als die Untersuchung eines unbeabsichtigten Produktionsaufrufs, der von einem ungeprüften Prozess ausging.

Eine Änderung des Tresorstatus nimmt das Handlungsrecht

Der Tresorstatus ist kein Hintergrunddetail. Wenn ein Tresor gesperrt wird, muss jede frühere Entscheidung, die von seiner Verfügbarkeit abhing, die Freigabe für Aktionen mit Zugangsdaten beenden.

Zwei Fehler müssen vermieden werden. Der erste ist offensichtlich: Ein Gateway verwendet eine entschlüsselte Zugangsinformation weiter, nachdem der Tresor gesperrt wurde. Der zweite ist unauffälliger: Das Gateway stellt eine Aktion mit Zugangsdaten während der Sperre in eine Warteschlange und führt sie automatisch aus, sobald der Tresor entsperrt wird, weil noch eine alte Sitzungsgenehmigung existiert. Dieser zweite Fehler macht das spätere Entsperren durch einen Menschen versehentlich zu einer Genehmigung für eine frühere Anfrage.

Apples Dokumentation zum Keychain beschreibt die Grenze klar. Die Zugriffskontrolle kann die Anwesenheit des Benutzers verlangen, wenn eine App ein Element abruft. Apple empfiehlt, die restriktivste passende Zugriffseinstellung zu wählen. Die Secure Enclave kann kryptografische Operationen absichern, ohne biometrische Daten an Software im Benutzerbereich weiterzugeben. Diese Mechanismen sind nützlich, entscheiden aber nicht über die Semantik deines Gateways. Deine Anwendung muss festlegen, was mit bereits genehmigten Agent-Läufen passiert, wenn diese Sperre greift.

Die sicherste Antwort ist eine Tresor-Epoche. Erhöhe sie, sobald der Tresor gesperrt oder entsperrt wird, sich zurücksetzt oder seine geschützte Sitzung verliert. Hänge die Epoche an jeden Genehmigungseintrag. Eine Abweichung bedeutet, dass der Eintrag keine Aktion mit Zugangsdaten autorisieren kann.

approved_vault_epoch = 17
current_vault_epoch = 18

if approved_vault_epoch != current_vault_epoch:
    require_new_session_approval()

Das bedeutet nicht, dass jedes Entsperren zu einem lästigen Ritual werden muss. Wenn der Agent keine aktive Sitzung hat, passiert nichts. Benötigt eine Anfrage nach dem Entsperren Zugangsdaten, kann das Gateway eine neue Genehmigungskarte anzeigen und erklären, warum: Der Tresorstatus hat sich nach der früheren Genehmigung geändert. Bei Zugangsdaten, die für jede Verwendung eine Genehmigung verlangen, bleibt die Prüfung pro Aufruf bestehen. Sitzungsgenehmigung und Genehmigung pro Aufruf beantworten unterschiedliche Fragen.

Eine Sitzungsgenehmigung fragt, ob dieser identifizierte Prozess diesen Kanal während seines aktuellen Laufs verwenden darf. Eine Genehmigung pro Aufruf fragt, ob der Mensch genau diese Verwendung jetzt möchte. Eine Sitzungsgenehmigung als Ersatz für eine Entscheidung pro Aufruf zu behandeln, widerspricht dem Zweck einer entsprechend markierten Zugangsinformation.

Ein Gateway-Neustart löscht sein Wissen über die Freigabe

Ein Gateway-Neustart sollte Sitzungsfreigaben im Speicher ungültig machen, weil das neu gestartete Gateway nicht beweisen kann, dass sein alter Genehmigungseintrag noch vollständig und unverändert an die reale Welt gebunden ist.

Manche Teams speichern Genehmigungstoken dauerhaft und laden sie nach einem Neustart wieder. Die Motivation ist nachvollziehbar: Der Benutzer hat einmal geklickt, der Agent arbeitet noch und ein Neustart soll den Ablauf nicht unterbrechen. Ein dauerhaft gespeichertes Token wird jedoch schnell zu einer wiederverwendbaren Zugangsinformation. Der Client sendet es nach der Wiederverbindung zurück, das Gateway erkennt es und die alte Freigabe kehrt zurück, ohne den Prozess erneut zu prüfen.

Dieses Design macht auch die Wiederherstellung mehrdeutig. Ist das Gateway abgestürzt, bevor es die Aktion gesendet hat? Hat es die Aktion gesendet und ist abgestürzt, bevor es die Antwort aufgezeichnet hat? Hat der entfernte Dienst die Anfrage nach einer Wiederholung zweimal erhalten? Autorisierungswiederherstellung und Wiederholung der Anfrage als einen einzigen Vorgang zu behandeln, vermischt Identitätswiederherstellung mit Zustellungswiederherstellung. Dafür braucht es unterschiedliche Kontrollen.

Gib jeder Lebensdauer des Gateways eine Boot-ID, die nur im aktuellen Speicher existiert. Füge sie jedem Genehmigungseintrag hinzu. Nach einem Neustart unterscheidet sich die aktuelle Boot-ID, deshalb kann kein früherer Sitzungseintrag mehr passen.

approval = {
  gateway_boot_id: "b7f9...",
  process_binding: "...",
  vault_epoch: 17,
  approved_at: "2026-07-22T14:20:11Z"
}

if approval.gateway_boot_id != gateway.current_boot_id:
    require_new_session_approval()

Das Gateway kann ein Audit-Ereignis speichern, das festhält, dass eine Genehmigung erteilt wurde. Es sollte dieses Ereignis jedoch nicht als aktive Freigabe laden. Die Audit-Historie erklärt, was passiert ist. Sie stellt keine aktive Autorisierungsbeziehung wieder her.

Sallyport folgt diesem Muster, indem der Tresor in der signierten Menüleisten-App verbleibt und Aktionen bei gesperrtem Tresor verweigert werden. Die Autorisierung pro Sitzung ist an einen neuen Agent-Prozess gebunden, und ein Benutzer kann einen aufgezeichneten Lauf sofort widerrufen. Diese Grenzen sind nur dann nützlich, wenn ein Neustart oder eine Sperre einen alten Lauf nicht unbemerkt an eine neue Entscheidung binden kann.

Binde die Genehmigung an Belege, die der Client nicht wiedergeben kann

Der Genehmigungseintrag braucht vom Server erstellte, aktuelle Belege. Ein vom Client bereitgestelltes Fortsetzungstoken kann dem Gateway helfen, eine Unterhaltung zu finden oder eine verständliche Bezeichnung anzuzeigen. Es kann jedoch nicht der Nachweis sein, dass die Autorisierung noch gültig ist.

Das kleinste praktikable Muster verwendet vier veränderliche Werte:

1. Das Gateway erzeugt beim Start eine zufällige Boot-ID.
2. Das Gateway erzeugt eine zufällige Lauf-Nonce, nachdem es einen neu verbundenen Prozess identifiziert hat.
3. Der Tresor verwaltet eine Epoche, die sich bei jeder Änderung der geschützten Verfügbarkeit ändert.
4. Das Gateway erzeugt eine Genehmigungs-ID erst, nachdem der Benutzer den identifizierten Lauf genehmigt hat.

Danach bewertet das Gateway jede Aktion anhand aller Werte, die es selbst besitzt. Der Client kann eine Aktion anfordern, aber keine Genehmigung erzeugen, die zu einer neuen Boot-ID oder einer neuen Lauf-Nonce passt.

Hier ist ein kompaktes Zustandsmodell, das Teams anpassen können. Die Gesprächsreferenz wird absichtlich nur als Anzeigekontext gespeichert und niemals als Autorisierungsfeld verwendet.

{
  "run": {
    "conversation_ref": "worktree-cleanup-42",
    "process": {
      "pid": 48192,
      "started_at": "2026-07-22T14:18:03Z",
      "signing_requirement": "recorded-at-approval",
      "launch_nonce": "gateway-generated"
    }
  },
  "approval": {
    "id": "gateway-generated",
    "gateway_boot_id": "gateway-generated",
    "vault_epoch": 17,
    "expires_when_process_exits": true
  }
}

Beachte, was fehlt: kein wiederverwendbares resume_authorized-Flag und kein Ablaufzeitpunkt, der einen beendeten Prozess in ein aktives Subjekt verwandeln könnte. Du kannst zusätzlich eine kurze Zeitüberschreitung verwenden, aber eine Zeitüberschreitung ist keine Identität.

Wenn sich der Agent wieder verbindet, sollte er die Initialisierung und die Registrierung des Prozesses wiederholen. Das Gateway sollte anschließend eines dieser Ergebnisse zurückgeben:

REAUTH_REQUIRED process_changed
REAUTH_REQUIRED gateway_restarted
REAUTH_REQUIRED vault_state_changed
RETRY_SAFE previous_action_not_started
STATUS_UNKNOWN inspect_activity_journal

Die Unterscheidung zwischen RETRY_SAFE und STATUS_UNKNOWN ist wichtig. Ein Gateway kann nur dann sagen, dass eine Aktion nicht gestartet wurde, wenn es dauerhafte Belege dafür hat. Hat es eine HTTP-Anfrage an den Netzwerk-Stack übergeben und danach die Stromversorgung verloren, kann die ehrliche Antwort unbekannt lauten. Der Agent sollte das Ziel oder das Journal prüfen, bevor er eine möglicherweise doppelte Aktion versucht.

Das Wiederholen einer Aktion ist etwas anderes als die Wiederherstellung einer Genehmigung

Ein Wiederverbindungsprotokoll sollte zuerst die Kommunikation wiederherstellen, danach eine frische Autorisierung etablieren und erst dann entscheiden, ob eine Wiederholung sinnvoll ist. Werden diese Schritte verbunden, entstehen doppelte Anfragen und geerbte Genehmigungen.

Verwende für eine geschützte Aktion, deren Verbindung verloren geht, diese Reihenfolge:

1. Der Agent verbindet sich erneut und initialisiert eine neue Gateway-Beziehung.
2. Das Gateway identifiziert den aktuellen Prozess und vergleicht ihn mit einem möglicherweise vorhandenen aktuellen Laufeintrag.
3. Das Gateway prüft seine Boot-ID und die aktuelle Tresor-Epoche.
4. Wenn sich eine Autorisierungseigenschaft geändert hat, fordert das Gateway vor der Verwendung von Zugangsdaten eine neue Sitzungsgenehmigung an.
5. Das Gateway meldet, ob es weiß, dass die frühere Aktion nicht gestartet wurde, abgeschlossen ist oder einen unbekannten Status hat.

Die Reihenfolge ist wichtig. Fordere den Agent nicht auf, die ursprüngliche Anfrage erneut zu senden, bevor die aktuelle Autorisierung etabliert ist. Sonst kann ein wieder verbundener Client Druck rund um eine alte Anfrage aufbauen: «Ich war bereits genehmigt, bring sie einfach zu Ende.» Ein Mensch sieht oft dieselben Worte und nimmt an, die Anfrage sei eine harmlose Fortsetzung. Das Gateway sollte die veränderte Bedingung sichtbar machen, bevor es die Aktion darstellt.

Verwende bei HTTP-APIs einen Idempotenzschlüssel, wenn das Ziel dies unterstützt. Erzeuge den Schlüssel für die logische Geschäftsaktion, speichere ihn vor dem Senden dauerhaft und verwende ihn nur wieder, wenn du die Autorisierung für die Wiederholung erneut hergestellt hast. Ein Idempotenzschlüssel hilft dem entfernten Dienst, doppelte Zustellungen zu erkennen. Er autorisiert die Wiederholung nicht.

Bei SSH brauchen Wiederholungen mehr Sorgfalt, weil ein entfernter Befehl einen Rechner teilweise verändert haben kann, bevor die Verbindung abbricht. Bevorzuge Operationen, die eine eindeutige Markierung schreiben oder den bestehenden Zustand abfragen, bevor sie ihn erneut ändern. Ein Befehl wie mkdir kann durch die Prüfung des erwarteten Verzeichnisses sicherer werden. Ein Befehl, der Zugangsdaten rotiert oder einen Dienst neu startet, sollte nach einem Transportfehler normalerweise einen unbekannten Status melden, bis der Agent den entfernten Zustand gelesen hat.

Verstecke diese Unsicherheit nicht hinter optimistischen Formulierungen. Ein Agent, der nach dem Verlust der Antwort «Deployment abgeschlossen» sagt, erfindet Sicherheit. Das Journal sollte festhalten, dass das Ergebnis der Aktion nicht beobachtet wurde, und der Agent sollte den Zustand prüfen.

Die unschönen Fehler zeigen die richtige Grenze

Der aussagekräftigste Test ist keine saubere Wiederverbindung. Es ist ein Neustart mitten in einer Aktion, gefolgt von einem Agent, der unbedingt weitermachen will.

Stell dir einen Agent vor, der die Sitzungsgenehmigung hat, über eine HTTP-API einen Issue-Tracker zu aktualisieren. Er bereitet eine Anfrage vor, erhält die Genehmigung und ruft das Gateway auf. Das Gateway fügt die Zugangsdaten ein und beginnt, die Anfrage zu senden. In diesem Moment startet die Gateway-App neu. Der Agent verbindet sich mit seiner bisherigen Gesprächsreferenz und einem lokal zwischengespeicherten Werkzeugstatus wieder.

Ein schwaches Design akzeptiert die alte Referenz, stellt die Genehmigung wieder her und wiederholt die Anfrage. Der Issue-Tracker kann zwei Kommentare erhalten. Schlimmer noch: Die Genehmigung gilt für den Prozess, der jetzt den zwischengespeicherten Zustand liefert.

Ein sorgfältiges Design führt zu einem weniger spektakulären Ergebnis. Das neu gestartete Gateway erzeugt eine neue Boot-ID. Es lehnt die alte Sitzungsfreigabe ab. Es fordert die Genehmigung für den aktuell verbundenen Prozess an. Es prüft das Aktivitätsjournal. Wenn das Journal eine abgeschlossene Anfrage verzeichnet, gibt es das Ergebnis zurück. Wenn es verzeichnet, dass keine Anfrage das Gateway verlassen hat, erlaubt es eine neue, genehmigte Wiederholung. Wenn die Aktion die Zustellungsgrenze überschritten hat, aber das Ergebnis verloren ging, meldet es einen unbekannten Status. Der Agent liest den Issue, bevor er entscheidet, ob ein weiterer Schreibvorgang nötig ist.

Das ist mehr Arbeit, als dem Fortsetzungstoken zu vertrauen. Es ist aber auch der Unterschied zwischen einem nachvollziehbaren Aktionssystem und einem System, das Mehrdeutigkeiten so lange verbirgt, bis ein Benutzer doppelte Änderungen entdeckt.

Teste mindestens diese Fälle, bevor du dein Verhalten bei Fortsetzungen als sicher bezeichnest:

• Beende den Agent nach der Genehmigung und starte anschließend einen Ersatz, der dieselbe Gesprächsreferenz vorlegt.
• Starte das Gateway neu, während ein genehmigter Agent aktiv bleibt und einen weiteren Aufruf mit Zugangsdaten versucht.
• Sperre und entsperre den Tresor, während ein genehmigter Agent auf eine Wiederholung wartet.
• Starte zwei identisch signierte Agent-Prozesse und stelle sicher, dass die Genehmigung für den einen nicht für den anderen gilt.
• Verwirf die Netzwerkantwort, nachdem das Gateway eine externe Anfrage begonnen hat, und prüfe, ob der Wiederholungsweg die Unsicherheit der Zustellung meldet.

Diese Tests finden einen besonders häufigen Fehler: Entwickler testen nur, ob der legitime Client sich erholen kann. Sie testen nicht, ob ein anderer Client den Wiederherstellungsweg ausleihen kann.

Logs müssen erklären, warum die Autorität endete

Ein Audit-Log sollte Änderungen der Autorität als eigene Ereignisse erfassen. Ein Ermittler sollte sie nicht aus Lücken zwischen Werkzeugaufrufen ableiten müssen.

Zeichne die Sitzungsgenehmigung mit den verwendeten Fakten zur Prozessidentität, der Gateway-Boot-ID, der Tresor-Epoche und dem für den Benutzer sichtbaren Subjekt auf. Zeichne das Ende mit einem konkreten Grund auf: Prozess beendet, Abweichung der Prozessidentität, Gateway neu gestartet, Tresor gesperrt, manuell widerrufen oder Genehmigung abgelaufen. Zeichne eine verweigerte Aktion getrennt von einer fehlenden Aktion auf. Das sind unterschiedliche Fakten.

Eine hilfreiche Aktivitätsfolge sieht so aus:

14:20:11 session_approved run=R31 signer="Example Developer ID" boot=B8 vault=17
14:23:04 gateway_restarted previous_boot=B8 current_boot=C2
14:23:06 action_denied run=R31 reason=gateway_restarted
14:23:09 session_approved run=R32 signer="Example Developer ID" boot=C2 vault=17
14:23:12 http_action_started run=R32 request=Q44
14:23:13 http_action_result run=R32 request=Q44 status=201

Es geht nicht darum, in jedem Journaleintrag geheime Werte oder vollständige Anfrageinhalte offenzulegen. Wichtig ist die kausale Kette: Wer hat angefragt, welche Autorität galt, welcher Zustand hat sich geändert und hat das Gateway die Aktion tatsächlich ausgeführt?

Manipulationsnachweise sind hier wichtig, weil eine Genehmigungshistorie nur dann nützlich ist, wenn spätere Änderungen erkannt werden können. Sallyport erstellt seine Sitzungs- und Aktivitätsjournale aus einem schreibgeschützten, verschlüsselten und hashverketteten Audit-Log. Mit sp audit verify kann diese Kette offline über dem Chiffretext geprüft werden, ohne einen Tresorschlüssel zu benötigen. So kann ein Prüfer die Abfolge bestätigen, ohne die Geheimnisse zu öffnen, die die Aktionen ermöglicht haben.

Übertrage einem Audit-Log nicht die Aufgabe der Verhinderung. Ein perfekter Eintrag, der zeigt, dass eine alte Genehmigung wiederverwendet wurde, ist ein Beleg für eine schlechte Entscheidung und keine Lösung dafür. Das laufende Gateway muss die Aktion vor dem Einfügen von Zugangsdaten verweigern, wenn die Bindung nicht mehr passt.

Eine erneute Genehmigung muss konkret genug sein, um die Unterbrechung zu rechtfertigen

Eine erneute Genehmigung nach einer relevanten Zustandsänderung ist sinnvoll. Eine vage Aufforderung bringt Benutzer jedoch dazu, sie einfach wegzuklicken. Die Genehmigungskarte sollte sagen, was sich geändert hat und wer jetzt anfragt.

Vermeide eine allgemeine Nachricht wie «Sitzung abgelaufen. Erneut genehmigen?» Diese Formulierung lässt den Benutzer das Ereignis als bloßen Timer behandeln. Zeige stattdessen die Bedingung, die die Kontinuität unterbrochen hat: «Das Gateway wurde neu gestartet. Soll dieser neu verbundene Prozess die Git-Hosting-API für diesen Lauf verwenden?» Wenn sich die Prozessidentität geändert hat, zeige die neue Signaturinstanz oder weise darauf hin, dass das Programm unsigniert ist. Wenn der Tresor gesperrt war, sage, dass das Entsperren des Tresors die frühere Agent-Freigabe nicht wiederhergestellt hat.

Hier entscheidest du auch, ob die Sitzungsgenehmigung für einen Kanal zu weit gefasst ist. Wenn ein fortgesetzter Agent eine SSH-Änderung in der Produktion vornehmen will, kann eine Genehmigung pro Aufruf selbst nach einer frischen Sitzungsentscheidung die sinnvollere Wahl sein. Dass die Sitzung jede Prüfung bestanden hat, macht nicht jeden Befehl gleich sicher.

Versuche nicht, Genehmigungsmüdigkeit zu lösen, indem du Genehmigungen übertragbar machst. Löse sie, indem du unnötige Änderungen verringerst, eine stabile Prozessidentität anzeigst, wenn es eine gibt, und den Umfang jeder Entscheidung verständlich hältst. Der Benutzer kann eine konkrete Anfrage genehmigen. Er kann nicht sicher das Versprechen genehmigen, dass jeder zukünftige Prozess mit einem alten Transkript handeln darf.

Die Implementierungsregel passt auf einen Notizzettel: Bewahre den Kontext über eine Fortsetzung hinweg, aber baue die Autorität aus aktuellen Belegen neu auf. Wenn sich Prozess, Tresor oder Gateway ändern, gehört die alte Genehmigung zum vergangenen Lauf.