Agent-Berechtigung nach dem Neustart: Berechtigungen, die ablaufen

Ein Neustart des Mac schafft eine klare technische Grenze. Nutzen Sie sie. Ein Agent-Prozess endet, sein Speicher verschwindet, und jede Genehmigung, die sich auf genau diesen Lauf bezog, sollte ebenfalls enden. Wer autonome Arbeit nach einem Neustart unsichtbar fortsetzen will, macht aus einer engen, überprüfbaren Berechtigung meist einen dauerhaften Zugriff mit unklarer Ablaufregel.

Das bedeutet nicht, dass ein Neustart alles löschen sollte. Teams brauchen Belege für frühere Aktionen, verschlüsselte Zugangsdaten für künftige Arbeit und genügend Aufgabenkontext, um bewusst fortzusetzen. Die Regel ist einfach: Aufzeichnungen und geschützte Materialien bleiben erhalten, aktive Berechtigungen werden verworfen. Danach muss eine Person den neu gestarteten Prozess genehmigen, bevor er mit der Außenwelt spricht.

Agent-Berechtigung nach einem Neustart beginnt mit einer leeren Laufzeitumgebung

Nach einem Neustart sollte es keine aktiven Prozessberechtigungen, keinen entsperrten Tresor, kein geerbtes Sitzungsgeheimnis und keine gespeicherte Genehmigung geben, die ein neuer Prozess verwenden kann. Ein Neustart beendet das Objekt, das die Genehmigung erhalten hat. Den Ersatzprozess als gleichwertig zu behandeln, nur weil er dasselbe Checkout, denselben Befehl oder denselben Agent-Namen verwendet, ist ein Identitätsfehler.

Oft heißt es, das verursache nach einem Betriebssystem-Update oder Stromausfall zu viel Reibung. Es gibt tatsächlich eine bewusste Pause. Sie zwingt jemanden, den Prozess zu prüfen, der jetzt Zugriff verlangt, statt den Prozess, den man Stunden zuvor unter anderen Bedingungen genehmigt hat.

Eine saubere Neustartgrenze hat vier nützliche Eigenschaften:

• Sie löscht flüchtige Daten wie Zugriffstokens im Speicher, entschlüsselte Schlüssel-Handles, ausstehende Bestätigungen und Prozesskennungen.
• Sie verhindert, dass ein Agent eine Genehmigung über eine unbeaufsichtigte Zeit hinweg mitnimmt, in der die verantwortliche Person möglicherweise nicht mehr anwesend ist.
• Sie liefert einen verlässlichen Audit-Marker, mit dem sich feststellen lässt, ob eine Aktion vor oder nach dem Neustart stattfand.
• Sie macht versteckte Abhängigkeiten von lokalen Caches, Hintergrundhelfern und Verbindungs-Multiplexern sichtbar.

Verwechseln Sie einen Neustart nicht mit der Abmeldung eines Benutzers. Auch eine Abmeldung sollte die Agent-Berechtigung beenden. Ein Neustart lässt sich jedoch leichter testen, weil er fast jeden normalen Prozess beendet. Überlebt eine Berechtigung ihn, wurde sie entweder bewusst gespeichert oder durch einen Helfer außerhalb des Agent-Lebenszyklus am Leben gehalten. Beides verdient eine Prüfung.

Die Regel gilt auch, wenn die Agent-Binärdatei signiert und unverändert ist. Codesignierung kann dem Betreiber helfen, den Herausgeber des Programms zu erkennen. Sie beweist nicht, dass der laufende Prozess dieselben Anweisungen, Umgebungsvariablen, Repository-Daten, Werkzeugeinstellungen oder dieselbe Absicht des Betreibers hat wie der vorherige Lauf. Ein signierter Prozess kann nach einem Neustart trotzdem einen gefährlichen Prompt erhalten.

Dasselbe gilt für eine geplante Aufgabe. Angenommen, ein Agent hat eine Datenbankmigration vorbereitet und eine Genehmigung angefordert, bevor der Mac neu gestartet wurde. Der Plan darf in einem Arbeitsverzeichnis erhalten bleiben. Die Berechtigung zur Ausführung darf es nicht. Nach dem Neustart sollte der Agent die geplante Aktion erneut anzeigen, damit die verantwortliche Person entscheiden kann, ob sie weiterhin richtig ist.

Hier werden viele Designs nachlässig. Sie speichern einen dauerhaften Eintrag mit dem Status «genehmigt» und nennen ihn eine Sitzung. Dieser Eintrag wird zu einer übertragbaren Berechtigung, weil ein späterer Prozess ihn für sich beanspruchen kann. Eine Sitzungsberechtigung braucht eine aktive Bindung an eine Prozessinstanz und eine kurze, eindeutige Lebensdauer. Sobald der Prozess endet, sollte der Eintrag zeigen, dass die Berechtigung beendet wurde, statt zur Wiederverwendung bereitzustehen.

Belege und Konfiguration behalten, aktive Berechtigungen verwerfen

Ein Team sollte Fakten zur Erklärung der Arbeit und sicher wiederverwendbare Konfigurationen bewahren. Jedes Objekt, das unmittelbare Berechtigung verleiht, sollte dagegen gelöscht oder ungültig gemacht werden. Legen Sie diese Kategorien in getrennten Speicher- und Lebenszyklusbereichen ab. Werden sie vermischt, wird ein Audit-Eintrag leicht versehentlich zu einem Berechtigungstoken.

In der Praxis funktioniert folgende Trennung gut:

Die erste Spalte ermöglicht Kontinuität. Die zweite verhindert, dass Kontinuität zu stiller Privilegienbewahrung wird.

Bewahren Sie den Status unterbrochener Arbeit auf, formulieren Sie ihn aber beschreibend. Ein guter Eintrag sagt, dass Lauf R-1842 einen SSH-Befehl angefordert und genehmigt bekommen hatte, jedoch vor der Ausführung stoppte, weil der Host neu gestartet wurde. Ein schlechter Eintrag sagt, dass Lauf R-1842 seine verbleibenden Aktionen nach dem nächsten Start ausführen darf. Der erste Eintrag ermöglicht eine Entscheidung. Der zweite trifft sie im Voraus, ohne zu wissen, wie der spätere Prozess aussehen wird.

Auch bei der Speicherung von Zugangsdaten ist präzise Sprache wichtig. Ein verschlüsselter API-Schlüssel darf in einem Tresor über den Neustart hinweg erhalten bleiben. Seine entschlüsselte Form darf nicht verfügbar bleiben, nur weil der Rechner schnell neu gestartet wurde. Das Sperren des Tresors schafft einen klaren Punkt, an dem die Person am Mac ihre Anwesenheit erneut bestätigt. Das ist eine andere Entscheidung als die Frage, ob ein Agent-Prozess bestimmte Zugangsdaten verwenden darf.

Sallyport folgt dieser Trennung: Die Tresorsperre blockiert jede Aktion, solange der Tresor gesperrt ist. Die sitzungsbezogene Genehmigung gilt für einen neu verbundenen Agent-Prozess und nicht für eine gespeicherte Aufgabenbezeichnung. Das sind zwei verschiedene Entscheidungen. Wer sie zusammenlegt, erschwert die Untersuchung von Vorfällen erheblich.

Speichern Sie Genehmigungen nicht versteckt in Komfortfunktionen. Einige Beispiele wirken harmlos, bis sie sich summieren:

• Ein Launch-Agent startet einen MCP-Client neu und übergibt ihm die alte Sitzungsdatei.
• Ein SSH-Client behält einen Control-Socket unter /tmp oder in einem Benutzer-Cache.
• Ein Skript kopiert ein Bearer-Token in eine Umgebungsdatei, damit Wiederholungen nach dem Neustart funktionieren.
• Ein Task-Runner sieht einen unvollständigen Job und führt ihn aus, bevor geprüft wird, ob sich das Ziel geändert hat.

Jede dieser Funktionen soll Fortschritt bewahren. Jede kann aber auch Berechtigungen erhalten, ohne der verantwortlichen Person zu zeigen, wer oder was sie jetzt besitzt.

Verwenden Sie stattdessen einen Unterbrechungseintrag. Er sollte eine Aufgabenreferenz, die alte Laufkennung, einen Digest der vorgesehenen Aktionsliste, Zielnamen und einen Status wie stopped_by_reboot enthalten. Er darf keine verwendbaren Zugangsdaten, Cookies, Genehmigungstokens oder Anweisungen enthalten, die ein Launcher ausführen kann. Beim nächsten Lauf zeigt man den Eintrag einer Person als Kontext. Kontext hilft bei der Prüfung. Berechtigung entsteht durch eine neue Entscheidung.

Ein Neustart ist kein Ereignis zur Rotation von Zugangsdaten

Ein Neustart sollte Agent-Berechtigungen ablaufen lassen, aber nicht automatisch API- oder SSH-Schlüssel rotieren. Diese Kontrollen behandeln unterschiedliche Fehlerarten. Das Ablaufen einer Berechtigung begrenzt, wer vorhandene Zugangsdaten wie lange verwenden darf. Rotation ersetzt die Zugangsdaten, weil eine Offenlegung, ein Verlust, Missbrauch oder ein veränderter Zugriffsbedarf vermutet wird.

Teams verlieren Zeit und beschädigen Integrationen, wenn sie jeden Neustart als Offenlegungsereignis behandeln. Eine routinemäßige Rotation kann außerdem ein falsches Sicherheitsgefühl erzeugen, wenn ein geleaktes Geheimnis dadurch verdeckt wird, ohne die Austrittsstelle zu finden. Die Rotation eines Schlüssels repariert kein Design, das den Schlüssel einem Agent übergeben, in ein Transkript geschrieben oder in der Shell-Historie abgelegt hat.

NIST Special Publication 800-63B trennt Sitzungsverwaltung und Lebenszyklus von Authentifikatoren. Sitzungsende und erneute Authentifizierung sind dort ausdrückliche Kontrollen, während der Ersatz eines Authentifikators ein anderes Problem behandelt. Diese Unterscheidung passt gut zu Agent-Systemen. Beenden Sie den aktiven Agent-Lauf beim Neustart. Rotieren Sie die zugrunde liegenden Zugangsdaten nur, wenn Belege oder Richtlinien dies verlangen.

Rotieren Sie nach einem Neustart, wenn der Neustart selbst auf ein glaubwürdiges Offenlegungsereignis folgte. Beispiele sind ein Geheimnis in einem Prompt-Protokoll, ein unbekannter Prozess mit Zugriff auf die Agent-Umgebung, ein verlorener Laptop oder ein ehemaliges Teammitglied mit einer kopierten Zugangsdaten. In solchen Fällen ist der Neustart nebensächlich. Der vermutete Austritt löst die Rotation aus.

Langlebige Bearer-Zugangsdaten verdienen besondere Aufmerksamkeit, weil sie überall funktionieren können, wo das Netzwerk den Zugriff erlaubt. Wenn ein Agent ihren Klartext erhält, ist die saubere Grenze, die den Ablauf beim Neustart sinnvoll macht, bereits verloren. Der Agent kann den Wert vor dem Neustart speichern oder übertragen. Eine spätere Sitzungsfreigabe kann ihn nicht zurückholen.

SSH hat eigene Fallen. Ein privater Schlüssel kann sicher in einem lokalen Tresor liegen, während eine bestehende SSH-Verbindung weiterhin entfernte Kanäle ausführt. SSH-Multiplexing kann außerdem einen lokalen Control-Socket hinterlassen, den ein späterer Client nutzt. Ein Neustart sollte beides normalerweise beseitigen, aber verlassen Sie sich nicht auf Annahmen. Testen Sie die tatsächlichen Client-Optionen und das Verhalten der eingesetzten Helfer.

Die praktische Richtlinie lautet: Verschlüsselte Ausgangszugangsdaten behalten, sie beim Neustart sperren, alle Berechtigungen und aktiven Transporte beenden und eine neue Prozessgenehmigung verlangen, bevor das Gateway wieder Zugangsdaten verwendet. Rotationsauslöser sollten sich an Offenlegung und Personaländerungen orientieren, nicht an einem beliebigen Startvorgang.

Das hält auch die Reaktion auf Vorfälle ehrlich. Wenn jemand sagt: «Wir haben neu gestartet, also wurde der Zugriff zurückgesetzt», fragen Sie, ob die Zugangsdaten jemals den geschützten Speicher verlassen haben und ob der entfernte Anbieter eigene Sitzungen führt. Ein Neustart setzt den lokalen Laufzeitstatus zurück. Er macht ein Token beim Cloud-Anbieter nicht ungültig, solange dieser keine Widerrufs- oder Rotationsaktion erhält.

Geräteentsperrung, menschliche Anwesenheit und Prozessgenehmigung sind verschiedene Fakten

Eine sichere Fortsetzung braucht getrennte Antworten auf drei Fragen: Darf der Mac auf geschützte Zugangsdaten zugreifen, ist eine verantwortliche Person anwesend, und welcher Prozess möchte sie verwenden? Ein Design, das alle drei Fragen mit demselben Signal beantwortet, gibt diesem Signal zu viel Bedeutung.

Die Geräteentsperrung steuert den Zugriff auf die lokale Benutzerumgebung. Sie kann zeigen, dass jemand den Anmeldeschutz des Mac passiert hat. Auf unterstützter Hardware kann ein Tresor Secure Enclave und Touch ID verwenden, damit Geheimnisse bei gesperrtem Gerät nicht verfügbar sind. Das schützt Daten im Ruhezustand und schafft eine klare Handlungsschwelle, sagt aber nichts Bestimmtes über den nächsten Prozess aus, den ein Agent-Framework startet.

Menschliche Anwesenheit ist ein Zeitpunkt. Eine biometrische Bestätigung oder ein Klick kann sie für eine bestimmte Entscheidung belegen. Wenn eine solche Prüfung bis zum nächsten Neustart stillschweigend alle künftigen externen Aktionen erlaubt, wird dieser Moment viel weiter ausgelegt, als die verantwortliche Person beabsichtigt hat. Das Risiko steigt, wenn ein Coding-Agent stundenlang weiterarbeitet, veränderte Repository-Dateien liest oder Anweisungen aus Pull Requests und Issue-Kommentaren akzeptiert.

Eine Prozessgenehmigung beantwortet die engere Frage: Genehmige ich dieses neu gestartete Programm für Gateway-Aufrufe während dieses Laufs? Die Genehmigungsansicht sollte den Prozess anhand dauerhafter Belege wie einer Codesignatur identifizieren und nicht verlangen, dass jemand einen veränderlichen Prozessnamen deutet. Eine Bezeichnung wie agent ist keine Identität. Jeder kann sie wählen.

Die Reihenfolge ist wichtig. Zuerst muss der Tresor verfügbar sein. Dann kann das Gateway den Prozess identifizieren. Danach kann die verantwortliche Person diesen Prozess für den angeforderten Lauf genehmigen. Für besonders sensible Zugangsdaten sollte bei jeder Verwendung erneut bestätigt werden. So erhält ein Team drei Kontrollen mit unterschiedlichen Aufgaben statt einer überladenen Schaltfläche «Agent erlauben».

Verwenden Sie den Mac-Kontonamen nicht als Ersatz für die Prozessidentität. Ein gemeinsam verwendetes lokales Konto kann mehrere Terminalsitzungen, Build-Werkzeuge, Editoren und Agent-Hosts ausführen. Folgt eine Genehmigung dem gesamten Konto, kann ein bösartiger Shell-Befehl oder ein zweiter Agent die Berechtigung verwenden, die eigentlich für einen anderen Prozess gedacht war.

Die Genehmigungsentscheidung darf außerdem nicht so tun, als beantworte sie Fragen zum Umfang, die sie gar nicht beantwortet. Eine Prozessberechtigung sagt, wer während eines bestimmten Laufs das Gateway aufrufen darf. Sie sollte nicht stillschweigend die Erlaubnis für jede Zugangsdatenart oder jede Aktion auf unbestimmte Zeit bedeuten. Verbinden Sie sie mit der Auswahl der Zugangsdaten und, falls nötig, einer Bestätigung pro Aufruf. So übernimmt eine wirkungsvolle Zugangsdatenart nicht einfach die Bequemlichkeit eines weniger riskanten API-Aufrufs.

Es liegt nahe, dieses Problem mit einer aufwendigen Richtliniensprache zu lösen: Bedingungen für Zeit, Quellpfad, Branch, Hostname, Befehlsmuster und Prompts. Für spezialisierte Sicherheitsteams kann das funktionieren. Für gewöhnliche Entwickler entsteht jedoch eine andere Gefahr, wenn sie das Ergebnis nicht vorhersehen können. Eine kleine Zahl sichtbarer Entscheidungen lässt sich nach einem Neustart leichter treffen und bei einer Prüfung leichter erklären.

Einen benannten Lauf statt einer pauschalen Team-Berechtigung fortsetzen

Teams können unterbrochene Arbeit sicher fortsetzen, wenn sie das Arbeitselement dauerhaft und die Berechtigung nur vorübergehend machen. Der neu gestartete Agent sollte genügend Kontext erhalten, um weiterzuarbeiten, aber als neuer Prozess eine neue Berechtigung bekommen. Eine projektweite gespeicherte Genehmigung ist der falsche Weg, weil dadurch unabhängige Arbeiten eine alte Entscheidung übernehmen können.

Geben Sie jedem umfangreichen Lauf eine dauerhafte Referenz, die Menschen bereits verstehen. Für Entwicklungsaufgaben können Repository-Pfad und Branch genügen. Für operative Aufgaben eignen sich möglicherweise Ticketnummer, Änderungsanfrage, Umgebungsname oder Vorfallskennung besser. Die Referenz verleiht keine Berechtigung. Sie ermöglicht den Vergleich zwischen dem neu gestarteten Lauf und der erwarteten Arbeit.

Eine nützliche Fortsetzungskarte oder Eingabeaufforderung enthält fünf Angaben:

1. Die Kennung des vorherigen Laufs und den Grund seines Endes, etwa stopped_by_reboot.
2. Die Arbeitsreferenz und die Repository-Revision oder das Deployment-Artefakt des alten Laufs.
3. Die nächste externe Aktion, die der neue Prozess vorschlägt, einschließlich Ziel und Kennzeichnung der Zugangsdaten.
4. Die Identitätsbelege des aktuellen Prozesses, nicht nur des alten.
5. Die Möglichkeit, diesen Lauf zu genehmigen, abzulehnen oder den früheren Aktionsdatensatz zu prüfen.

Stellen Sie nicht die gesamte Aktionswarteschlange ohne Prüfung wieder her. Die Außenwelt kann sich während der Ausfallzeit verändert haben. Ein Pull Request kann per Force-Push geändert worden sein, ein DNS-Eintrag kann auf ein anderes Ziel zeigen, ein Deployment kann auf anderem Weg abgeschlossen worden sein oder ein Wartungsfenster kann geschlossen sein. Dass ein Agent früher einen Plan erstellt hat, macht spätere Nebenwirkungen nicht automatisch angemessen.

Nehmen wir einen Agent, der eine Flotte über eine HTTP-API aktualisiert. Vor dem Neustart änderte er erfolgreich die Hosts A bis D und bereitete Aufrufe für E bis H vor. Der Mac startet neu. Beim Start findet der Agent die alte Warteschlange und versucht weiterzumachen. Eine nachlässige Implementierung verwendet das Token erneut und sendet die Aufrufe für E bis H. Eine sichere Implementierung liest den Unterbrechungseintrag, erstellt einen neuen Lauf, fordert eine Genehmigung an, ruft den aktuellen Zustand ab und zeigt die verbleibenden geplanten Aufrufe. Dabei kann sich herausstellen, dass eine andere Person F und G bereits geändert hat. Die frische Genehmigung gab Gelegenheit, dies zu erkennen.

Wiederholungen brauchen eine harte Grenze. Verweigert das Gateway einen Aufruf, weil der Tresor gesperrt ist oder der Prozess keine Genehmigung besitzt, sollte der Client stoppen und die blockierte Aktion melden. Er sollte nicht in einer Schleife weiterlaufen, wiederholt Aufforderungen öffnen, auf direkten Netzwerkzugriff ausweichen oder Zugangsdaten aus einer Umgebungsvariable einsetzen. Eine Wiederholung nach einem vorübergehenden Netzwerkfehler ist nur dann vertretbar, wenn der Aufruf weiterhin gültig genehmigt ist.

Dieser Ansatz verlangt nicht, dass ein Agent seine Arbeit vergisst. Bewahren Sie Plan, Befehlsausgabe, Repository-Diff und eine verständliche Notiz zur Unterbrechung auf. Behandeln Sie diese Artefakte als Belege für eine neue Entscheidung. Der Unterschied klingt in einer Designbesprechung klein und wird bei einem Vorfall groß: Der gespeicherte Plan erklärt die Absicht, eine geerbte Berechtigung führt dagegen eine Aktion ohne neue verantwortliche Entscheidung aus.

Bei sensiblen Aktionen sollte der neu gestartete Agent den aktuellen Zustand erneut lesen, bevor er die nächste Aktion vorschlägt. Das ist besonders bei zerstörerischen API-Aufrufen und SSH-Befehlen sinnvoll, deren Wirkung vom aktuellen Host-Zustand abhängt. Das zusätzliche Lesen ist keine Berechtigung. Es prüft, ob der alte Plan die Welt noch richtig beschreibt.

HTTP und SSH brauchen ausdrückliche Neustartregeln

HTTP-APIs und SSH brauchen nach einem Neustart beide eine neue Agent-Genehmigung. Ihr versteckter Zustand unterscheidet sich jedoch genug, dass eine pauschale Aussage «Sitzung zurückgesetzt» Fehler übersehen kann. Schreiben Sie das Rücksetzverhalten für jeden Kanal fest und testen Sie die Pfade, die Agents tatsächlich verwenden.

Bei HTTP müssen Zugangsdaten und ein von einem entfernten Dienst ausgestelltes Zugriffstoken oder Cookie unterschieden werden. Ein Gateway kann die Zugangsdaten lokal verschlüsselt halten und erst nach der Genehmigung in eine Anfrage einsetzen. Der Agent sollte die Antwort erhalten, nicht das Bearer-Token. Nach einem Neustart müssen lokale Zugriffstoken-Caches, für Wiederholungen gespeicherte Request-Header, von Automatisierung verwendete Cookie-Jars und offene Verbindungszustände verworfen werden.

Ein Anbieter kann eine entfernte Sitzung nach dem Neustart erhalten, wenn ein Client später ein noch gültiges Refresh-Token oder Cookie vorlegt. Deshalb sollte ein Agent solche Artefakte nicht besitzen. Sonst kann er den Anbieter direkt aufrufen und die lokalen Neustartregeln umgehen. Legen Sie das Einsetzen von Zugangsdaten und die Token-Erneuerung auf die Aktionsseite der Grenze, wo ein frisch genehmigter Prozess sie aufruft.

Bei SSH müssen Client-Verbindungen beendet und Multiplexing-Einstellungen geprüft werden. OpenSSH kann über ControlMaster und ControlPath eine Master-Verbindung wiederverwenden. Das hilft interaktiven Benutzern, kann aber unklar machen, welche Ausführung eine entfernte Sitzung besitzt. Ein Agent-Gateway sollte einen zustandslosen Ausführungspfad oder einen Lebenszyklus verwenden, der jeden Helfer sauber beendet, sobald der Agent-Lauf endet. Nehmen Sie niemals an, dass ein entfernter Befehl gestoppt wurde, nur weil die lokale Oberfläche geschlossen ist.

Verwenden Sie für beide Kanäle diesen reproduzierbaren Neustarttest:

1. Starten Sie einen Agent-Lauf und genehmigen Sie eine harmlose HTTP-Anfrage oder einen SSH-Befehl gegen ein Nicht-Produktionsziel.
2. Notieren Sie Laufkennung, Prozessidentität, geplante Anfrage und Zeitpunkt der letzten abgeschlossenen Aktion.
3. Starten Sie den Mac neu, bevor der Agent eine zweite vorbereitete Aktion ausführt.
4. Starten Sie den Agent-Host erneut, ohne Aufgabendateien zu ändern, und fordern Sie die zweite Aktion an.
5. Prüfen Sie, dass der erste Versuch abgelehnt wird, bis der Tresor verfügbar ist und der neue Prozess eine Genehmigung erhält. Kontrollieren Sie anschließend, dass die zweite Aktion zu einer anderen Laufkennung gehört.

Wenn das Gateway einen Befehlszeilenprüfer für Audits unterstützt, führen Sie ihn vor und nach dem Test aus:

sp audit verify

Der Befehl sollte melden, ob die verschlüsselte Audit-Kette gültig ist, ohne dass der Tresor entsperrt werden muss. Schreiben Sie keine Automatisierung, die erfundene Erfolgstexte aus einem für Menschen bestimmten Befehl auswertet. Prüfen Sie den dokumentierten Exit-Status und bewahren Sie die Befehlsausgabe beim Testprotokoll auf. Sallyport erstellt Sitzungs- und Einzelaufrufprotokolle aus einem schreibgeschützten, hashverketteten und verschlüsselten Audit-Protokoll. Der Prüfer ermöglicht deshalb nach einem Neustart eine Integritätsprüfung ohne Netzwerk und ohne Entsperren des Tresors.

Der Test sollte auch den fehlerhaften Weg abdecken. Probieren Sie eine alte Umgebungsvariable, ein zwischengespeichertes HTTP-Client-Profil, einen SSH-Control-Socket und einen zweiten lokalen Agent-Prozess aus. Erreicht einer davon das Ziel ohne neue Genehmigung, ist die Neustartgrenze nur Dekoration. Beheben Sie die Umgehung, statt den Betreibern eine weitere Erinnerung hinzuzufügen.

Audit-Einträge müssen alten und neuen Lauf erklären

Ein Audit-Protokoll nach einem Neustart sollte zeigen, wo ein Lauf endete und wo ein anderer begann. Die Trennung muss sichtbar bleiben, auch wenn derselbe Benutzer, dasselbe Repository und dasselbe Agent-Framework dieselbe Aufgabe fortsetzen. Fasst das Protokoll beide Ereignisse zu einer langen Sitzung zusammen, kann es nicht beantworten, wer die Aktion nach dem Neustart genehmigt hat.

Speichern Sie den Endzustand des alten Laufs ausdrücklich. Nützliche Werte sind normal beendet, wegen gesperrtem Tresor abgelehnt, auf Genehmigung wartend abgelehnt, Host heruntergefahren, Netzwerkfehler und vom Betreiber widerrufen. Überschreiben Sie diesen Zustand nicht, wenn der neue Prozess startet. Ein Neustarteintrag sollte auf den vorherigen Lauf verweisen, nicht mit ihm verschmelzen.

Für den neuen Lauf sollten die bei der Genehmigung vorgelegten Prozessidentitätsbelege, der Genehmigungszeitpunkt und der erste externe Aufruf erfasst werden. Der erste Aufruf ist wichtig, weil eine Genehmigung nicht immer zu einer Verwendung führt. Eine Person kann einen Lauf genehmigen, der vor der ersten Aktion endet. Die Trennung von Genehmigung und Ausführung verhindert, dass eine Prüfung eine Aktion behauptet, obwohl nur die Möglichkeit dazu erlaubt wurde.

Einzelne Aufrufeinträge sollten genügend Kontext bewahren, um die Aktion ohne Speicherung eines Geheimnisses zu rekonstruieren. Bei HTTP gehören Ziel, Methode, Kennzeichnung der Zugangsdaten, Ergebnisklasse und eine bereinigte Darstellung der Request-Metadaten dazu. Bei SSH sollten Ziel, Kontokennung, Befehl oder ein genehmigter Digest, Exit-Status und Ergebnis-Metadaten gespeichert werden. Wie Befehlsausgaben aufbewahrt werden, hängt von ihrer Sensibilität ab. Die Tatsache einer Aktion darf jedoch nicht verschwinden.

Hash-Verkettung macht nachträgliche Manipulation leichter erkennbar, nicht unmöglich. Sie ist nützlich, weil jeder Eintrag sich auf die vorherigen Einträge bezieht und eine Offline-Prüfung eine beschädigte Reihenfolge zeigen kann. Sie beweist nicht, dass eine genehmigte Aktion klug war, und sie hindert niemanden mit entsprechender Berechtigung daran, eine Aktion auszuführen. Teams brauchen weiterhin Prüfung und disziplinierte Genehmigungsgrenzen.

Halten Sie den Audit-Prüfer außerhalb des normalen Agent-Pfads. Ein Agent, der seine eigenen Belege ändern oder bestätigen kann, erzeugt eine zirkuläre Vertrauensbehauptung. Betreiber sollten die Prüfung unabhängig ausführen können, auch wenn der Tresor gesperrt bleibt. Testen Sie außerdem, was passiert, wenn ein Eintrag in einer Kopie der Audit-Daten verändert wird, damit das erwartete Fehlverhalten bekannt ist, bevor es gebraucht wird.

Auch ein sofortiger Widerruf braucht eine Aufzeichnung seines Umfangs. Widerruft eine Person nach einem Neustart eine Sitzung, sollte das Protokoll zeigen, welcher Lauf seine Berechtigung verlor und welche Aufrufe danach abgelehnt wurden. Vermeiden Sie globale Aussagen wie «Agent-Zugriff deaktiviert», sofern das nicht tatsächlich geschehen ist. Präzise Einträge verhindern, dass ein Team raten muss, ob ein anderer Prozess noch eine Genehmigung besaß.

Ablaufregeln festlegen, bevor Automatisierung sie festlegt

Eine sichere Neustartrichtlinie ist kurz genug, dass jeder Entwickler sie korrekt wiedergeben kann: Ein Neustart sperrt geschützte Materialien, beendet jede Agent-Prozessberechtigung und bewahrt Belege sowie nicht ausführbaren Aufgabenkontext. Ein neu gestarteter Prozess erhält eine neu geprüfte Genehmigung. Zugangsdaten werden nur rotiert, wenn Offenlegungs- oder Lebenszyklusregeln dies verlangen.

Schreiben Sie diese Richtlinie in operativen Begriffen auf und benennen Sie für jede Ausnahme eine verantwortliche Person. Wenn ein Team behauptet, durch Neustarts hindurch ununterbrochene Automatisierung zu brauchen, fragen Sie, welche Aktion fortgesetzt würde, welches Konto sie besitzt, wie sie überwacht wird und warum eine menschliche Genehmigungsgrenze nicht akzeptabel ist. Das kann eine Workload mit Servicekonto statt eines interaktiven Coding-Agents beschreiben. Geben Sie ihr ein eigenes Design, statt eine Agent-Sitzung still in ein Serverkonto umzuwandeln.

Legen Sie für den ersten Arbeitstag nach einem unerwarteten Neustart einen vorhersehbaren Ablauf fest. Die verantwortliche Person prüft die Integrität des Audits, kontrolliert den letzten abgeschlossenen Aufruf des alten Laufs, entsperrt geschützte Materialien bei Bedarf, startet einen neuen Agent-Prozess, prüft die fortzusetzende Aufgabe und genehmigt nur Arbeit, die noch zur aktuellen Situation gehört. Das ist eine kleine Unterbrechung im Vergleich zur Rückabwicklung einer Aktion, die unter einer Genehmigung ausgeführt wurde, von deren Fortbestand niemand wusste.

Versprechen Sie nicht, dass Neustartlogik autonome Arbeit allein sicher macht. Sie kann lediglich einen sauberen Entscheidungspunkt schaffen. Die Qualität dieser Entscheidung hängt weiterhin von klarer Prozessidentität, begrenzter Nutzung von Zugangsdaten, verständlichen Aktionsbeschreibungen und Aufzeichnungen ab, die später eine andere Person prüfen kann.

Wenn der nächste Neustart eine echte Aufgabe unterbricht, widerstehen Sie dem Drang, einen Schalter «automatisch fortsetzen» einzubauen. Bewahren Sie den Plan. Bewahren Sie die Belege. Lassen Sie den neuen Prozess erneut fragen, bevor er eine Berechtigung verwendet.