Autorisierung von Agenten nach dem Mac-Ruhezustand

Ein genehmigter Agent-Prozess sollte seine Autorisierung nicht allein deshalb behalten, weil ein Mac mit denselben noch im Speicher befindlichen Prozessen aufgewacht ist. Ruhezustand, Abschalten des Bildschirms, Bildschirmsperre, Schließen des Deckels und Aufwachen sind unterschiedliche Ereignisse des Betriebssystems. Sie führen jedoch alle zur selben Sicherheitsfrage: War die Person, die diesen Lauf genehmigt hat, weiterhin anwesend und in der Lage einzugreifen?

Behandle diese Frage als Autorisierungsentscheidung, nicht als Detail der Energieverwaltung. Wenn du einem Programmieragenten API- oder SSH-Zugriff überlässt, kann eine veraltete Genehmigung aus einer normalen Kaffeepause, einem Arbeitsweg oder einer Pause über Nacht eine unbeaufsichtigte Verwendung von Zugangsdaten machen. Die Lösung ist kein Labyrinth aus Regeln. Du brauchst ein kleines Zustandsmodell, eine klare Ablaufregel und Tests, die genau die unangenehmen Übergänge erzwingen, die sonst meist übersprungen werden.

Der Ruhezustand ist kein einzelnes Ereignis

macOS unterscheidet zwischen Systemruhezustand und Bildschirmruhezustand. Das ist wichtig, weil ein dunkler Bildschirm nicht beweist, dass dein Agent angehalten wurde. Apple stellt getrennte NSWorkspace-Benachrichtigungen für willSleep, didWake, screensDidSleep und screensDidWake bereit. Die Benachrichtigungen für Ruhezustand und Aufwachen enthalten keine Nutzerdaten, die deiner App den Grund für den Übergang mitteilen.

Ein Laptop kann das Bild dimmen oder abschalten, während ein Build, eine Netzwerkübertragung oder ein lokaler Prozess weiterläuft. Ein Desktop-Mac kann ohne aktiven Bildschirm arbeiten. Ein Notebook, das an Stromversorgung und Peripheriegeräte angeschlossen ist, kann sich anders verhalten als dasselbe Notebook im Akkubetrieb. Aus einem schwarzen Bildschirm kannst du keine Autorisierungsentscheidung ableiten.

Verwende in deinem Design vier getrennte Fakten:

• Bildschirmstatus zeigt, ob der Bildschirm in den Ruhezustand gegangen ist oder wieder aktiv wurde.
• Energiezustand zeigt, ob sich das Gerät auf den Ruhezustand vorbereitet oder daraus aufgewacht ist.
• Status der Benutzeranwesenheit zeigt, ob die Sitzung aktiv, gesperrt, abgemeldet oder zu einem anderen Benutzer gewechselt ist.
• Tresorstatus zeigt, ob Geheimnisse überhaupt verwendet werden dürfen.

Teams fassen die ersten drei Punkte oft in einem Boolean namens isAwake zusammen. Diese Abkürzung kann Autorisierung durchsickern lassen. Ein Agent kann laufen, während der Bildschirm ruht. Ein Gerät kann zu einem Sperrbildschirm aufwachen. Ein Benutzer kann den Bildschirm sperren, ohne das System in den Ruhezustand zu versetzen. Jeder Fall braucht ein eigenes erwartetes Ergebnis.

Die richtige Standardeinstellung ist streng, aber leicht zu erklären: Für eine geschützte Aktion braucht es einen entsperrten Tresor und eine aktuelle Genehmigung, die zur aktuellen Autorisierungsepoche gehört. Ein Aufwachen, eine Sperre, ein Wechsel der Benutzersitzung, ein manueller Widerruf oder das Sperren des Tresors kann diese Epoche erhöhen. Sobald das geschieht, schlagen Aufrufe aus der alten Epoche fehl.

Die Bildschirmsperre sollte die interaktive Autorisierung beenden

Eine Bildschirmsperre ist das deutlichste Signal dafür, dass die interaktive Genehmigung enden sollte. Der Mac kann weiterlaufen, und ein langlebiger Terminalprozess kann weiterhin seine Sockets und seinen Speicher haben. Die genehmigende Person hat die interaktive Sitzung jedoch verlassen. Weitere API-Anfragen oder SSH-Befehle unter einem früheren Klick lassen sich nur schwer rechtfertigen.

Das bedeutet nicht, dass jeder Agent bei einer Sperre beendet werden muss. Lokale Berechnungen zu beenden ist eine separate Entscheidung. Ein Modell kann weiterhin ein Repository lesen, Code kompilieren oder einen Patch vorbereiten, wenn diese Aktionen kein Gateway mit Zugangsdaten benötigen. Die Grenze ist die externe Aktion. Lass die Arbeit bestehen und entziehe die Autorisierung.

Diese Unterscheidung ist nützlich, weil sie eine Entscheidung zwischen zwei Extremen vermeidet. Du musst dich nicht zwischen einem eingefrorenen und einem völlig ungeschützten Agenten entscheiden. Lass den Agenten Aufgaben in seinem lokalen Arbeitsbereich fortsetzen, die sicher sind. Der nächste geschützte Aufruf sollte dann eine klare Ablehnung zurückgeben:

authorization_denied
reason: authority_epoch_changed
required: unlock_vault_and_approve_session

Eine hilfreiche Ablehnung teilt dem Agenten mit, was passiert ist, ohne ein Geheimnis preiszugeben oder so zu tun, als sei die Anfrage wegen eines Netzwerkfehlers fehlgeschlagen. Der Agent kann pausieren, die Blockade protokollieren und auf die Person warten, statt wiederholt denselben zerstörerischen Befehl zu versuchen.

Mache keine Ausnahme, nur weil die Sperre durch einen Inaktivitätstimer ausgelöst wurde. Genau dann hat die Person den laufenden Agenten oft vergessen. Eine explizite und eine automatische Sperre spiegeln zwar unterschiedliche menschliche Absichten wider, doch keine von beiden beweist, dass die Person weiterhin für eine Produktionsänderung zur Verfügung steht.

Es gibt einen engen Anwendungsfall, in dem eine Autorisierung über eine Sperre hinweg bestehen bleiben kann: ein bewusst unbeaufsichtigter Job mit einer separat erteilten, stark begrenzten Fähigkeit. Das sollte ein eigener Lauf-Typ sein und keine versteckte Ausnahme von der interaktiven Genehmigung. Wenn deine Automatisierung über Nacht genau wie ein tagsüber chatgesteuerter Agent arbeitet, hast du die Risiken nicht getrennt.

Ein Aufwachereignis beginnt eine neue Autorisierungsepoche

Das Aufwachen sollte eine interaktive Genehmigung ungültig machen, selbst wenn der genehmigte Prozess weiterläuft. Ein Prozess kann vor dem Ruhezustand pausieren und danach mit derselben PID, denselben Umgebungsvariablen und denselben offenen Dateideskriptoren fortfahren. Nichts davon beweist, dass die frühere menschliche Entscheidung weiterhin gilt.

Eine Autorisierungsepoche ist ein monoton steigender Wert, der einen zusammenhängenden Zeitraum markiert, in dem eine Genehmigung gültig sein kann. Wenn das System eine für dich relevante Grenze überschreitet, erhöhe die Epoche, bevor du eine weitere Aktion ausführst. Der Prozess handelt das nicht aus. Er erkennt die Änderung bei seiner nächsten Anfrage.

Ein minimaler Autorisierungsdatensatz kann so aussehen:

{
  "session_nonce": "6a018d62-2e94-4d4a-9e79-1f4e4b5ca501",
  "process_id": 84172,
  "process_start_marker": "2026-07-22T14:03:18Z",
  "signing_authority": "approved-agent-binary",
  "authority_epoch": 27,
  "approved_at": "2026-07-22T14:04:01Z",
  "per_call_approval": false
}

Die Prozess-ID ist nur ein Feld. macOS kann eine PID nach dem Ende eines Prozesses wiederverwenden. Eine bloße PID wird deshalb gefährlich, wenn das Gateway einen alten Eintrag vergisst und die Nummer später erneut sieht. Verknüpfe die Genehmigung mit einer neuen Nonce und einer beobachteten Prozessinstanz. Verwende die Codesignatur als Identitätssignal für die ausführbare Datei und verlange trotzdem für jeden neuen Prozesslauf eine neue Sitzungsgenehmigung.

Wenn dein Ereignishandler willSleep sieht, protokolliere die bevorstehende Aufhebung und nimm sofort keine neuen geschützten Aufrufe mehr an. Apple zufolge kann ein Beobachter die Verarbeitung des Ruhezustands um bis zu 30 Sekunden verzögern. Nutze diese Zeit jedoch nicht, um eine Warteschlange ausstehender Aktionen abzuarbeiten. Verweigere sie oder markiere sie als unterbrochen. Die Person hat keinen letzten Arbeitsschub genehmigt, während der Deckel geschlossen wurde.

Wenn das Gerät das Aufwachen meldet, erhöhe die Epoche erneut, falls nötig, und halte das Tresortor geschlossen, bis die Person die Entsperranforderung erfüllt. So werden auch fehlerhafte Reihenfolgen der Ereignisse abgedeckt. Energieereignisse sind an ihren Grenzen unübersichtlich. Eine zusätzliche harmlose Genehmigung ist besser als ein Aufruf mit Geheimnissen, der während eines Übergangs durchrutscht.

Das Schließen des Deckels verdient einen eigenen Testfall

Für Menschen fühlt sich das Schließen eines Notebookdeckels wie ein Ruhezustandsbefehl an. Software sollte jedoch nicht davon ausgehen, dass diese physische Geste sauber einem einzigen Ereignis des Betriebssystems entspricht. Stromquelle, externe Bildschirme, Docking-Zubehör und Einstellungen können das Verhalten des Geräts verändern. Die einzige ehrliche Antwort ist, die Hardware und Konfiguration zu testen, die dein Team tatsächlich verwendet.

Die Sicherheitsrichtlinie kann trotzdem einfach bleiben: Das Schließen des Deckels beendet die interaktive Autorisierung, sobald du eine verlässliche zugehörige Grenze beobachtest. Bei einer normalen mobilen Konfiguration bietet willSleep die früheste Gelegenheit, neue Aktionen zu blockieren. Wenn eine bestimmte Konfiguration das System nach dem Schließen des Deckels aktiv hält, verwende eine Benutzer- oder Bildschirmgrenze als konservative Rückfallebene. Warte nicht auf eine perfekte semantische Bezeichnung wie lidClosed. Du musst die unbeaufsichtigte Verwendung von Zugangsdaten verhindern.

Führe diesen Versuch mit einem Agenten durch, der eine harmlose Fähigkeit mit Zugangsdaten besitzt, etwa das Schreiben einer Markierung an eine Test-API oder das Ausführen eines ungefährlichen Befehls auf einem wegwerfbaren SSH-Host:

1. Starte einen neuen Agent-Prozess und genehmige seine Sitzung.
2. Bestätige, dass ein geschützter Aufruf erfolgreich ist, und lasse den Agenten dann für einen weiteren Aufruf bereit.
3. Schließe den Deckel lange genug, damit das erwartete Energieverhalten ausgelöst wird, und öffne ihn anschließend wieder.
4. Lasse den Agenten den geschützten Aufruf ohne erneutes Entsperren oder Genehmigen wiederholen.
5. Bestätige, dass das Gateway den Wiederholungsversuch verweigert und den Autorisierungsübergang vor der Ablehnung protokolliert.

Wiederhole denselben Versuch im Dockingbetrieb, im Akkubetrieb und mit einem externen Bildschirm, wenn diese Modi verwendet werden. Halte den Testendpunkt harmlos. Ziel ist es, das Verhalten der Autorisierung zu beobachten, nicht herauszufinden, ob sich eine Produktionsbereitstellung mitten im Ablauf unterbrechen lässt.

Ein Fehler sieht hier oft täuschend sauber aus: Im Aktionsprotokoll ist während des Ruhezustands kein Aufruf zu sehen, und der erste Aufruf nach dem Aufwachen ist erfolgreich. Das ist trotzdem ein Fehler, wenn die Person einen Sperrbildschirm sah und den fortgesetzten Lauf nie genehmigt hat. Genau diese Zeitlücke ist der Zweck des Tests.

Der Bildschirmruhezustand allein ist ein schlechter Auslöser für einen Widerruf

Ein Widerruf allein beim Bildschirmruhezustand ist sicher, kann auf einem Desktop-Mac jedoch zu störend sein, wenn der Bildschirm während normaler Arbeit ruht. Die Autorisierung während des Bildschirmruhezustands beizubehalten ist bequem, aber leicht falsch umzusetzen, wenn ein Bildschirm-Timeout zugleich als Signal für einen unbeaufsichtigten Benutzer dient.

Lege eine Regel fest und mache den Zielkonflikt ausdrücklich. Bei Zugangsdaten mit hohem Einfluss solltest du bei Bildschirmsperre und Systemruhezustand widerrufen, nicht erst beim Bildschirmruhezustand. Auf einem Gerät, bei dem der Bildschirm zuverlässig kurz vor der Sperre ruht, kannst du den Widerruf bereits beim Bildschirmruhezustand auslösen und damit einen zusätzlichen Schutz schaffen. Akzeptiere dann mehr Genehmigungsabfragen. Nenne keine der beiden Entscheidungen «offensichtlich». Sie hängt vom Einsatz und von den Möglichkeiten der Zugangsdaten ab.

Apples getrennte Benachrichtigungen für Bildschirm und System erinnern daran, dass beide nicht dasselbe bedeuten. Überwache beide, protokolliere beide und teste die Richtlinie, die du jeweils daran knüpfst.

Eine praktische Matrix verhindert, dass sich daraus bloße Überlieferungen entwickeln:

Die Person entsperrt den Mac, um wieder zum Schreibtisch zu gelangen. Dadurch sollte nicht stillschweigend die frühere Autorisierung eines Agenten wiederhergestellt werden. Das Entsperren eines Computers und die Genehmigung einer externen Aktion hängen zusammen, beantworten aber unterschiedliche Fragen.

Läufe über Nacht brauchen einen eigenen Vertrag

Ein Agent-Lauf über Nacht sollte nicht die Berechtigungen einer interaktiven Nachmittagssitzung übernehmen. Bei interaktiver Arbeit genehmigen Menschen etwas, während sie den Diff, das Terminal oder eine Anfragekarte sehen. Arbeit über Nacht ist die ausdrückliche Entscheidung, etwas ohne diese unmittelbare Aufsicht fortzusetzen.

Formuliere den Vertrag des Jobs so eng, dass du ihn in einem Satz erklären kannst. «Tests ausführen und einen Pull Request vorbereiten» ist verständlich. «Alles Nötige tun, um die Aufgabe abzuschließen» ist kein Vertrag, sondern ein Blankoscheck.

Trenne bei unbeaufsichtigter Arbeit lokale von externen Aktionen. Erlaube lokale Aktionen, wenn sie begrenzt bleiben: Repository-Analyse, Änderungen an einem Branch, Testausführung und Erstellung von Artefakten. Für sensible externe Auswirkungen ist eine neue menschliche Genehmigung erforderlich, etwa für eine Änderung an einer Produktions-API, ein Deployment, die Veröffentlichung eines Pakets, einen Schreibzugriff auf eine gemeinsam genutzte Datenbank oder SSH-Zugriff auf einen wichtigen Rechner.

Manchmal muss ein Lauf über Nacht einen externen Dienst aufrufen. Verwende dafür eine eigene Zugangsinformation oder eine Testumgebung, deren Schadensradius zum Job passt. Nutze keine Administrator-Zugangsdaten, nur weil sie bereits im Tresor liegen. Das verbreitete Argument lautet, die Person habe den Agenten am Abend bereits genehmigt. Diese Genehmigung galt einem sichtbaren, interaktiven Lauf. Sie gilt nicht für das, was nach dem Einschlafen noch übrig ist.

Verwende ein begrenztes Aktionsbudget, wenn der Job eine legitime, wiederkehrende externe Aufgabe hat. Begrenze es nach Ziel, Methode und Wirkung statt anhand vager Vertrauenswerten. Ein unbeaufsichtigter Testjob darf beispielsweise eine festgelegte Anfrage an genau einen Staging-Endpunkt senden, aber keine Hosts wechseln, HTTP-Methoden ändern oder SSH verwenden. Wenn der Job mehr braucht, wartet er.

Sallyports sitzungsbezogene Autorisierung gibt jedem neuen Agent-Prozess eine eigene Genehmigungsgrenze. Führe Arbeiten über Nacht in einem neu gestarteten Prozess aus und unterziehe seine geschützten Aktionen derselben Prüfung wie jeden anderen unbeaufsichtigten Lauf.

Protokolle müssen die Verweigerung beweisen, nicht nur Aktivität

Ein Eintrag wie «Der Mac ist aufgewacht» beweist nicht, dass die Autorisierung beendet wurde. Du brauchst Belege von beiden Seiten der Grenze: das Ereignis des Betriebssystems, das den Richtlinienübergang ausgelöst hat, und die nächste geschützte Aktion, die das Gateway verweigert hat.

macOS liefert einen nützlichen Ausgangspunkt für die Untersuchung der Energieereignisse:

pmset -g log | grep -E 'Sleep|Wake|DarkWake|Display'

Die genauen Zeilen unterscheiden sich je nach Hardware und macOS-Version. Die Ausgabe sollte jedoch Zeitstempel und Ereignisnamen wie Sleep, Wake, DarkWake oder Bildschirmübergänge zeigen. Speichere bei jedem Versuch das passende Zeitfenster. Verwende diese Ausgabe nicht als Quelle der Wahrheit für die Autorisierung, da sie weder deinen Tresor noch deine Agent-Identität kennt.

Dein eigenes Journal sollte andere Fragen beantworten:

14:20:16.402 session_approved process=84172 epoch=27 authority=approved-agent-binary
14:22:04.118 power_will_sleep epoch=27
14:22:04.119 authority_revoked old_epoch=27 new_epoch=28 reason=system_sleep
14:25:38.771 power_did_wake epoch=28
14:25:44.025 action_denied process=84172 request=ssh.exec reason=authority_epoch_changed

Die Reihenfolge ist wichtig. Wenn die Aktion vor dem Widerrufseintrag erscheint, hast du eine Race Condition gefunden. Wenn kein verweigerter Aufruf erscheint, weil dein Testagent still beendet wurde, hast du nichts über einen dauerhaften Prozess bewiesen. Richte den Versuch so ein, dass derselbe langfristig laufende Prozess nach jedem Übergang einen geschützten Aufruf versucht.

Ein manipulationssicherer Prüfpfad bietet einen zweiten Vorteil: Du kannst später überprüfen, dass die Abfolge von Ereignissen und Aktionen nicht nachträglich zu einer schöneren Geschichte verändert wurde. Sallyport erzeugt seine Sitzungs- und Aktivitätsjournale aus einem schreibgeschützten, verschlüsselten und hashverketteten Audit-Log. sp audit verify prüft diese Kette offline über dem Chiffretext. Das ist für diesen Test nützlich, weil eine erfolgreiche Prüfung bestätigt, dass die aufgezeichnete Abfolge nicht unbemerkt umgeschrieben wurde. Sie entschuldigt jedoch keine schwache Widerrufsrichtlinie.

Race Conditions entstehen an der Grenze

Der gefährliche Fehler ist meist eine Anfrage, die bereits läuft, wenn der Mac in den Ruhezustand wechselt oder die Person den Bildschirm sperrt. Ein Gateway, das die Genehmigung nur beim Akzeptieren einer Verbindung prüft, kann eingereihtem Arbeiten erlauben, nach dem Autorisierungsübergang ausgeführt zu werden. Ein Gateway, das erst prüft, nachdem es eine Zugangsinformation eingefügt hat, kann diese an einen Helfer weitergeben, bevor es den Widerruf bemerkt.

Prüfe die Autorisierung unmittelbar vor der privilegierten Aktion. Das bedeutet: vor dem Einfügen von Zugangsdaten, vor dem Öffnen eines SSH-Helfers mit einem verwendbaren Schlüssel und vor dem Senden der HTTP-Anfrage. Wenn eine Aktion mehrere privilegierte Phasen hat, prüfe an jeder Phase erneut, an der das System sonst eine Autorisierungsgrenze überschreiten könnte.

Eine einfache Struktur sieht so aus:

receive request
identify process and session nonce
read current authority epoch
compare request grant epoch to current epoch
check vault gate
check per-call approval when required
inject credential and execute action
append result to audit log

Halte das Lesen der Epoche und die Verpflichtung zur privilegierten Ausführung so eng zusammen, wie es deine Implementierung erlaubt. Sobald Bytes den Mac verlassen, kannst du eine verteilte HTTP-Aktion nicht mehr vollständig rückgängig machen. Du kannst jedoch verhindern, dass eine veraltete Genehmigung sie startet.

Versuche nicht, jeden Sonderfall durch eine Verzögerung des Ruhezustands zu lösen. Apples willSleep-Benachrichtigung erlaubt eine kurze Verzögerung für die Verarbeitung. Einen Laptop am Einschlafen zu hindern, damit Agent-Aktionen beendet werden können, stellt die Prioritäten jedoch auf den Kopf. Das Gerät verlässt einen interaktiven Zustand. Widerrufe den Zugriff, protokolliere die Unterbrechung und überlasse der Person die Entscheidung, was fortgesetzt wird.

Eine Genehmigung pro Aufruf ist die klare Lösung für Schlüssel, die teure oder unumkehrbare Auswirkungen haben können. Dadurch werden Ruhezustand und Aufwachen weniger problematisch, weil jede Verwendung ohnehin im Moment der Nutzung die Person fragt. Das ist kein Grund, auf den Widerruf der Sitzung zu verzichten. Es ist eine zweite Schranke für eine kleinere Gruppe von Zugangsdaten.

Teste die Übergänge, die Menschen tatsächlich ausführen

Ein guter Testplan beginnt nicht mit Unit-Tests für einen Benachrichtigungshandler. Solche Tests helfen, aber die Fehler liegen in echten Energieübergängen, echten Sperrbildschirmen und Agent-Prozessen, die ein Terminalfenster überdauern.

Baue einen Testagenten, der warten, ein Signal empfangen und anschließend eine harmlose geschützte Aktion anfordern kann. Gib jedem Versuch eine neue Lauf-ID. Halte vor dem Test eine schriftliche Erwartung fest. Sonst wird ein überraschendes Ergebnis im Nachhinein schnell zu «Wird schon passen».

Teste mindestens diese Fälle auf jeder unterstützten Mac-Konfiguration:

• Sperre den Bildschirm, während der Agent untätig ist, und wiederhole eine genehmigte Aktion vor und nach dem Entsperren.
• Versetze das System über das Apple-Menü in den Ruhezustand, wecke es am Sperrbildschirm auf und wiederhole den Aufruf mit dem ursprünglichen Prozess.
• Lass den Bildschirm ruhen, während das System aktiv bleibt, und prüfe, ob das Verhalten deiner gewählten Bildschirmrichtlinie entspricht.
• Schließe und öffne den Deckel eines Notebooks, sowohl im Akkubetrieb als auch in der üblichen Schreibtischkonfiguration.
• Lass einen bewusst langen Agent-Lauf über Nacht laufen und prüfe anschließend das Energieprotokoll, das Aktionsjournal und den ersten geschützten Aufruf nach der Rückkehr.

Verwende für jeden Lauf ein kleines Ergebnisblatt: erwartete Epoche, beobachtete Energieereignisse, Überleben des ursprünglichen Prozesses, Sperrstatus des Tresors und Ergebnis des ersten geschützten Aufrufs. Dieses Blatt deckt einen häufigen Fehler auf: Teams prüfen, ob die App das Ereignis gesehen hat, testen aber nie, ob die Aktionsschicht danach einen Aufruf zurückweist.

Teste auch ungünstige Zeitpunkte. Starte eine geschützte Aktion, sperre den Bildschirm, während sie auf eine Netzwerkantwort wartet, und prüfe, ob ein Wiederholungs- oder Folgeaufruf unter der alten Genehmigung läuft. Starte eine Aktion einen Sekundenbruchteil vor dem Ruhezustand. Trenne ein Dock und verbinde es wieder. Starte den Agent-Prozess nach dem Aufwachen neu und stelle sicher, dass er den Genehmigungseintrag des alten Prozesses nicht übernehmen kann.

Du brauchst keine riesige Richtlinien-Engine, damit diese Tests bestehen. Du brauchst ein strenges Tresortor, einen Genehmigungseintrag pro Prozess, eine widerrufbare Epoche und einen Aktionspfad, der all das unmittelbar vor der Verwendung einer Zugangsinformation prüft.

Formuliere die Richtlinie anhand von Ergebnissen und setze sie anschließend durch

Eine gute Autorisierungsrichtlinie passt auf eine Seite, weil sie beobachtbare Ergebnisse beschreibt und keine Sammlung vermuteter Bezeichnungen des Betriebssystems. Lege fest, was nach Sperre, Ruhezustand, Aufwachen, Schließen des Deckels, Abmeldung und manuellem Widerruf mit geschützten Aktionen geschieht. Lege fest, ob lokale Arbeit fortgesetzt werden darf. Lege fest, was die Person tun muss, um fortzufahren.

Für die meisten interaktiven KI-Programmieragenten sollte die Richtlinie so lauten:

Eine geschützte Aktion erfordert einen entsperrten Tresor und eine Genehmigung für den aktuellen Prozess in der aktuellen Autorisierungsepoche. Sperre, Ruhezustand, Verlust der Benutzersitzung, Sperren des Tresors und manueller Widerruf beenden diese Genehmigung. Aufwachen und Entsperren stellen sie nicht wieder her. Der Agent muss vor der nächsten geschützten Aktion eine neue Genehmigung anfordern.

Diese Regel hat einen Preis: Nach der Rückkehr an einen Mac müssen Menschen erneut genehmigen. Akzeptiere diesen Preis. Die Alternative verlangt von einer Person, sich an jeden Agent-Prozess zu erinnern, der vor dem Schließen des Deckels aktiv war, und darauf zu vertrauen, dass er sich Stunden später beim Aufwachen vernünftig verhält.

Führe die Tests durch, bevor du eine Agent-Konfiguration als sicher für unbeaufsichtigte Arbeit bezeichnest. Wenn eine Anfrage nach einer Sperre oder einem Aufwachen ohne eine neue Entscheidung der Person erfolgreich ist, hast du eine Autorisierung gefunden, die länger bestand als der Moment, in dem sie erteilt wurde.