# macOS-Logout-Sicherheit: lokale Agentenberechtigung beenden

Ein Logout des Entwicklers muss die lokale Agentenberechtigung beenden, selbst wenn ein Agent-Prozess, eine Netzwerkanfrage oder eine Menüleisten-App das noch nicht bemerkt hat. Wer Logout als höfliche Bitte zum Aufräumen behandelt, schafft ein Zeitfenster, in dem ein unbeaufsichtigter Rechner weiterhin mit den Zugangsdaten eines Menschen handeln kann.

Das ist bei Coding-Agenten besonders wichtig, weil ihre nützliche Arbeit eine Grenze überschreitet. Sie rufen APIs auf, öffnen SSH-Sitzungen, erstellen Tickets, veröffentlichen Pakete oder ändern Infrastruktur. Wenn ihre Berechtigung von der Person an der Tastatur stammt, erlischt sie, sobald diese Person die macOS-Sitzung verlässt. Das System sollte Beweise für das Geschehene bewahren, aber nicht die Möglichkeit, weitere Aktionen auszuführen.

Der Fehler, den ich immer wieder sehe, ist die Vermischung von drei verschiedenen Dingen: einem lokal gespeicherten Geheimnis, einer einem Prozess erteilten Freigabe und einer bereits laufenden Aktion. Für sie gelten unterschiedliche Regeln beim Herunterfahren. Ein einzelner `quit`-Handler kommt zu spät und ist zu ungenau.

## Logout ist eine Berechtigungsgrenze, kein App-Ereignis

macOS-Logout-Sicherheit bedeutet, dass das Fehlen einer interaktiven Benutzersitzung künftige Aktionen mit Zugangsdaten verhindern muss, unabhängig davon, ob jede Anwendung sauber beendet wird. Eine Desktop-Anwendung kann bei einem normalen Logout zwar Benachrichtigungen zur Beendigung erhalten, aber die Sicherheit darf nicht davon abhängen, dass diese Benachrichtigungen eintreffen, vollständig verarbeitet werden oder in einer bestimmten Reihenfolge laufen.

Ein Benutzer kann den Laptop schließen, den Benutzer wechseln, eine App sofort beenden, die Stromversorgung verlieren oder den Logout auslösen, während ein Agent auf einen langsamen Endpunkt wartet. Auch das Betriebssystem kann Prozesse in einer Reihenfolge beenden, mit der dein Code nicht gerechnet hat. Ein Design nach dem Muster «Wir widerrufen den Zugriff in `applicationWillTerminate`» hat bereits zu viel Unsicherheit akzeptiert.

Die Dokumentation von Apple's `launchd` macht die hier wichtige Abgrenzung deutlich. Sie unterscheidet zwischen System-, Benutzer- und grafischen Login-Domänen. Ein Job in einer grafischen Benutzerdomäne gehört zu einer bestimmten angemeldeten Sitzung, während ein Systemjob ein anderes Lebensdauer- und Berechtigungsmodell hat. Lies «Der Prozess läuft noch» nicht als Beweis dafür, dass er weiterhin für den abgemeldeten Benutzer handeln darf.

Baue die Autorisierungsprüfung um einen aktuellen Sitzungsfakt auf, den das Aktions-Gateway beim Aufruf prüfen kann. Jede Aktion muss in dieser Reihenfolge fragen:

1. Ist der Tresor für diese angemeldete Benutzersitzung gerade geöffnet?
2. Gehört diese Anfrage zu einem aktiven, autorisierten Agent-Prozess in derselben Sitzung?
3. Erfordert diese Zugangsinformation eine Freigabe für genau diese Verwendung?
4. Hat ein Logout- oder Sitzungswiderrufsereignis die Sitzungsgeneration bereits erhöht?

Die vierte Prüfung verhindert eine subtile Race Condition. Eine Anfrage kann die ersten drei Prüfungen bestehen, in einer Warteschlange liegen und den Executor erst erreichen, nachdem der Logout begonnen hat. Eine Generationsnummer, die unmittelbar vor dem Einfügen von Zugangsdaten oder der SSH-Ausführung erneut geprüft wird, lässt eine solche veraltete Anfrage scheitern.

Mache das Logout-Verhalten nicht davon abhängig, dass ein Agent dem Beenden zustimmt. An dieser Grenze ist der Agent ein nicht vertrauenswürdiger Aufrufer. Er kann verwirrt, beschäftigt, kompromittiert oder schlicht verschwunden sein.

## Ein gesperrter Tresor muss ablehnen, bevor das Aufräumen beginnt

Das Tresortor sollte zuerst geschlossen werden und aus Sicht des Executors synchron schließen. Sobald das Tor geschlossen ist, dürfen weder neue HTTP-Zugangsdaten eingefügt noch neue SSH-Authentifizierungen gestartet werden. Das Aufräumen kann danach folgen, darf aber nicht der Mechanismus sein, der das System sicher macht.

Diese Reihenfolge klingt selbstverständlich, bis eine App eine Anfragewarteschlange verwaltet. Ein typischer Fehler sieht so aus: Ein Agent stellt fünf Deployment-Aufrufe ein, die Benutzeroberfläche beginnt mit dem Logout-Aufräumen, die App entfernt die sichtbare Sitzungskarte und ein Worker-Thread nimmt den vierten Aufruf mit einer zuvor aufgelösten Zugangsdaten-Referenz aus der Warteschlange. Die App wirkt abgemeldet, während die Aktion den externen Dienst trotzdem erreicht.

Halte ein einzelnes Autorisierungsobjekt in dem Prozess, der die Geheimnisse verwendet. Es sollte eine undurchsichtige Sitzungskennung, einen Generationenzähler und einen Aktivierungsstatus enthalten. Worker erhalten niemals Geheimnis-Bytes. Sie erhalten eine Aktionsanfrage und müssen unmittelbar vor der Tresoraktion eine frische Autorisierungsfreigabe beziehen.

Eine kleine Struktur genügt:

```text
AuthorityState {
  sessionID: 6C17...
  generation: 41
  vaultOpen: true
  logoutStarted: false
}

execute(request):
  lease = authority.issueLease(request, generation: 41)
  vault.perform(request, lease)

beginLogout():
  authority.logoutStarted = true
  authority.vaultOpen = false
  authority.generation = 42
  cancelPendingRequests()
```

`vault.perform` muss die Freigabe ablehnen, wenn ihre Generation nicht mehr übereinstimmt. Dieser zweite Vergleich gehört so nah wie möglich an den Punkt, an dem der Tresor einen HTTP-Header liefert, einen SSH-Helfer startet oder eine Anfrage signiert. Eine Prüfung nur beim Einreihen der Anfrage lässt eine relevante Race Condition offen.

Bei einer macOS-App, die ihren Tresor mit Secure Enclave und Touch ID schützt, ist hardwaregebundener Zugriff hilfreich, weil er dem Gate einen klaren lokalen Besitzer gibt. Er ersetzt den Sitzungsstatus aber nicht. Eine vor dem Logout akzeptierte biometrische Abfrage kann einen Aufruf nach dem Logout nicht autorisieren.

Das Tresortor von Sallyport folgt dieser Regel: Solange es gesperrt ist, wird jede Aktion abgelehnt. Diese feste Grenze ist besser als eine Ausnahmeliste für das Herunterfahren, weil Ausnahmelisten immer weiter wachsen, bis niemand mehr erklären kann, welcher Aufruf ihnen noch entkommt.

## Eine aktive Freigabe gehört zu einem Prozess und einer Sitzung

Eine Benutzerfreigabe sollte an einen bestimmten Agent-Prozess, dessen Codesignatur und die aktuelle macOS-Anmeldesitzung gebunden sein. Sie darf niemals bedeuten: «Dieses Konto hat dieses Tool irgendwann früher freigegeben.»

Die Prozessidentität ist mehr als eine Prozess-ID. Prozess-IDs werden wiederverwendet. Ein Aufrufer, der nur PID 4812 speichert, kann nach genügend Prozesswechseln versehentlich einen anderen Prozess freigeben. Speichere neben der PID die Startzeit des Prozesses und eine Codesignatur-Identität. Wenn der Prozess ein Kind eines Terminals oder einer Editor-Integration ist, bewahre genügend Informationen zum übergeordneten Prozess auf, um den Weg in der Freigabeaufzeichnung zu erklären. Mache die Prozesshierarchie aber nicht zu deinem einzigen Vertrauenssignal. Shell-Wrapper und Prozess-Supervisoren verändern sie ständig.

Die Freigabekarte sollte mit der Signaturautorität beginnen. Sie ermöglicht dem Entwickler eine sinnvolle Frage: «Soll dieser signierte Agent-Prozess in dieser Sitzung handeln dürfen?» Ein Paketname oder eine beliebige über MCP gelieferte Zeichenkette beantwortet diese Frage nicht.

Wenn der Logout beginnt, verwirf jede aktive Freigabe dieser Sitzung. Pausiere sie nicht. Serialisiere sie nicht für die nächste Anmeldung. Erzeuge sie nicht erneut, nur weil nach einem Neustart dieselbe Binärdatei zurückkehrt. Der Entwickler muss den neuen Lauf als neuen Lauf freigeben.

Das gilt auch für Freigabedialoge, die bereits auf dem Bildschirm zu sehen sind. Sie sollten verschwinden oder beim Sitzungswechsel inaktiv werden. Ein verspäteter Klick auf einer alten Karte darf eine inzwischen ungültige Autorisierung nicht wieder aktivieren. Verknüpfe jede Freigabeaufforderung mit einem Ablaufzeitpunkt und derselben Sitzungsgeneration, die auch die Anfragen schützt.

Viele Implementierungen verwischen eine nützliche Unterscheidung:

- Das Entsperren des Tresors erlaubt dem lokalen Gateway, Aktionen überhaupt in Betracht zu ziehen.
- Eine Sitzungsautorisierung erlaubt einem identifizierten Agent-Prozess, Aktionen einzureichen.
- Eine Freigabe pro Verwendung erlaubt genau eine bestimmte Nutzung von Zugangsdaten.

Ein Logout macht alle drei ungültig, aber sie beruhen nicht auf denselben Nachweisen und haben nicht denselben Zeitpunkt. Der Tresor wird sofort geschlossen. Sitzungsfreigaben werden als Gruppe ungültig. Freigaben pro Verwendung scheitern einzeln, weil sich ihre Sitzungsgeneration geändert hat. Wenn du alles in einem Boolean zusammenfasst, wird es schwer nachzuvollziehen, warum ein Aufruf erfolgreich war oder scheiterte.

## Laufende Tools brauchen Abbruch und ehrliche Ungewissheit

Ein Logout sollte Arbeiten stoppen, die die externe Grenze noch nicht überschritten haben, und versuchen, bereits übertragene Arbeiten zu stoppen. Eine Operation, die ein Remote-Dienst bereits angenommen hat, kann es nicht rückgängig machen.

Teile eine Aktion in Zustände mit konkreter operativer Bedeutung auf:

```text
queued -> authorized -> dispatched -> response received
                    \-> cancelled
```

Eine eingereihte Aktion hat den Mac noch nicht verlassen. Entferne sie aus der Warteschlange und melde `cancelled_before_dispatch`. Eine autorisierte Aktion hält möglicherweise nur eine kurzlebige interne Freigabe. Mache diese Freigabe vor dem Versand ungültig und melde `revoked_before_dispatch`, wenn der Worker sie zu spät erreicht.

Eine versendete Aktion ist etwas anderes. Das entfernte System kann sie erhalten haben, selbst wenn der lokale Prozess nie eine Antwort bekommt. Melde sie nicht als abgebrochen, nur weil du eine Socket-Verbindung geschlossen oder einen Helfer beendet hast. Zeichne `logout_during_dispatch` auf, erfasse die Anfragekennung, falls das Protokoll des entfernten Systems eine liefert, und teile dem Benutzer mit, dass das Ergebnis unbekannt bleibt, bis er das entfernte System prüft.

HTTP-Anfragen verdienen besondere Aufmerksamkeit. Das Schließen einer Client-Verbindung kann einen Upload stoppen, bevor der Server ihn liest, oder erst geschehen, nachdem der Server eine Änderung übernommen hat. Idempotenz-Tokens begrenzen den Schaden bei einem späteren erneuten Versuch, machen aus einer unklaren Anfrage aber keine abgebrochene Anfrage. Für Vorgänge, die eine externe Ressource erstellen, sende eine Idempotenzkennung, die die entfernte API tatsächlich unterstützt, und protokolliere diese Kennung, ohne die Zugangsdaten zu speichern.

SSH ist noch weniger eindeutig. Ein Signal an einen lokalen Helfer kann den lokalen Prozess beenden, während der entfernte Befehl in seiner eigenen Prozessgruppe weiterläuft. Wenn du die entfernte Umgebung kontrollierst, führe lange Arbeiten unter einem entfernten Job-Supervisor mit einer eindeutigen Jobkennung und einem Abbruchweg aus. Wenn du sie nicht kontrollierst, schreibe das in den Aktivitätseintrag. Zu behaupten, eine entfernte Migration sei abgebrochen worden, weil sich das lokale Terminal geschlossen hat, verschlimmert einen Vorfall nur.

Lass den Logout nicht unbegrenzt auf das Aufräumen warten. Schließe zuerst die Berechtigung, fordere die Worker zum Abbruch auf, gib der Anwendung ein kurzes, begrenztes Zeitfenster zum Aufräumen und lass das Betriebssystem den Logout abschließen. Die Sicherheitsanforderung lautet: Künftige Nutzung muss verweigert werden. Ein sauberer Programmabschluss ist nur ein Komfort auf Best-Effort-Basis.

## Hintergrundpersistenz verändert das Bedrohungsmodell

Eine benutzerbezogene App, die nach dem Logout weiterarbeitet, ist von einem Desktop-Assistenten zu einem unbeaufsichtigten Dienst geworden. Das kann für ein bewusst eingerichtetes Dienstkonto angemessen sein. Als unbeabsichtigte Nebenwirkung einer Menüleisten-App ist es nicht angemessen.

Vermeide es, nur deshalb einen privilegierten Helfer oder einen Launch-Job in der Systemdomäne zu installieren, damit ein Agent den Logout überlebt. Dieser Schritt ist beliebt, weil lange Jobs dadurch zuverlässig wirken. Gleichzeitig löst er den Aktionspfad von der Person, die ihn freigegeben hat, und erweitert oft den Zugriff über die ursprüngliche Benutzersitzung hinaus.

Wenn ein Team Arbeit nach dem Weggang eines Entwicklers wirklich fortsetzen muss, gib dieser Arbeit ein eigenes Zuhause. Verwende eine eigene Dienstidentität, Zugangsdaten mit eng begrenztem entfernten Umfang und Ablaufzeit, klarer Zuständigkeit, einem Audit-Trail und einem Kündigungsverfahren, das ein anderer Betreiber nutzen kann. Mache die Übergabe sichtbar. Ein lokaler Agent darf diese Rolle nicht stillschweigend übernehmen.

Der schnelle Benutzerwechsel legt dasselbe Problem offen. Benutzer A kann eine grafische Sitzung geöffnet lassen, während sich Benutzer B anmeldet. Benutzer B darf die Agentenberechtigung von Benutzer A weder freigeben noch beobachten können. Binde jede Gateway-Instanz, jede Freigabeaufzeichnung und jede Tresorzugriffsprüfung an den richtigen Benutzer und die richtige grafische Sitzung. Ein systemweiter Daemon, der beide Benutzer beiläufig multiplexed, braucht eine sehr sorgfältige Isolation. Die meisten Desktop-Tools sollten diese Architektur vermeiden.

Ruhezustand ist kein Logout. Ein schlafender Mac kann dieselbe Benutzersitzung fortsetzen. Teams brauchen deshalb eine eigene Entscheidung für Ruhezustand und Bildschirmsperre. Bei sensiblen Zugangsdaten ist es oft sinnvoll, den Tresor beim Sperren des Bildschirms zu schließen. Für weniger sensible lokale Arbeit kann das Gateway den Tresorstatus behalten, aber nach dem Aufwachen eine neue Freigabe verlangen. Welche Richtlinie du auch wählst, bezeichne sie nicht als Logout-Verhalten. Benutzer und Personen, die Vorfälle untersuchen, brauchen präzise Begriffe.

## Logs sollten länger leben als Berechtigungen, aber kein zweiter Geheimnisspeicher werden

Du brauchst eine dauerhafte Aufzeichnung der beendeten Berechtigung, besonders wenn eine Netzwerkaktion den Logout überschneidet. Du brauchst keine zweite Datenbank voller Token, Request-Inhalte oder privater SSH-Schlüssel.

Schreibe Lebenszyklusereignisse als Fakten auf: Sitzung geöffnet, Agent-Prozess freigegeben, Anfrage eingereicht, Nutzung von Zugangsdaten autorisiert, Versand begonnen, Logout erkannt, Freigabe widerrufen, Beendigung des Helfers angefordert und endgültiges Ergebnis. Verwende stabile Kennungen, mit denen ein Betreiber die Ereignisse verbinden kann, und begrenze gleichzeitig die Inhalte des Benutzers. Ein Aktivitätseintrag kann festhalten, dass ein HTTP-Aufruf an einen konfigurierten Endpunkt erfolgreich war, ohne einen Authorization-Header oder einen sensiblen Response-Inhalt zu speichern.

Ein hashverkettetes Audit-Log bietet eine Eigenschaft, die gewöhnlichen Anwendungslogs fehlt: Ein Offline-Prüfer kann entfernte oder veränderte Einträge erkennen. Das ist nach einem umstrittenen Deployment oder einem vermuteten lokalen Angriff hilfreich, macht ein Log aber nicht automatisch wahr. Das Log beweist die Kontinuität der enthaltenen Einträge. Es kann nicht beweisen, dass ein schädlicher Prozess nicht aufgehört hat zu protokollieren, bevor er handelte.

Schreibe das Widerrufsereignis deshalb vor jeder Aufräumarbeit auf Best-Effort-Basis. Wenn die App beim Beenden eines Helfers abstürzt, sollte der Eintrag trotzdem zeigen, dass die lokale Berechtigung beendet wurde und das Ergebnis der Aktion unklar sein kann. Ein Audit-Trail, der nur saubere Abschlüsse aufzeichnet, vermittelt den Betreibern die falsche Vorstellung.

Sallyport führt sowohl sein Sitzungs- als auch sein Aktivitätsjournal aus einem schreibgeschützten, verschlüsselten und hashverketteten Audit-Log. Mit `sp audit verify` kann die Kette offline über dem Chiffretext geprüft werden. So kann ein Team die Kontinuität prüfen, ohne den Tresor nur dafür zu öffnen, um festzustellen, ob der Logout einen Lauf widerrufen hat.

Die nützliche Audit-Frage ist konkret: «Welcher Prozess hatte die Berechtigung, welchen Zugangspfad hat er angefordert und was wusste das Gateway, als der Benutzer gegangen ist?» Ein riesiges Debug-Log beantwortet sie nur selten.

## Teste Race Conditions statt eines sauberen Beendens

Ein Logout-Test muss eine Aktion mit der Grenze überschneiden lassen. Tests, die eine Anwendung erst nach dem Abschluss aller Worker beenden, prüfen lediglich, ob das normale Aufräumen funktioniert.

Beginne mit einem Endpunkt, den du kontrollierst. Er nimmt eine Anfrage an, zeichnet ihren Eingang auf und verzögert anschließend seine Antwort. Reiche über das Agent-Gateway eine Aktion ein und löse den Logout aus, nachdem das Gateway die Aktion als versendet markiert hat, aber bevor die Antwort eintrifft. Vergleiche bei der nächsten Anmeldung den lokalen Audit-Status mit dem Eintrag des Endpunkts. Das erwartete Ergebnis ist nicht immer «abgebrochen». Es ist ein genauer Status wie `logout_during_dispatch` mit einer Anfragekennung, die du untersuchen kannst.

Führe einen eigenen Test für eingereihte Arbeit durch. Halte einen Worker an, nachdem er ein Element aus der Warteschlange genommen hat, aber bevor er den Tresor um eine Aktionsfreigabe bittet. Starte den Logout, setze den Worker fort und prüfe, dass er ein Widerrufsergebnis erhält, statt etwas zu senden. Dieser Test findet den häufigen Fehler, die Autorisierung nur beim Einreihen der Anfrage zu prüfen.

Teste anschließend die unangenehmen Fälle:

- Wechsle zu einem anderen Benutzer, während die ursprüngliche Sitzung geöffnet bleibt.
- Sperre den Bildschirm, wecke den Rechner auf und prüfe die von dir gewählte Richtlinie für diesen Übergang.
- Beende den Agenten sofort, während eine Anfrage auf Freigabe wartet, und starte einen neuen Prozess mit einer wiederverwendeten PID, falls dein Testsystem das ermöglicht.
- Unterbrich das Gateway während des Herunterfahrens und prüfe, ob der Audit-Eintrag weiterhin ungelöste Arbeit ausweist.
- Sende einen SSH-Befehl, der entfernte Arbeit startet, und prüfe anschließend das Verhalten auf der entfernten Seite, statt dem Beendigungsstatus des lokalen Helfers zu vertrauen.

Prüfe unter macOS während der Testeinrichtung die Launch-Domänen, damit du weißt, was du tatsächlich gestartet hast:

```sh
uid="$(id -u)"
launchctl print "gui/$uid" | grep -E "(agent-gateway|your-test-label)"
```

Die Ausgabe hängt vom installierten Job und der macOS-Version ab. Sie sollte aber den passenden Job innerhalb der aktuellen `gui/<uid>`-Domäne zeigen. Wenn dein Testjob stattdessen in einer Systemdomäne erscheint, sagt das Ergebnis des Logouts wenig über das Sitzungsverhalten einer normalen Desktop-Anwendung aus.

Automatisiere nicht zuerst einen echten Logout über das Hauptkonto eines Entwicklers. Verwende ein wegwerfbares lokales Konto, eine wegwerfbare API-Zugangsinformation und einen Endpunkt, an dem du jede Anfrage prüfen kannst. Logout-Tests können ungespeicherte Arbeit zerstören und entfernten Zustand nur teilweise verändern. Das ist kein Grund, sie auszulassen. Es ist ein Grund, sie nicht als Unit-Test zu behandeln.

## Entfernte Zugangsdaten sollten den Schaden eines verspäteten Aufrufs begrenzen

Ein lokaler Widerruf kann nicht rückwirkend ein Bearer-Token widerrufen, das ein entfernter Dienst bereits akzeptiert hat. Das Design entfernter Zugangsdaten begrenzt den Schaden, wenn das Gateway eine Anfrage zu spät entdeckt, eine App abstürzt oder ein Rechner vor dem Logout kompromittiert wird.

Bevorzuge, sofern der Zielservice das unterstützt, entfernte Zugangsdaten mit engen Berechtigungen und kurzer Lebensdauer. Verwende für verschiedene Umgebungen getrennte Zugangsdaten. Ein Agent, der ein Staging-Deployment aktualisieren kann, sollte keine Zugangsdaten erhalten, mit denen er Produktionsdaten löschen kann, nur weil beide Endpunkte denselben API-Anbieter verwenden.

Verwende für SSH ein eigenes entferntes Konto und beschränke dessen Möglichkeiten. Wenn ein Befehl eine länger laufende Aufgabe starten muss, müssen deren Besitz und Abbruch auf der entfernten Seite sichtbar sein. Eine persönliche SSH-Identität mit weitreichendem Shell-Zugriff ist bequem, bis du erklären musst, warum ein Job nach dem Verschwinden seines lokalen Elternprozesses weiterlief.

Übergebe Zugangsdaten nicht als Umgebungsvariablen, Konfigurationstext, Platzhalterersetzungen oder Shell-Argumente an den Agenten. Sobald ein Geheimnis den Aufrufer erreicht, kann ein Logout zwar künftige lokale Aktionen stoppen, aber diese Kopie nicht aus dem Prozessspeicher, der Shell-Historie, Absturzberichten oder einem Transkript verschwinden lassen. Ein Gateway sollte die Zugangsdaten nur in die von ihm ausgeführte Aktion einfügen und das Ergebnis an den Agenten zurückgeben.

Damit erhält der Logout eine klare Aufgabe: den Tresor schließen, aktive Freigaben ungültig machen, veraltete Leases ablehnen, ausstehende Arbeit stoppen und für bereits gesendete Arbeit den unklaren Status protokollieren. Er kann nicht versprechen, das Internet rückgängig zu machen. Er kann aber verhindern, dass der nächste Aufruf die Berechtigung einer Person nutzt, die nicht mehr anwesend ist.

## Die Endbedingung sollte leicht zu erklären sein

Formuliere die Regel so, dass ein müder Entwickler sie während eines Vorfalls verwenden kann: Wenn die macOS-Benutzersitzung endet, darf kein lokaler Agent-Prozess unter der Berechtigung dieses Benutzers eine weitere Aktion mit Zugangsdaten starten.

Alles Weitere folgt daraus. Das Tresortor schließt vor dem Aufräumen. Freigaben sterben mit dem Prozess und der Sitzung, die sie erworben haben. Eine eingereihte Anfrage verliert ihre Lease. Eine versendete Anfrage erhält einen ehrlichen unbekannten Status, bis ein entferntes System das Ergebnis bestätigt. Logs bleiben zur Prüfung verfügbar, Geheimnisse und ausführbare Berechtigungen dagegen nicht.

Wenn ein Produkt nach dem Logout eine Berechtigung braucht, baue einen ausdrücklich unbeaufsichtigten Dienst mit eigener Identität. Schiebe diese Entscheidung nicht in den Shutdown-Pfad einer Desktop-Anwendung.