# Sollten ausstehende Anfragen bei einem gesperrten Tresor überhaupt warten? Eine Agent-Anfrage, die einen gesperrten Tresor erreicht, sollte sofort scheitern. Sie darf nicht zu einem ruhenden Befehl werden, der wieder zum Leben erwacht, wenn jemand den Tresor eine Stunde später entsperrt. Das klingt streng, bis man sich ansieht, was ein Entsperren tatsächlich beweist. Es beweist, dass eine Person in diesem Moment den Zugriff auf einen Speicher für Geheimnisse autorisiert hat. Es beweist nicht, dass ein alter Agent-Prozess noch dieselbe Aufgabe hat, dass ein Deployment weiterhin sinnvoll ist, dass sich ein Pull Request nicht verändert hat oder dass der alte HTTP-Body und der alte SSH-Befehl noch passen. Solche Entscheidungen werden oft als Komfortfunktion getarnt. Jemand sieht einen blockierten Lauf und schlägt eine Warteschlange vor: Anfrage zurückhalten, Benachrichtigung anzeigen, Arbeit nach Touch ID freigeben. Die Warteschlange wirkt hilfreich, weil die Anfrage bereits fertig formuliert ist. Genau das macht sie gefährlich. Eine fertige Anfrage hat die Grenze vom Plan zu einer auf Autorisierung wartenden Aktion überschritten. Die sicherere Regel ist einfach: Solange der Tresor gesperrt ist, werden Aktionen verweigert und ihre ausführbare Form verworfen. Nach dem Entsperren darf der Agent seinen aktuellen Zustand prüfen und eine neue Anfrage senden. Diese zweite Anfrage kann unter dem aktuellen Kontext eine Sitzungsautorisierung oder eine Genehmigung pro Aufruf erhalten. ## Ein gesperrter Tresor muss die Aktion sofort ablehnen Eine Tresorsperre ist eine Zugriffsschranke, kein vorübergehender Netzwerkausfall. Wer sie wie einen Ausfall behandelt, fördert automatische Wiederholungen. Gerade automatische Wiederholungen willst du bei veralteten Absichten eines Agenten vermeiden. Wenn ein Agent einen API-Aufruf oder eine SSH-Verbindung anfordert, verfügt das Gateway über genügend Informationen, um zu entscheiden, ob die Anfrage fortgesetzt werden darf. Ist der Tresor gesperrt, muss es keinen Body prüfen, keinen Host auflösen, keine Verbindung starten und nicht auf einen Benutzer warten. Es sollte die Anfrage ablehnen, bevor sie die Außenwelt berührt. Das Ergebnis muss dem Agenten mitteilen, was geschehen ist, ohne ihn zu einer blinden Wiederholung einzuladen. Eine sinnvolle Form sieht so aus: ```json { "ok": false, "error": { "code": "VAULT_LOCKED", "message": "The credential vault is locked. This action was not queued or sent.", "request_id": "req_7d4c1f", "retryable": false } } ``` `retryable: false` wirkt vielleicht kontraintuitiv. Der Agent kann später eine neue Anfrage stellen, aber die fehlgeschlagene Anfrage selbst darf nicht sicher wiederholt werden. Diese Unterscheidung verhindert, dass Autoren von Clients eine allgemeine Backoff-Schleife bauen, die aus einem Entsperren plötzlich eine ungeprüfte Welle alter Arbeit macht. Ersetze dieses Ergebnis nicht durch `503 Service Unavailable`, einen Timeout oder einen allgemeinen Transportfehler. Solche Antworten weisen einen gut gemeinten Client an, genau dieselbe Aktion zu wiederholen. Das Gateway braucht ein semantisches Ergebnis, das sagt: «Eine von einem Menschen kontrollierte Sicherheitsbedingung hat diesen Aufruf blockiert, und genau dieser Aufruf ist abgeschlossen.» Diese Regel gilt gleichermaßen für Lese- und Schreibzugriffe. Teams sind bei Schreibzugriffen oft vorsichtiger, weil ein veralteter Schreibvorgang etwas löschen oder deployen kann. Auch ein veralteter Lesezugriff kann Kundendaten offenlegen, eine Produktionskonfiguration verraten oder den Agenten dazu bringen, eine spätere Entscheidung auf Daten zu stützen, die der Benutzer längst nicht mehr abrufen wollte. ## Das Entsperren genehmigt keine frühere Absicht Ein Entsperrereignis und eine Genehmigung für eine Aktion beantworten unterschiedliche Fragen. Beim Entsperren geht es darum, ob der Tresor seine Geheimnisse überhaupt verwenden darf. Bei der Genehmigung einer Aktion geht es darum, ob dieser Prozess unter der aktuellen Aufgabe genau diese Art von externem Aufruf ausführen darf. Wenn man diese Entscheidungen zusammenlegt, entsteht ein subtiler Autorisierungsfehler. Stell dir vor, ein Agent bereitet einen SSH-Befehl zum Neustart eines Dienstes vor. Der Entwickler schließt den Laptop, der Tresor wird gesperrt, und der Agent sendet den Aufruf trotzdem. Vierzig Minuten später kommt der Entwickler zurück, entsperrt den Mac, um ein anderes Problem zu untersuchen, und der Neustart wird ausgelöst, weil das Gateway den alten Befehl aufbewahrt hat. Der Entwickler hat in diesem Moment keinen Neustart genehmigt. Er hat den Zugriff auf den Tresor für sich selbst freigegeben. Dasselbe Problem zeigt sich in weniger auffälligen Formen: - Ein Agent hat einen Kommentar für einen Pull Request vorbereitet, aber der Reviewer hat das Problem bereits behoben. - Ein Agent hat einen Cloud-API-Aufruf mit einem Branchnamen vorbereitet, der inzwischen auf einen anderen Commit zeigt. - Ein Agent hat eine Abfrage im Support-System vorbereitet, aber die Kundenanfrage, die sie begründet hat, ist abgeschlossen. - Ein Agent hat die Veröffentlichung eines Pakets vorbereitet, aber während des gesperrten Zugriffs ist ein Test fehlgeschlagen. Das verbreitete Gegenargument lautet, dass die Anfrage bereits vor der Sperre autorisiert war. Manchmal stimmt das, aber auch dann rechtfertigt es keinen verzögerten Versand. Eine Autorisierung kann für eine Sitzung bestehen bleiben, solange der Prozess existiert. Eine Absicht bleibt nicht allein deshalb gültig, weil eine Bytefolge in einer Warteschlange liegt. Ein Gateway sollte deshalb sauber trennen: 1. Die Tresorsperre entscheidet, ob eine Aktion mit Geheimnissen überhaupt beginnen darf. 2. Die Sitzungsautorisierung entscheidet, ob dieser Agent-Prozess für seinen aktuellen Lauf erkannt wird. 3. Die Genehmigung pro Aufruf entscheidet, ob ein Zugangsschlüssel, der eine individuelle Bestätigung verlangt, jetzt verwendet werden darf. Wenn die erste Entscheidung «Nein» lautet, wird abgebrochen. Die späteren Entscheidungen werden nicht geprüft, und eine versandbereite Anfrage wird nicht für den Moment aufbewahrt, in dem sich die Antwort ändert. ## Eine Benachrichtigung ist keine Anfragewarteschlange Du kannst eine Person darüber informieren, dass Arbeit blockiert ist, ohne ausführbare Arbeit zurückzuhalten. Das sind unterschiedliche Designs. Teams vermischen sie, weil beide oft «ausstehende Anfragen» genannt werden. Eine **Benachrichtigung** ist eine nicht ausführbare Tatsache. Sie kann mitteilen, dass ein Prozess zu einem bestimmten Zeitpunkt versucht hat, eine benannte Referenz auf Zugangsdaten für eine Zielklasse zu verwenden. Sie hilft der Person zu entscheiden, ob sie den Tresor entsperren und zur Aufgabe zurückkehren möchte. Sie kann keine Header, keinen Anfrage-Body, keinen SSH-Befehl und kein Genehmigungstoken rekonstruieren. Eine **Anfragewarteschlange** bewahrt genügend Material auf, um später zu versenden. Dazu können eine HTTP-Methode, eine URL, ein Body, Befehlsargumente, die Auswahl von Zugangsdaten, eine Autorisierungsentscheidung oder ein signiertes Wiederholungstoken gehören. Sobald dieses Material gespeichert wird, hast du eine verzögerte Ausführung gebaut. Der Unterschied ist bei der Implementierung wichtig. Als Hinweis auf blockierte Arbeit ist Folgendes akzeptabel: ```json { "event": "action_denied", "reason": "vault_locked", "session_id": "ses_31b8", "channel": "ssh", "credential_label": "production-deploy", "destination": "deploy host", "occurred_at": "2026-07-22T21:14:05Z" } ``` Nicht akzeptabel ist es, wenn das System später den vollständigen Befehl, die Zieladresse, den privaten Anfrage-Body oder eine Autorisierung zur Verwendung der Zugangsdaten aus diesem Ereignis wiederherstellen kann. Der Eintrag sollte Untersuchungen unterstützen, nicht die Wiederholung ermöglichen. Sei auch bei Hashes vorsichtig. Ein Digest ist für die Zuordnung oft unbedenklich, aber nur dann, wenn das Gateway ihn nicht verwenden kann, um einen gespeicherten Payload abzurufen. Ein Digest zusammen mit einem versteckten Blob ist weiterhin eine Warteschlange. Ein Digest, der ausschließlich in einem unveränderbaren Audit-Eintrag existiert, ist etwas anderes. Hier entsteht eine besondere Versuchung: Eine Liste ausstehender Anfragen lässt ein Dashboard reaktionsfähig wirken. Widerstehe ihr, solange jeder Eintrag den Agenten nicht dazu zwingt, nach der Aktion des Benutzers einen neuen Aufruf zu senden. Ein Bildschirm mit «Alle nach dem Entsperren ausführen» hat eine Sicherheitsabfrage in einen verzögerten Auftragsplaner verwandelt. ## Gib dem Agenten ein eindeutig verständliches Zustandsmodell Agenten verhalten sich besser, wenn das Gateway ein kleines, eindeutiges Zustandsmodell bereitstellt. Mehrdeutige Fehler bringen Agenten dazu, eigene Wiederherstellungspläne zu erfinden. Ihr Plan kann dann darin bestehen zu warten, es erneut zu versuchen oder einen anderen Zugangspfad zu finden. Verwende ein Zustandsmodell, in dem eine Anfrage ein endgültiges Ergebnis erhält, sobald die Tresorschranke sie ablehnt: ```text received | +-- vault locked --> denied_locked (terminal) | +-- vault unlocked --> session check | +-- not approved --> denied_session (terminal) | +-- approved --> per-call check | +-- approval declined --> denied_call (terminal) | +-- approved --> dispatched --> completed ``` Wichtig ist nicht das Diagramm selbst. Wichtig ist, dass `denied_locked` keinen Pfeil zurück zu `dispatched` hat. Eine spätere Anfrage kann bei `received` beginnen, die alte Anfrage darf aber an keiner Stelle wieder eintreten. Dieses Design macht auch die Betrachtung von Idempotenz einfacher. Wenn ein Aufruf scheitert, weil der Tresor gesperrt war, darfst du kein Idempotenz-Token reservieren, als hätte der Server die Aktion angenommen. Der Agent muss später eine weitere Anfrage mit einer neuen Anfrage-ID erstellen. Unterstützt die externe API Idempotenzschlüssel, kann die neu gesendete Anfrage einen Schlüssel auf Anwendungsebene verwenden, der den vorgesehenen Geschäftsvorgang beschreibt. Die Ablehnung durch das Gateway darf aber keinen halbfertigen Aktionsdatensatz anlegen. Bei Schreibvorgängen sollte der Agent, sofern das Ziel dies unterstützt, seine eigene aktuelle Vorbedingung mitsenden. Das kann eine Revisions-ID, eine Entitätsversion, ein erwarteter Branch-Stand oder ein ETag sein. Wenn der Tresor geöffnet wird, sollte der Agent den aktuellen Kontext erneut abrufen und einen passenden Aufruf erstellen. Eine veraltete Anfrage kann eine gute Vorbedingung nicht erfüllen. Eine neue Anfrage zeigt dagegen, dass der Agent noch einmal geprüft hat. Versuche nicht, Aktualität allein aus der verstrichenen Zeit abzuleiten. Bei einem sich schnell ändernden Deployment können fünf Sekunden zu lang sein, während eine Stunde bei einer statischen Abfrage unproblematisch sein kann. Aktualität entsteht durch erneutes Lesen des Aufgabenstatus und den Neuaufbau der Aktion, nicht durch einen Timer. ## Die Genehmigung muss an den tatsächlichen Aufruf gebunden sein Auch eine neue Anfrage nach dem Entsperren braucht ein eng gefasstes Genehmigungsmodell. Sonst entfernst du nur die verzögerte Wiederholung und ersetzt sie durch eine unklare Berechtigung, mit der der Agent nach dem Klick des Benutzers seine Absicht ändern kann. Eine Genehmigungskarte sollte an die Informationen gebunden sein, die die Sicherheitsbedeutung der Aktion verändern. Bei HTTP gehören dazu normalerweise die Methode, das normalisierte Ziel, die Referenz auf die Zugangsdaten und ein Digest des Anfrage-Bodys. Bei SSH gehören die Identität des Hosts, das Konto, der Befehl oder sein Digest und die Referenz auf die Zugangsdaten dazu. Die Genehmigung sollte außerdem an den Agent-Prozess gebunden sein und schnell ablaufen. Vermeide eine Karte mit dem alleinigen Text «Agent Zugriff auf die Produktion erlauben». Damit genehmigt eine Person eine Kategorie, während der Agent die Details kontrolliert. Jemand kann bereit sein, einem Prozess das Lesen eines Endpunkts zu erlauben, aber nicht den Aufruf eines administrativen Endpunkts unter demselben Hostnamen. Ein praktischer Genehmigungsdatensatz kann so aussehen: ```json { "approval_id": "apr_8c62", "session_id": "ses_31b8", "process_identity": "signed-authority-and-process-instance", "channel": "http", "credential_label": "billing-api", "method": "POST", "destination": "api.example.internal/v1/invoices", "payload_digest": "sha256:...", "expires_at": "2026-07-22T21:16:00Z", "used": false } ``` Das Gateway muss nicht jedes Byte eines großen Payloads anzeigen, um ehrlich zu sein, was genehmigt wird. Es muss die Genehmigung aber an die Bytes binden, die tatsächlich gesendet werden. Eine knappe Zusammenfassung für Menschen kann neben einem Digest stehen. Der Digest schützt die exakte Anfrage vor einer Ersetzung. Verwende für Zugangsdaten mit Genehmigung pro Aufruf einmalige Genehmigungsdatensätze. Markiere die Genehmigung als verwendet, bevor der Versand beginnt, nicht erst nach dem Eintreffen einer Antwort. Bricht eine Verbindung nach dem Versand ab, muss der Agent möglicherweise am Ziel prüfen, ob die Aktion wirksam war. Eine Wiederverwendung der Genehmigung würde doppelte Schreibvorgänge erleichtern. ## Der zu testende Fehlerfall ist ein Entsperren im falschen Moment Der aufschlussreichste Test lautet nicht «Scheitert der Aufruf bei gesperrtem Tresor?», sondern «Was geschieht, wenn sich die Welt verändert, bevor der Benutzer entsperrt?» Richte einen harmlosen Testdienst mit einem Endpunkt ein, der ein Deployment-Ziel protokolliert, und einem weiteren, der das derzeit erlaubte Ziel ändert. Führe dann diese Abfolge aus: 1. Starte eine Agent-Aufgabe, die `POST /deploy` mit `{\"revision\":\"a1b2c3\"}` senden soll. 2. Sperre den Tresor, bevor der Agent den Aufruf sendet. 3. Bestätige, dass das Gateway `VAULT_LOCKED` zurückgibt und der Testdienst nichts empfängt. 4. Ändere die erlaubte Revision auf `d4e5f6`, während der Tresor gesperrt bleibt. 5. Entsperre den Tresor aus einem anderen Grund. 6. Warte, ohne den Agenten zu berühren. Das richtige Ergebnis ist unspektakulär: Der Testdienst empfängt weiterhin nichts. Wenn er ein Deployment für `a1b2c3` erhält, enthält dein Gateway einen Pfad für verzögerte Ausführung. Informiere den Agenten anschließend darüber, dass der Aufruf abgelehnt wurde, lasse ihn die erlaubte Revision erneut lesen und sende eine neue Anfrage. Die erwartete Anfrage lautet jetzt `d4e5f6`. Das Gateway kann dafür die jeweils geltende Sitzungs- oder Aufrufgenehmigung anfordern. Damit ist bewiesen, dass der Wiederherstellungspfad den aktuellen Kontext bewahrt, statt die Zeit der Sperre wie eine unsichtbare Pausetaste zu behandeln. Führe denselben Test für SSH durch. Verwende einen Befehl, der einen harmlosen Marker mit der vorgesehenen Revision schreibt. Teste nicht nur den Verbindungsaufbau. Eine unsichere Implementierung hält oft einen Befehl zurück, nachdem sie einen Schlüssel ausgewählt hat, und führt ihn aus, sobald der Tresor wieder verfügbar ist. Du brauchst den Nachweis, dass der Befehlstext selbst an der Sperrgrenze verworfen wird. ## Lass Clients die Verweigerung nicht verbergen Ein Gateway kann die richtige Entscheidung treffen und trotzdem schlechtes Verhalten erzeugen, wenn seine Clients jeden Fehler zu «Später erneut versuchen» verkürzen. Das Protokoll braucht genügend Struktur, damit Agent-Frameworks und Wrapper-Skripte einen gesperrten Tresor bewusst behandeln können. Agenten sollten im Antwortvertrag drei Anweisungen erhalten. Erstens: Die Aktion hat das Gateway nicht verlassen. Zweitens: Das Gateway hat die Anfrage verworfen. Drittens: Der Agent darf dieselbe Anfrage nicht automatisch wiederholen. Der Wiederherstellungszyklus des Agenten sollte eher so aussehen: ```text if result.error.code == "VAULT_LOCKED": record_blocked_task() ask the user to unlock when appropriate stop this action if user later resumes the task: reread relevant state decide whether the action is still needed create a new request ``` Die Zeile `decide whether the action is still needed` ist entscheidend. Sie darf nicht durch `retry request` ersetzt werden. Ein Agent, der neue Anweisungen erhalten, Dateien bearbeitet, Branches gewechselt oder von einem fehlgeschlagenen Test erfahren hat, braucht jetzt möglicherweise eine andere Aktion oder gar keine Aktion mehr. Bei unbeaufsichtigten Läufen sollte das Gateway die Ablehnung an den Orchestrator zurückgeben und den Lauf in einem blockierten Zustand beenden. Warte nicht im Gateway darauf, dass jemand den Tresor entsperrt. Ein wartender Agent-Prozess hält Speicher und möglicherweise sensible Informationen zurück. Außerdem entsteht der Druck, ein späteres Entsperren als Erlaubnis zur Fortsetzung zu behandeln. Ein sauberer Abbruch gibt dem Menschen die Möglichkeit, die Aufgabe vor der Fortsetzung zu prüfen. Wenn deine Oberfläche eine Benachrichtigung anzeigt, formuliere sie präzise: «Eine Agent-Aktion wurde abgelehnt, weil der Tresor gesperrt war.» Vermeide Schaltflächen mit der Beschriftung «Fortsetzen» oder «Ausstehende genehmigen». Eine Schaltfläche darf den Tresor öffnen oder Sitzungsdetails anzeigen, aber sie darf keine alte Aktion ausführen. ## Logs sollten beweisen, dass nichts gesendet wurde Eine Ablehnung verdient einen Audit-Eintrag, weil sie eine Frage beantwortet, die Betreiber früher oder später stellen werden: Hat der Agent die Aktion nur versucht oder tatsächlich das externe System kontaktiert? Protokolliere den versuchten Kanal, die Identität des Agent-Laufs, die Referenz auf die Zugangsdaten, ein normalisiertes Ziel, das Ergebnis und Zeitstempel. Kennzeichne den Versandstatus eindeutig. Betreiber sollten `denied_before_dispatch` von `dispatch_started`, `remote_rejected` und `completed` unterscheiden können, ohne aus Ausnahmezeichenfolgen Vermutungen ableiten zu müssen. Protokolliere standardmäßig keine Geheimnisse, rohen Autorisierungs-Header, privaten Schlüssel oder vollständigen Bodies. Bei sensiblen Anfrage-Bodies kannst du einen Digest und eine kurze, genehmigte Zusammenfassung speichern, sofern diese ohne Offenlegung von Inhalten erstellt werden kann. Ziel ist es, festzustellen, was geschehen ist, und keine zweite Kopie der Daten aufzubauen, die der Tresor schützen sollte. Eine Audit-Abfrage sollte eine solche Ereignismeldung beantworten können: ```text 21:14:05 session ses_31b8 attempted SSH action using production-deploy 21:14:05 vault gate denied action before dispatch 21:15:41 vault unlocked by local user action 21:16:09 no action dispatched from ses_31b8 ``` Die letzte Zeile kann aus dem Fehlen von Versanddatensätzen abgeleitet werden. Explizite Endzustände beschleunigen Untersuchungen aber und verringern Unklarheiten. Wenn du ein Hash-verkettetes Journal verwendest, überprüfe die Kette bei der Untersuchung eines Vorfalls ebenso wie bei Routineprüfungen. Manipulationsnachweise sind wenig wert, wenn niemand sie nutzt, sobald der Eintrag wichtig wird. Sallyports Trennung zwischen einem Sessions-Journal für Läufe und einem Activity-Journal für einzelne Aufrufe passt gut zu diesem Problem. Eine Ablehnung wegen eines gesperrten Tresors gehört sowohl zur Historie des Laufs als auch zur Spur auf Aktionsebene. Die Offline-Prüfung `sp audit verify` ermöglicht es einem Team außerdem, die Integrität dieser Historie zu testen, ohne den Tresor zu öffnen. ## Komfortwarteschlangen schaffen ein zweites Autorisierungssystem Sobald ein Gateway Anfragen zur späteren Freigabe speichert, sammeln sich Regeln an: Wie lange bleiben Anfragen bestehen? Wer darf sie freigeben? Muss der ursprüngliche Prozess noch existieren? Darf sich der Inhalt ändern? Was geschieht nach einem Neustart? Gibt ein Entsperren eine Anfrage oder alle Anfragen frei? Diese Regeln sind in Wahrheit eine Richtlinien-Engine. Sie sind für Benutzer schwer zu erklären, weil jede Ausnahme die Bedeutung des Entsperrens verändert. Ein kurzes Zeitlimit behebt das Bedeutungsproblem nicht. Auch die Forderung, dass der ursprüngliche Prozess weiterlaufen muss, löst es nicht, denn der Prozess kann kompromittiert sein oder schlicht mit einem veralteten Kontext arbeiten. Halte das Design kleiner. Die Tresorschranke verweigert alle Aktionen, solange der Tresor gesperrt ist. Eine neue Prozesssitzung kann eine Genehmigung erfordern. Ein Zugangsschlüssel mit Genehmigung pro Aufruf verlangt jedes Mal eine ausdrückliche Bestätigung. Alle anderen Komfortfunktionen gehören auf die Seite des Agenten, als Wiederherstellung einer Aufgabe, bei der der Agent seinen Plan neu erstellen muss und der Mensch sehen kann, was sich geändert hat. Das gibt Benutzern außerdem eine verlässliche Gewohnheit: Das Entsperren stellt die Möglichkeit wieder her, neue Aktionen zu prüfen. Es gibt niemals Aktionen frei, deren Warteschlange sie vergessen haben. Mit diesem mentalen Modell können Menschen gute Entscheidungen treffen. Schwieriger wird es, wenn der Sperrbildschirm zugleich als versteckte Arbeitswarteschlange dient. ## Der sichere Weg muss weniger lästig sein als der unsichere Teams bauen Warteschlangen, weil ein harter Fehler während der normalen Entwicklung störend wirken kann. Behebe diese Reibung, ohne ausführbare Anfragen aufzubewahren. Beschränke die Sitzungsautorisierung auf die Lebensdauer des Agent-Prozesses, damit ein Entwickler nicht jeden gewöhnlichen Aufruf genehmigen muss. Verlange eine Bestätigung pro Aufruf nur für Zugangsschlüssel, bei denen bewusste Reibung sinnvoll ist, etwa bei Produktionsadministration oder externer Veröffentlichung. Gib eine klare Ablehnung zurück, die es dem Agenten erlaubt, blockierte Arbeit in verständlicher Sprache zu melden. Biete dem Benutzer eine Möglichkeit, den Tresor zu entsperren, die Agent-Sitzung zu prüfen und die Aufgabe bewusst fortzusetzen. Formuliere anschließend die Anweisungen für Agenten eindeutig. Sage ihnen, dass Zugangsdaten außerhalb ihres Kontexts bleiben, dass ein Ergebnis mit gesperrtem Tresor die versuchte Aktion beendet und dass eine spätere Aktion nach der Prüfung des aktuellen Zustands neu erstellt werden muss. Eine Agent-Anweisung kann die Regel nicht erzwingen, sie verringert aber sinnlose Wiederholungen und macht das Protokollverhalten leichter handhabbar. Der Test für dieses Design ist einfach. Wenn eine Person den Tresor abgelenkt, müde oder wegen einer anderen Aufgabe entsperrt, darf keine frühere Agent-Aktion stattfinden. Wenn das nicht stimmt, entferne die Warteschlange, bevor daraus ein Vorfallsbericht wird.