Zugriff eines AI-Agents während eines laufenden Tasks sicher widerrufen

Ein aktiver AI-Agent braucht keine böswillige Absicht, um einen Incident auszulösen. Eine falsche Anweisung, eine zu weitreichende Tool-Berechtigung, eine manipulierte Repository-Datei oder ein überforderter Bediener können ihn in eine zerstörerische Schleife schicken, solange er noch Zugriff hat. Die Reaktion muss neue Aktionen schnell stoppen, ohne den Datensatz zu vernichten, der erklärt, was passiert ist.

Die übliche schlechte Reaktion besteht darin, das Terminal zu schließen, alle erreichbaren Zugangsdaten zu widerrufen und das Ereignis am nächsten Morgen aus dem Gedächtnis zu rekonstruieren. Dadurch entsteht ein größerer Ausfall. Außerdem geht oft die Unterscheidung verloren zwischen dem, was der Agent versucht hat, dem, was ein entfernter Dienst angenommen hat, und dem, was sich tatsächlich geändert hat. Behandle einen Agent-Incident als Eindämmungsaufgabe mit Beweissicherung, nicht als peinliche Unterbrechung, die man verbergen muss.

Der Widerruf muss künftige Berechtigungen stoppen, bevor er die Spuren verwischt

Einen Agent zu widerrufen bedeutet, ihn an seiner nächsten privilegierten Aktion zu hindern und gleichzeitig genug Zustand zu bewahren, um festzustellen, ob frühere Aktionen erfolgreich waren. Das Schließen eines sichtbaren Chats oder Terminalfensters erfüllt möglicherweise keine der beiden Anforderungen. Der Prozess kann Unterprozesse haben, der Agent kann eine offene Verbindung zu einem entfernten System besitzen und eine HTTP-Anfrage kann weiterlaufen, nachdem der lokale Prozess verschwunden ist.

Trenne diese vier Dinge, bevor du Kontrollen veränderst:

• Der Agent-Prozess ist das lokale Programm, das Entscheidungen und Tool-Aufrufe erzeugt.
• Die Sitzung ist die Berechtigung, die diesem konkreten Prozesslauf erteilt wurde.
• Die Zugangsdaten sind das Geheimnis oder die Identität, die ein externes System akzeptiert.
• Die entfernte Operation ist die Arbeit, die bereits von einer API, Warteschlange, einem Host oder einer Cloud-Steuerung angenommen wurde.

Oft werden Sitzungswiderruf und Wechsel von Zugangsdaten miteinander vermischt. Das kann schwerwiegende Folgen haben. Wenn du ein gemeinsam genutztes Deployment-Token wechselst, um einen Agent zu stoppen, kann die Produktionsautomatisierung ausfallen, während die bereits angenommene Anfrage des Agents trotzdem weiterläuft. Wenn du nur den Agent-Prozess beendest, nachdem er ein Token in einen Arbeitsbereich kopiert hat, kann ein wiederverwendbares Geheimnis zurückbleiben.

Die Eindämmung sollte deshalb der zuverlässigsten Kontrolle möglichst nahe am Agent folgen. Verweigere zuerst dem aktiven Lauf weitere Aktionen. Halte oder storniere danach Arbeit, die bereits entfernte Systeme erreicht hat. Deaktiviere Zugangsdaten, wenn die Beweise nahelegen, dass das Geheimnis nicht mehr begrenzt ist oder du der Sitzungsgrenze nicht vertrauen kannst.

Formuliere eine einfache Incident-Regel, bevor sie jemand braucht: Wer verdächtiges Verhalten beobachtet, darf den Agent sofort stoppen, ohne auf eine Besprechung zu warten. Eine Prüfung folgt danach. Ein verzögertes Genehmigungsverfahren passt zu einem Deployment, nicht zum Entzug der Berechtigung eines laufenden Prozesses.

Erstelle vor dem ersten Incident eine Aktionsübersicht

Du kannst nichts widerrufen, was du nicht identifizieren kannst. Jeder Agent-Lauf braucht eine Kennung, die im lokalen Prozessdatensatz, in den Tool-Logs und in Anfragen an entfernte Systeme auftaucht. Eine zufällige Lauf-ID reicht aus, wenn du sie konsequent weitergibst. Verwende keinen menschlichen Namen und keine vage Bezeichnung wie coding-agent. Beide vermischen voneinander unabhängige Aktivitäten.

Halte für jeden Weg, über den ein Agent handeln kann, die Antworten auf fünf operative Fragen fest:

1. Welcher lokale Prozess besitzt diesen Weg, und wie stoppen wir ihn?
2. Welche Sitzung oder welches Token repräsentiert diesen Prozess gegenüber dem Aktions-Gateway?
3. Welche entfernten Operationen können nach dem lokalen Widerruf weiterlaufen?
4. Wo protokollieren unabhängige Dienste diese Operationen?
5. Wer kann den Weg deaktivieren, wenn der normale Verantwortliche nicht verfügbar ist?

Das ist keine Bürokratie um ihrer selbst willen. Während eines Incidents sollte niemand erst herausfinden müssen, ob eine Datenbankmigration über einen Shell-Unterprozess, einen CI-Job, eine HTTP-Anfrage oder einen separaten Cloud-Workflow läuft.

Verwende eine Lauf-ID als Request-Header, wann immer eine API das erlaubt. Für einen Agent mit der Lauf-ID run_2025_04_18_7f3c kann ein Wrapper einen Korrelations-Header hinzufügen, ohne ein Geheimnis in Prompt oder Umgebung des Agents abzulegen:

export AGENT_RUN_ID="run_2025_04_18_7f3c"
curl -sS -X POST "$ACTION_ENDPOINT" \
  -H "X-Agent-Run-ID: $AGENT_RUN_ID" \
  -H "Content-Type: application/json" \
  --data @request.json

Der empfangende Dienst sollte die Lauf-ID zusammen mit der normalen Request-ID, der aufrufenden Identität, dem Endpunkt, dem Antwortstatus und der Uhrzeit protokollieren. Ein nützlicher Eintrag sieht etwa so aus:

time=2025-04-18T14:12:09Z request_id=req_91a run_id=run_2025_04_18_7f3c caller=agent-gateway method=POST path=/deployments status=202

Ein 202 ist wichtig. Er bedeutet, dass der Dienst die Arbeit angenommen hat, nicht dass sie abgeschlossen ist. Genau hier gehen Prüfungen oft schief: Teams betrachten die letzte Tool-Ausgabe des Agents als Ergebnis, obwohl das entfernte System lediglich die Übermittlung an eine Warteschlange bestätigt hat.

Ordne SSH das entfernte Konto, die Ziel-Hosts, gegebenenfalls erzwungene Befehle und den Ort zu, an dem Anmelde- und Befehlsaktivitäten protokolliert werden. Ein lokales Terminalprotokoll ist hilfreich, beweist aber nicht, dass ein Befehl nicht entfernt ausgeführt wurde. Die eigenen Logs des Hosts und der relevante Service-Audit-Trail beantworten diese Frage.

Stoppe den aktiven Lauf so, dass die Kontrolle erhalten bleibt

Halte zuerst die Uhrzeit und den unmittelbaren Grund für den Widerruf fest. Verweigere danach neue Aktionen und beende den Agent. Die genauen Befehle unterscheiden sich je nach Betriebssystem und Laufzeitumgebung. Die Reihenfolge sollte sich jedoch nicht ändern, weil sie Eindämmung und Bereinigung voneinander trennt.

1. Notiere Lauf-ID, lokale Prozess-ID, Bediener, beobachtetes Verhalten und aktuelle Uhrzeit im Incident-Datensatz. Sichere eine Kopie des aktuellen Agent-Transkripts und des letzten sichtbaren Tool-Aufrufs, bevor du die Oberfläche schließt.
2. Widerrufe oder sperre die aktive Sitzung am Gateway, das Aktionen autorisiert. Bestätige, dass ein neuer Testaufruf desselben Prozesses abgelehnt wird, sofern eine sichere Nur-Lese-Aktion verfügbar ist.
3. Halte den lokalen Prozess an, bevor du ihn beendest, sofern das Betriebssystem dies erlaubt. Durch das Anhalten bleiben Prozessbaum und Liste geöffneter Dateien stabil. Beende ihn erst nach dieser Sicherung, außer die weitere Ausführung würde unmittelbar Schaden verursachen.
4. Suche und stoppe Unterprozesse, Hintergrundjobs, Container und entfernte Sitzungen, die mit diesem Lauf verbunden sind.
5. Storniere angenommene entfernte Arbeit über die eigene Stornierungsfunktion des Dienstes und bewahre Antwort und Status auf.

Beginne unter macOS oder Linux mit einer Prüfung statt mit einem blinden kill -9. Ersetze die Beispiel-Prozess-ID durch die aufgezeichnete ID:

ps -o pid,ppid,pgid,lstart,command -p 48192
pgrep -P 48192 -a
lsof -nP -p 48192
kill -STOP 48192

Der erste Befehl erfasst Elternprozess und Startzeit. pgrep zeigt direkte Kinder, und lsof macht oft geöffnete Arbeitsbereichsdateien, Sockets und Pipes sichtbar, die gesichert werden sollten. kill -STOP friert einen kooperativen Prozess ein, ohne ihm eine weitere Bereinigung zu ermöglichen. Ein bereits abgelöster Unterprozess, ein entfernter Job oder eine Anfrage, die die Netzwerkgrenze überschritten hat, wird dadurch nicht eingefroren.

Nachdem du die Ausgaben in den Incident-Ordner kopiert hast, erfasse die Prozessgruppe. Ein Prozess kann einen Unterprozess starten, der seine Prozessgruppe wechselt. Beschränke dich deshalb nicht auf einen einzigen Befehl. Prüfe Container-Laufzeiten und Hintergrundjob-Manager, sofern der Agent sie verwenden kann. Wenn der Agent SSH-Zugriff hat, prüfe auch aktive Sitzungen auf jedem Ziel-Host.

Wenn die Aufgabe entfernte Arbeit ausführt, verwende die Operations-ID des entfernten Systems. Eine API kann bei der Annahme einer Anfrage beispielsweise Folgendes zurückgeben:

{
  "operation_id": "op_4e2b7c",
  "status": "queued"
}

Speichere diese Antwort und rufe anschließend den dokumentierten Stornierungsendpunkt auf oder verwende die Dienstkonsole unter menschlicher Kontrolle. Halte das Ergebnis der Stornierung fest. Eine Antwort wie cancel_requested bedeutet, dass du die Operation weiter abfragen musst, bis sie cancelled, completed oder einen anderen Endzustand meldet. Schreibe nicht «gestoppt» in die Incident-Notizen, nur weil der lokale Prozess verschwunden ist.

Sichere Beweise, bevor du den Arbeitsbereich zurücksetzt

Sichere Beweise in einem separaten Incident-Ordner, bevor du Branches löschst, Dienste neu startest oder ein automatisches Bereinigungsskript ausführst. Du brauchst eine chronologische Aufzeichnung, die eine andere Entwicklerin oder ein anderer Entwickler prüfen kann, ohne auf die Erinnerung des Bedieners angewiesen zu sein.

Sammle die folgenden Daten und bewahre nach Möglichkeit die ursprünglichen Zeitstempel:

• Das Agent-Transkript, Tool-Eingaben, Tool-Ausgaben und die für den Lauf verwendete Konfiguration.
• Prozessprüfungen, IDs von Eltern- und Unterprozessen, offene Verbindungen und für den Lauf relevante Shell-Historie.
• Sitzungsaufzeichnungen und Aktionslogs des Gateways, einschließlich Ablehnungen nach dem Widerruf.
• Audit-Ereignisse entfernter Dienste, Operations-IDs, Stornierungsergebnisse und IDs geänderter Ressourcen.
• Den Zustand des Repositorys: aktueller Commit, Diff, nicht versionierte Dateien und erzeugte Artefakte.

Hash die Dateien nach der Sammlung. Ein einfaches Manifest ermöglicht späteren Prüfern, versehentliche Änderungen zu erkennen, während Kopien zwischen Bereitschaftsdienst, Sicherheitsteam und der für das betroffene System verantwortlichen Entwicklung weitergegeben werden:

mkdir -p incident-run_2025_04_18/evidence
cp agent-transcript.txt incident-run_2025_04_18/evidence/
ps -o pid,ppid,pgid,lstart,command -p 48192 > incident-run_2025_04_18/evidence/process.txt
shasum -a 256 incident-run_2025_04_18/evidence/* > incident-run_2025_04_18/SHA256SUMS.txt

Das Ausgabemanifest sollte so aussehen:

8f7c...  incident-run_2025_04_18/evidence/agent-transcript.txt
30b1...  incident-run_2025_04_18/evidence/process.txt

Ein Hash macht eine Datei nicht wahrheitsgetreu. Er beweist, dass ein Prüfer dieselbe Datei erhalten hat, die du gehasht hast. Gleiche sie mit Logs ab, die von Systemen gehalten werden, die der Agent nicht bearbeiten konnte, etwa dem Audit-Trail eines API-Anbieters oder einem zentralen, nur anhängbaren Logging-Dienst.

NIST behandelt in seinem Computer Security Incident Handling Guide, SP 800-61, Eindämmung, Beseitigung, Wiederherstellung und Arbeiten nach dem Incident als getrennte Aktivitäten. Diese Trennung passt gut zu Agent-Incidents. Teams springen oft direkt zur Beseitigung, indem sie das Arbeitsverzeichnis löschen oder ein Token wechseln. Dann stellen sie fest, dass das gelöschte Transkript genau den Request-Body enthielt, der zum Auffinden einer entfernten Ressource nötig gewesen wäre.

Kopiere keine Geheimnisse allein deshalb in den Incident-Ordner, weil du Kontext bewahren willst. Erfasse Kennungen der Zugangsdaten, Verantwortliche, Umfang, Erstellungszeit und letzte Nutzungen. Speichere tatsächliche Geheimniswerte nur, wenn dein bestehender Incident-Prozess dies ausdrücklich erlaubt und schützen kann. Ein Incident-Archiv sollte Unsicherheit verringern und keinen zweiten Verlust von Geheimnissen schaffen.

Ein beendeter Elternprozess beweist nicht, dass die Arbeit gestoppt wurde

Gehe davon aus, dass ein aktiver Agent Arbeit zurücklassen kann, bis du das Gegenteil festgestellt hast. Die problematischsten Fälle sind nicht dramatische Shell-Befehle, sondern gewöhnliche asynchrone Aktionen, die während normaler Arbeit kaum auffallen würden.

Stell dir einen Coding-Agent vor, der eine Deployment-Anfrage sendet, einen SSH-Befehl startet, der eine Hintergrundmigration ausführt, und anschließend auf Tests wartet. Der Bediener sieht ein unerwartetes Produktionsziel und stoppt den übergeordneten Agent. Der Deployment-Dienst hat die Anfrage bereits angenommen, während die entfernte Shell unter nohup bereits einen Befehl gestartet hat. Beide laufen weiter. Die letzte Zeile des Terminals sagt möglicherweise nur, dass die Verbindung geschlossen wurde.

Die Prüfung braucht drei unterschiedliche Kontrollen:

Von APIs angenommene Arbeit prüfen

Durchsuche den betroffenen Dienst nach Lauf-ID, Request-ID, Kontokennung und Zeitfenster. Ermittle für jede Anfrage, ob sie abgelehnt, in die Warteschlange gestellt, ausgeführt, abgeschlossen oder storniert wurde. Liste bei abgeschlossenen Änderungen die konkreten Ressourcen-IDs auf und vergleiche den resultierenden Zustand mit dem angeforderten Zustand.

Verlasse dich nicht allein auf den HTTP-Status. Ein 200 kann eine synchrone Änderung, ein Statusdokument oder eine Antwort eines Vermittlers beschreiben. Ein 202 bedeutet normalerweise, dass eine Verarbeitung angenommen wurde. Die endgültige Bedeutung legt jedoch die Dokumentation des Dienstes fest. Lies diese Dokumentation, bevor du für den Dienst einen Stornierungsablauf erstellst.

Vom Agent abgelöste Arbeit prüfen

Prüfe auf Zielsystemen die Sitzungen des entfernten Kontos, den Prozessbaum, geplante Jobs, temporäre Verzeichnisse und Dienst-Logs. Suche nach der aufgezeichneten Befehlszeile, dem Arbeitsverzeichnis, der Lauf-ID oder einer eindeutig erzeugten Datei. Verwendet eine entfernte Aufgabe einen Job-Scheduler, storniere sie über diesen Scheduler, statt eine Shell zu beenden, die möglicherweise nicht mehr für sie zuständig ist.

Prüfe auch Rückrufe. Ein erzeugtes Skript kann einen Webhook eingerichtet, einen Pull-Request-Workflow erstellt oder CI ausgelöst haben. Das sind eigenständige Akteure mit eigenen Zugangsdaten und Zeitplänen. Der Widerruf des ursprünglichen Agents widerruft diese nicht.

Deshalb ist ein eng begrenztes Aktions-Gateway sicherer, als einem Agent eine allgemeine Shell mit einer weitreichenden Umgebung zu übergeben. Du kannst eine begrenzte Zahl von Kanälen erfassen und verlangen, dass jeder privilegierte Aufruf einen Kontrollpunkt passiert. Eine Shell mit geerbten Zugangsdaten macht jeden Unterprozess zu einem eigenen Incident-Zweig.

Wechsle Zugangsdaten nur, wenn die mögliche Offenlegung es rechtfertigt

Wechsle Zugangsdaten, wenn Grund zu der Annahme besteht, dass der Agent, seine Unterprozesse, seine Logs oder sein Arbeitsbereich das Geheimnis behalten haben könnten. Wechsle sie nicht nur, um den Anschein einer Reaktion zu erzeugen. Ein weitreichender Wechsel unterbricht legitime Nutzer und kann die Prüfung erschweren, wenn dadurch genau die Datensätze verändert werden, die du noch untersuchen musst.

Diese Bedingungen rechtfertigen eine sofortige Deaktivierung oder einen Wechsel:

• Der Agent erhielt ein Klartextgeheimnis in Prompt, Umgebungsvariable, Konfigurationsdatei, Befehlszeile oder Tool-Ausgabe.
• Eine Zugangsdaten erschien in einem Transkript, Repository-Diff, einer temporären Datei oder einem CI-Log mit Zugriff außerhalb des Incident-Teams.
• Du kannst einen Unterprozess, eine entfernte Sitzung oder eine ausgehende Verbindung nicht nachvollziehen, die das Geheimnis gelesen haben könnte.
• Die Zugangsdaten haben weitreichende Berechtigungen und keine verlässlichen Nutzungsprotokolle.
• Der betroffene Anbieter teilt mit, dass die Zugangsdaten von einer ungeklärten Identität oder einem ungeklärten Ort verwendet wurden.

Wenn ein Gateway die Zugangsdaten einfügt und dem Agent nur das Ergebnis der Aktion zurückgibt, ist die Situation deutlich anders. Der Agent könnte eine nicht autorisierte Aktion ausgeführt haben, besaß aber nicht zwingend ein wiederverwendbares Geheimnis. Deaktiviere die aktive Sitzung und den betroffenen Aktionsweg, prüfe den Audit-Datensatz und wechsle die zugrunde liegenden Zugangsdaten, wenn die Prüfung einen Umweg um diese Grenze oder ein Problem auf Anbieterseite feststellt.

Vermeide die Empfehlung, nach jedem Fehler eines Agents jedes Geheimnis zu wechseln. Sie ist beliebt, weil sie entschlossen wirkt und offengelegte Zugangsdaten ernste Folgen haben. Als Standard ist sie falsch, weil sie unbefugte Nutzung mit der Offenlegung von Zugangsdaten verwechselt, vermeidbare Produktionsausfälle erzeugt und Teams dazu bringt, auf eine genaue Eingrenzung zu verzichten. Wechsle aggressiv, wenn eine Offenlegung plausibel ist. Bewahre andernfalls die Möglichkeit, den kompromittierten Lauf von allen anderen zu unterscheiden.

Wenn ein Wechsel erforderlich ist, dokumentiere die alte Kennung, den Deaktivierungszeitpunkt, nachgelagerte Systeme, die sie verwenden, den Verantwortlichen für den Ersatz und einen Test, der beweist, dass die alte Zugangsdaten nicht mehr funktioniert. Lege keinen der beiden Werte in einem Ticket oder Transkript ab. Ein Secret Manager oder der geschützte Rotationsmechanismus des Anbieters sollte den Ersatz übernehmen.

Der Incident-Datensatz muss eine kritische Prüfung ermöglichen

Eine Incident-Prüfung sollte einer Entwicklerin oder einem Entwickler, die oder der nicht Bereitschaft hatte, erlauben, die Abfolge zu rekonstruieren, ohne einem einzigen veränderbaren Log zu vertrauen. Beginne mit der Absicht des Agents und dem lokalen Prozessdatensatz und vergleiche diese Darstellung anschließend mit Gateway-Aufzeichnungen und Beweisen aus entfernten Diensten.

Erstelle eine Zeitleiste mit ausdrücklichen Vertrauensstufen. «Agent schlug Anfrage vor» stammt beispielsweise aus einem Transkript. «Gateway führte Anfrage aus» stammt aus dem Aktionsdatensatz des Gateways. «Anbieter nahm Operation an» stammt aus dem Anbieter-Audit-Eintrag. «Ressource wurde geändert» stammt aus dem Endzustand und der Änderungshistorie der Ressource. Das sind unterschiedliche Aussagen und sie benötigen unterschiedliche Belege.

Ein schreibgeschütztes, hashverkettetes Audit-Log hat hier einen wichtigen Vorteil: Die Komponente, die Aktionen ausführt, kann ihre eigene Historie nachträglich nicht unbemerkt umschreiben. Eine Prüfung über Chiffretext ermöglicht außerdem, die Kontinuität zu kontrollieren, ohne Zugriff auf jedes Geheimnis oder jede Aktionsnutzlast zu erhalten. Das macht das Log nicht vollständig. Es erfasst weiterhin nur Aktivitäten, die das Gateway passiert haben. Deshalb gehören die Logs entfernter Dienste ebenfalls zur Prüfung.

Sallyport zeichnet Agent-Sitzungen und einzelne Aktionen in einem verschlüsselten, hashverketteten Audit-Log auf. sp audit verify prüft die Kette offline, ohne einen Tresorschlüssel zu benötigen. Das gibt einer prüfenden Person einen klaren Test für eine exportierte Log-Kopie:

sp audit verify /path/to/exported-audit-log

Eine erfolgreiche Prüfung bestätigt die Kontinuität des verschlüsselten Datensatzes, den du erhalten hast. Eine fehlgeschlagene Prüfung sollte eine beiläufige Bereinigung stoppen und die Beweissicherung auslösen. Du musst feststellen, ob ein Fehler beim Export, eine Beschädigung des Speichers oder eine absichtliche Veränderung die Unterbrechung verursacht hat.

Die Prüfung sollte Antworten liefern, keine vage Liste von Beobachtungen. Ermittle die auslösende Anweisung oder Eingabe, die dem Lauf erteilte Berechtigung, jede bestätigte externe Aktion, jede weiterhin unsichere Aktion, möglicherweise entwichene Zugangsdaten und die Kontrolländerung, die das Ereignis früher gestoppt hätte. Wenn das Team die erste ausgefallene Kontrolle nicht benennen kann, wird es wahrscheinlich einen störenden Genehmigungsdialog hinzufügen, statt den offengelegten Weg zu reparieren.

Setze die Entwicklung mit einer neuen Grenze fort, nicht mit einer wieder geöffneten Sitzung

Entwickler können nach der Eindämmung weiterarbeiten. Sie sollten jedoch nicht denselben Prozess, denselben Arbeitsbereich oder dieselbe Berechtigung verwenden. Der unterbrochene Lauf kann ungeprüfte Anweisungen im Speicher, veralteten Aufgabenkontext, erzeugte Skripte oder einen Unterprozess enthalten, den die erste Reaktion übersehen hat.

Erstelle einen neuen Lauf mit einer neuen Sitzungsidentität. Prüfe Repository-Diff und erzeugte Dateien, bevor du dem neuen Lauf Zugangsdaten oder Produktionsziele zugänglich machst. Wenn die frühere Aufgabe fortgesetzt werden muss, gib dem neuen Lauf eine kurze schriftliche Übergabe mit abgeschlossenen entfernten Aktionen, stornierten Aktionen und Ressourcen, die noch geprüft werden müssen.

Verwende für die fortgesetzte Aufgabe einen engeren Berechtigungssatz. Eine Codeprüfung braucht selten Deployment-Berechtigungen. Eine Aufgabe, die Produktionsdaten abfragen muss, braucht normalerweise keinen Schreibzugriff. Es geht nicht darum, jede Entwicklerin und jeden Entwickler in eine komplizierte Richtliniensprache zu zwingen. Es geht darum, eine weitreichende Berechtigung aus dem Vortag nicht in einen Lauf mitzunehmen, der nach einem Incident startet.

Eine sitzungsbezogene Autorisierung ist besonders nützlich, wenn nach einem Stopp ein neuer lokaler Prozess beginnt. Sie zwingt einen Menschen zu erkennen, dass es sich um einen anderen Lauf handelt. Eine Genehmigung pro Aufruf passt zu Aktionen, bei denen die Kosten eines fehlerhaften Schreibvorgangs hoch genug sind, um eine Unterbrechung zu rechtfertigen. Wenn eine Genehmigungskarte den aufrufenden Prozess und die konkrete Aktion nicht erkennen lässt, repariere das, bevor du ihr während eines Incidents vertraust.

Die erste Übung sollte fünfzehn Minuten dauern: Starte eine harmlose Agent-Aufgabe, widerrufe ihre Sitzung während eines API-Aufrufs, sichere lokale und entfernte Datensätze und bestätige, dass die Aufgabe unter ihrer alten Berechtigung nicht fortgesetzt werden kann. Führe die Übung gegen ein wegwerfbares Ziel aus. So findest du fehlende Request-IDs, abgelöste Unterprozesse und Probleme beim Log-Zugriff, wenn die Kosten gering sind, statt während eines echten Produktionsfehlers.

Mache den Widerruf zu einer normalen Bedieneraktion

Ein Team, das den Widerruf als seltenen Notfall behandelt, wird zögern, wenn sich ein Agent seltsam verhält. Die Kontrollen sollten die sichere Entscheidung schnell machen: Aktionsgrenze sperren, Sitzung widerrufen, bereits über diese Grenze gelangte Arbeit prüfen und einen Datensatz hinterlassen, der die Bereinigung übersteht.

Die stärkste Designentscheidung ist eine einfache Trennung. Agents können Aktionen planen und anfordern. Ein lokaler Kontrollpunkt verwahrt Zugangsdaten, identifiziert den anfragenden Prozess, protokolliert die Anfrage und kann diesen Prozess ablehnen, ohne ihm das Geheimnis zu übergeben. Wenn der Bediener auf Stopp drückt, muss der nächste privilegierte Aufruf fehlschlagen, während die früheren Aufrufe prüfbar bleiben.

Prüfe diese Aussage mit den tatsächlichen Tools deiner Agents. Wenn das Team einen einzelnen laufenden Lauf nicht stoppen kann, ohne eine gemeinsam genutzte Zugangsdaten zu wechseln, eine entfernte Operation nicht diesem Lauf zuordnen kann oder die Aktionshistorie nachträglich nicht prüfen kann, ist der Incident-Ablauf noch nicht fertig.