Ein Genehmigungslatenz-Budget für sicherere Agentenaktionen

Genehmigungen für Agenten scheitern auf zwei entgegengesetzte Arten. Muss jede Aktion von einer Person bestätigt werden, verbringt der Agent seinen Tag damit, hinter einer Prüfwarteschlange zu warten. Entfernt man den Entscheidungspunkt, weil Warten stört, erhält der Agent Befugnisse, die niemand sinnvoll überwachen kann.

Ein Genehmigungslatenz-Budget verhindert beide Probleme. Es legt fest, wie lange eine menschliche Entscheidung für eine bestimmte Klasse von Agentenaktionen dauern darf, misst, wohin diese Zeit fließt, und erzwingt eine Neugestaltung, wenn Routinearbeit nicht in den Rahmen passt. Das Budget ist kein Ziel, damit Menschen schneller klicken. Es ist eine Vorgabe für den Ablauf und für die Befugnisse, die du einem Agenten gibst.

Ich habe erlebt, wie Teams eine Genehmigungsaufforderung als Beweis für Kontrolle behandelten und anschließend feststellten, dass ein Entwickler während seiner eigenen Arbeit zwanzig fast identische Anfragen bestätigte. Diese Person prüft nicht mehr. Sie fungiert als langsames Relais. Die Lösung ist selten eine bessere Erinnerungsbenachrichtigung. Meist braucht es klarere Befugnisse, weniger unnötige Aufrufe und einen eindeutigen Eskalationsweg für Aktionen, bei denen Reibung sinnvoll ist.

Ein Genehmigungslatenz-Budget ist eine Frist für eine menschliche Entscheidung

Ein Genehmigungslatenz-Budget ist die maximal akzeptable Zeit zwischen dem Moment, in dem eine Anfrage prüfbar wird, und der endgültigen Entscheidung, sie zu erlauben oder abzulehnen. Es muss je nach Aktionsklasse unterschiedlich ausfallen. Das Lesen eines Pull-Requests, das Erstellen einer vorübergehenden Testressource und das Ändern einer Zugriffseinstellung in der Produktion haben weder dieselbe Dringlichkeit noch dieselben Folgen.

Behandle das Budget als Teil des Aktionsvertrags. Braucht ein Agent innerhalb von zwei Minuten eine Antwort, damit eine interaktive Aufgabe weiterläuft, muss das System die Aktion entweder innerhalb von zwei Minuten leicht beurteilbar machen oder während der normalen Arbeit gar nicht erst danach fragen. Kann eine Aufgabe gefahrlos bis zum Morgen warten, sollte sie keine störende Aufforderung auslösen.

Das Budget besteht aus drei Teilen:

• Wartezeit in der Warteschlange: Zeit vom Erstellen der Anfrage bis zum Öffnen durch eine prüfende Person.
• Entscheidungszeit: Zeit vom Öffnen der Anfrage bis zur Genehmigung oder Ablehnung.
• Ausführungszeit: Zeit von der Entscheidung bis zum Beginn der Aktion oder ihrem Fehlschlagen.

Viele Teams fassen diese Werte zu einer Zahl zusammen und nennen sie Genehmigungszeit. Dadurch bleibt verborgen, wo angesetzt werden muss. Eine Wartezeit von zwanzig Minuten in der Warteschlange verlangt Änderungen an Weiterleitung, Zuständigkeit oder Planung. Eine Entscheidungszeit von zwanzig Minuten bedeutet, dass der Anfrage Kontext fehlt, sie zu weitreichende Befugnisse enthält oder eine Entscheidung verlangt, die nie bei einem gestressten Menschen hätte landen dürfen.

Lege Budgets anhand der Fristen der Arbeit fest, nicht anhand einer abstrakten Sicherheitsstufe. Eine mögliche Ausgangstabelle sieht so aus:

Das sind Beispiele, keine allgemeingültige Richtlinie. Ein Deployment-Team mit Bereitschaftsdienst kann ein anderes Zeitfenster brauchen als eine einzelne Person. Wichtig ist, die Erwartung festzulegen, bevor sich die Warteschlange bildet.

Verwende dafür nur dann ein Service-Level-Agreement, wenn du es auch personell abdecken kannst. Ein Budget ist eine Designgrenze. Es zeigt dir, dass eine Aufgabe nicht von einer interaktiven Entscheidung abhängen darf, wenn die entscheidungsberechtigten Personen schlafen, in Besprechungen sitzen oder einen Vorfall bearbeiten. Der Agent sollte das ebenfalls wissen. Er kann die Anfrage vorbereiten, einen sicheren alternativen Weg wählen oder mit einer verständlichen Erklärung anhalten. Er sollte nicht jede Minute dieselbe Anfrage erneut stellen.

Miss den Lebenszyklus der Anfrage statt eines Mausklicks

Du kannst Verzögerungen bei Genehmigungen nicht verbessern, wenn deine Zeitstempel erst beginnen, sobald eine Benachrichtigung ein Telefon erreicht. Starte beim Erstellen einer prüfbaren Aktion durch das System und zeichne anschließend jeden Zustandswechsel mit einer Anfrage-ID auf, die Wiederholungen und Aktualisierungen der Oberfläche überlebt.

Verwende einen kleinen Ereignisdatensatz wie diesen. Die Felder sind bewusst unspektakulär. Unspektakuläre Datensätze lassen sich sortieren und verknüpfen und überstehen eine Untersuchung nach einem Vorfall.

{
  "request_id": "req_7f31",
  "run_id": "run_241",
  "action_class": "bounded_write",
  "target": "issue tracker/project-amber",
  "created_at": "2025-03-08T14:02:01Z",
  "presented_at": "2025-03-08T14:02:03Z",
  "opened_at": "2025-03-08T14:09:18Z",
  "decided_at": "2025-03-08T14:10:06Z",
  "decision": "allow",
  "executed_at": "2025-03-08T14:10:07Z",
  "outcome": "success"
}

Mit dieser Struktur berechnest du die Wartezeit in der Warteschlange als opened_at - presented_at, die Entscheidungszeit als decided_at - opened_at und die Ausführungszeit als executed_at - decided_at. Behalte auch created_at. Damit findest du einen stilleren Fehler: einen Broker, der eine Anfrage zurückhält, bevor sie jemand sehen kann.

Eine Abfrage kann diese Messungen auch ohne komplizierte Analytik ausdrücken:

SELECT
  action_class,
  percentile_cont(0.50) WITHIN GROUP (ORDER BY opened_at - presented_at) AS p50_queue_wait,
  percentile_cont(0.95) WITHIN GROUP (ORDER BY opened_at - presented_at) AS p95_queue_wait,
  percentile_cont(0.95) WITHIN GROUP (ORDER BY decided_at - opened_at) AS p95_decision_time,
  count(*) FILTER (WHERE decision = 'deny') AS denied,
  count(*) AS total
FROM approval_requests
WHERE created_at >= current_timestamp - interval '14 days'
GROUP BY action_class;

Die genaue Syntax für Perzentile unterscheidet sich je nach Datenbank. Die Messung bleibt dieselbe. Berichte für jede Aktionsklasse p50 und p95 sowie Anzahl und Ablehnungsrate. Ein Durchschnitt lässt eine fünf Sekunden dauernde Erfahrung neben einigen Anfragen, die neunzig Minuten gewartet haben, gut aussehen. p95 zeigt dir, ob der langsame Rand echte Aufgaben blockiert.

Zeichne außerdem auf, ob der Agent die Aufgabe abgebrochen, wiederholt oder aufgegeben hat, bevor die Entscheidung eintraf. Eine verspätete Genehmigung, die ausgeführt wird, nachdem der Agent bereits einen anderen Weg gewählt hat, ist schlimmer als eine gewöhnliche Ablehnung. Sie erzeugt eine Aktion, die nicht mehr zur aktuellen Arbeit der entwickelnden Person passt.

Belohne Prüfer nicht allein für eine kürzere Entscheidungszeit. Sonst wirken sorgfältige Ablehnungen wie ein Leistungsproblem. Betrachte die Verteilung von Genehmigungen, Ablehnungen, Abläufen und Rücknahmen gemeinsam. Ein plötzlicher Rückgang der Ablehnungen bei sehr kurzen Lesezeiten bedeutet oft, dass Menschen gelernt haben, mit einem Klick auf «Genehmigen» eine lästige Aufforderung loszuwerden.

Wartezeit und Prüfzeit weisen auf unterschiedliche Fehler hin

Wartezeit in der Warteschlange und Entscheidungszeit laufen auf derselben Uhr, haben aber unterschiedliche Ursachen und Zuständigkeiten. Wer sie zusammenfasst, setzt am falschen Punkt an.

Die Wartezeit in der Warteschlange wächst, wenn Anfragen bei der falschen Person landen, zu viele Menschen annehmen, jemand anderes werde entscheiden, Benachrichtigungen außerhalb der Arbeitszeit eintreffen oder ein Prüfer keinen Grund sieht, seine aktuelle Aufgabe zu unterbrechen. Mehr Benachrichtigungen verschlimmern das oft. Sie verteilen dieselbe unklare Verantwortung auf noch mehr Menschen.

Die Entscheidungszeit wächst, wenn die Karte einen Prüfer dazu zwingt, die Absicht des Agenten selbst zu rekonstruieren. Eine Anfrage wie «POST /v1/resources» ist nicht prüfbar. Die prüfende Person muss das Ziel, die Operation, die Anzahl der Objekte, die verwendete Berechtigung und die sichtbare Folge kennen. Sie sollte kein Terminal öffnen, Quellcode untersuchen und herausfinden müssen, ob die Anfrage einen Entwurf erstellt oder eine Nachricht an Kunden sendet.

Eine gute Genehmigungskarte beantwortet fünf Fragen in klarer Sprache:

1. Welcher Agentenlauf hat die Anfrage erstellt und welcher signierte Prozess hat diesen Lauf gestartet?
2. Welches externe Ziel erhält die Aktion?
3. Was ändert sich oder welche Daten verlassen das Gerät?
4. Welche begrenzte Berechtigung erlaubt die Aktion?
5. Was passiert, wenn der Prüfer sie ablehnt oder nichts tut?

Mehr Details bedeuten nicht automatisch besseren Kontext. Ein vollständiger Roh-Payload kann das einzige wichtige Feld verbergen. Zeige zuerst eine kurze Beschreibung der Folge. Danach kann der Prüfer bei Bedarf den Befehl, den Endpunkt, von Geheimnissen bereinigte Header und den Payload untersuchen. Wer eine Löschung genehmigt, braucht die Namen der betroffenen Objekte. Wer einen HTTP-Lesezugriff genehmigt, braucht Host, Pfad und Abfragebereich. Jede Aktion braucht Belege, die zu ihrem Risiko passen.

Der wiederkehrende Fehler besteht darin, die Wartezeit durch eine weitreichende Sitzungsfreigabe zu verkürzen, obwohl der Prüfer wegen der Unklarheit der Aktion langsam war. Damit wird ein Kontextproblem zu einem Berechtigungsproblem. Verbessere zuerst die Beschreibung und die Grenze der Aktion.

Der umgekehrte Fehler kommt ebenfalls vor: Teams verlangen für hundert gewöhnliche Lesezugriffe jeweils eine eigene Bestätigung, weil sich die Warteschlange unsicher anfühlt. Unsicher wird sie, weil sie Gewöhnung erzeugt. Wiederholte Aufforderungen mit geringen Folgen bringen Prüfer dazu, nach Form und Zeitpunkt statt nach Inhalt zu genehmigen. Diese Gewohnheit bleibt bestehen, wenn eine folgenschwere Anfrage auftaucht.

Eine Prüfwarteschlange zeigt, dass der Ablauf eine andere Form braucht

Eine Warteschlange verzögert nicht nur die Arbeit. Sie verändert das Verhalten des Agenten und des Menschen. Der Agent wiederholt Anfragen, teilt eine Aufgabe in kleinere Aufrufe auf oder hält einen unvollständigen Plan zurück. Der Mensch sieht einen wachsenden Stapel und beginnt, ihn in Gruppen abzuarbeiten. Jede Antwort lässt die Warteschlange weniger beunruhigend wirken, bis sich eine ungewöhnliche Anfrage zwischen vertrauten verbirgt.

Betrachte einen typischen Fehler. Ein Agent soll aus Daten eines Issue-Trackers einen Release-Hinweis vorbereiten. Zuerst liest er die Projektliste, ruft anschließend jedes Issue ab, liest Kommentare zu den ausgewählten Issues und erstellt danach einen Entwurf. Ein Ablauf, der für jeden HTTP-Aufruf eine Genehmigung verlangt, macht aus einer überschaubaren Aufgabe Dutzende Aufforderungen.

Um 9:30 genehmigt ein Entwickler die ersten Lesezugriffe sorgfältig. Um 9:45 beginnt eine Besprechung. Um 10:30 hat der Agent Wiederholungen und verwandte Aufrufe angereiht. Der Entwickler kommt zurück, sieht eine Wand aus Anfragen an denselben Dienst und genehmigt sie schnell. Eine Anfrage erstellt einen öffentlichen Kommentar statt eines Entwurfs, weil Endpunkt und gewünschte Folge im Rohtext der Anfrage verborgen waren. In dieser Warteschlange konnte der Entwickler sie kaum erkennen.

Die schlechte Entscheidung begann vor dem öffentlichen Kommentar. Der Ablauf ließ Routine-Lesezugriffe mit einem sichtbaren Schreibzugriff konkurrieren. Außerdem musste der Mensch den Kontext über eine lange Unterbrechung hinweg behalten. Das ist ein Designfehler, kein Versagen des Prüfers.

Behebe ihn, indem du die Arbeit nach sinnvoller Absicht gruppierst. Eine Lesesitzung kann einen benannten Dienst und die Dauer einer Aufgabe abdecken, sofern ihre Berechtigung keine Änderungen erlaubt. Das Erstellen eines Entwurfs kann eine ausdrückliche Entscheidung mit Speicherort und Zielgruppe des Entwurfs verlangen. Eine öffentliche Veröffentlichung sollte getrennt bleiben, weil ihre Folge die Prüfungsfrage verändert.

Löse das nicht mit der pauschalen Anweisung, ein Agent dürfe «den Issue-Tracker verwenden». Dieser Satz verbirgt zu viel. Er sagt dem Prüfer nicht, ob der Agent private Issues lesen, Labels ändern, öffentlich kommentieren oder Daten löschen kann. Namen für Berechtigungsbereiche müssen Aktionen entsprechen, die Menschen später wiedererkennen.

Dasselbe gilt für SSH. Eine Anfrage zum Prüfen eines Servicelogs und eine Anfrage zum Ausführen einer Migration können über dieselbe Verbindung laufen, gehören aber nicht in dieselbe Genehmigungsklasse. Die Identität der Verbindung ist nicht die Identität der Aktion.

Der Genehmigungsumfang sollte den Folgen folgen, nicht dem Transport

Eine gute Genehmigungsgrenze beschreibt, womit eine Person einverstanden ist. HTTP oder SSH, ein Befehl oder ein API-Aufruf und ein lokaler oder entfernter Prozess sind Details des Transports. Sie sind für die Umsetzung wichtig, sagen einem Prüfer aber nicht, ob eine Aktion umkehrbar, extern sichtbar oder teuer ist.

Beginne mit Folgenklassen. Leseoperationen können Daten offenlegen, daher bedeutet «Lesen» nicht automatisch harmlos. Auch Schreibzugriffe unterscheiden sich: Einen privaten Entwurf erstellen, eine Produktionseinstellung ändern und eine Nachricht senden verändert jeweils einen Zustand, erfordert aber eine andere Prüfung. Trenne diese Fälle, bevor du entscheidest, welche Interaktionen dieselbe Genehmigung teilen dürfen.

Begrenze den Umfang anschließend entlang der Dimensionen, die ein Prüfer überprüfen kann:

• Ziel: ein benannter Host, ein Repository, ein Projekt oder eine Umgebung.
• Operation: lesen, Entwurf erstellen, ein bestimmtes Feld aktualisieren oder eine benannte Befehlsfamilie ausführen.
• Objektmenge: die konkreten beteiligten Datensätze, Dateien oder Dienste.
• Dauer: eine Aktion, ein Agentenlauf oder ein kurzes geplantes Zeitfenster.
• Folge: privat, umkehrbar, extern sichtbar oder zerstörerisch.

Vermeide Umfänge, die auf technischen Nebensächlichkeiten beruhen. «POST-Anfragen erlauben» ist eine Transportregel, keine Genehmigungsgrenze. Ein POST kann einen Entwurf erstellen oder ein Konto löschen. «Zugriff auf die Befehlszeile erlauben» hat denselben Fehler. Es gewährt ein Medium für Aktionen statt eines verständlichen Ergebnisses.

Menschen plädieren oft für eine weitreichende Sitzungsfreigabe, weil einzelne Anfragen den Arbeitsfluss unterbrechen. Mit der Unterbrechung haben sie recht. Die Lösung ist jedoch falsch, wenn die Sitzung unterschiedliche Vorgänge vermischen kann. Eine Sitzung passt nur, wenn Ziel und erlaubte Folgen während ihrer gesamten Laufzeit klar erkennbar bleiben. Wechselt ein Agent vom Sammeln von Release-Hinweisen zum Ändern von Repository-Berechtigungen, braucht er eine neue Entscheidung.

Verwende eine Bestätigung pro Aktion, wenn die Folgen auch innerhalb eines ansonsten vertrauenswürdigen Laufs schwerwiegend bleiben. Veröffentlichungen, Löschungen, das Erneuern von Zugangsmaterial, Änderungen der Netzwerkerreichbarkeit und das Senden von Informationen außerhalb des Teams gehören meist dazu. Verwende Einzelbestätigungen nicht als Strafe für ungewohnte Arbeit, sondern dort, wo jeder einzelne Vorgang menschliches Ermessen erfordert.

Gestalte Routinearbeit neu, bevor du Prüfkontrollen lockerst

Wenn die Genehmigungslatenz ihr Budget überschreitet, entferne zuerst Anfragen, die nie interaktiv hätten werden dürfen. Das bedeutet nicht, beliebige Aktionen zu erlauben. Es bedeutet, Routinearbeit so klar zu begrenzen, dass ein Mensch den Lauf oder die Aufgabe statt jedes mechanischen Teilaufrufs genehmigen kann.

Arbeite eine langsame Klasse in dieser Reihenfolge durch:

1. Ziehe die Anfragen mit p95 heran und lies die vollständige Abfolge rund um jede Anfrage. Zähle Wiederholungen und doppelte Aufrufe getrennt von notwendigen Aufrufen.
2. Markiere die erste Aktion, bei der sich die Folge ändert. Das ist oft der richtige Punkt für eine ausdrückliche Entscheidung.
3. Fasse deterministische Lesezugriffe unter einem engen Aufgabenbereich zusammen, mit bekanntem Ziel und einem Ablaufdatum, sobald der Lauf endet.
4. Teile externe Veröffentlichungen, Löschungen, Berechtigungsänderungen und umfangreiche Datenexporte in getrennte Anfragen auf.
5. Teste die Aufgabe erneut mit einer echten prüfenden Person, die den Ablauf nicht entworfen hat. Kann sie das erwartete Ergebnis vor der Genehmigung nicht nennen, begrenze die Anfrage weiter.

Bündel helfen nur, wenn das Bündel selbst prüfbar ist. «Erstelle diese vier Entwurfs-Issues im Projekt Amber» ist ein sinnvolles Bündel, wenn die Karte die vier Issues und ihr Ziel nennt. «Erledige alle verbleibenden Release-Arbeiten» ist kein Bündel, sondern eine offene Delegation.

Lass den Agenten die Grenze eines Bündels nicht allein nach Bequemlichkeit festlegen. Gib ihm ein Aufgabenobjekt mit Ziel, gewünschtem Ergebnis, erlaubten Datenquellen und Ablaufzeit. Der Agent kann die Aufrufe darunter sammeln. Ein Wechsel von Ziel oder Folge muss das Bündel jedoch schließen. Das verbessert auch die Untersuchung nach Vorfällen, weil das Log eine tatsächliche Arbeitseinheit statt eines langen Stroms anonymer Anfragen abbildet.

Geplante Arbeit braucht eine andere Neugestaltung. Muss ein Mensch nachts eine nächtliche Wartungsaktion genehmigen, hat das Team einen vorhersehbaren Fehler geschaffen. Plane entweder ein Prüfungsfenster vor der Ausführung, beauftrage eine Bereitschaftsperson mit einem passenden Budget oder verschiebe die Arbeit. Verkleide unbeaufsichtigte Genehmigungen nicht als Automatisierung.

Die Möglichkeit zu Wiederholungen verdient besondere Aufmerksamkeit. Ein Agent sollte dieselbe ausstehende Anfrage-ID wiederverwenden, solange sich die zugrunde liegende Aktion nicht geändert hat. Für jede Wiederholung eine neue Genehmigungskarte zu erstellen, bläht die Warteschlange künstlich auf und zerstört das Verständnis des Prüfers für die Abfolge. Ändern sich Ziel, Payload, Berechtigung oder beabsichtigte Folge, erstelle eine neue Anfrage und nenne die Änderung.

Der Genehmigungsbildschirm muss die richtige Entscheidung erleichtern

Der Prüfer braucht eine kompakte Absichtserklärung, keine Einladung, einen Agentenlauf rückwärts zu analysieren. Baue den Bildschirm um die Entscheidung herum, die jetzt getroffen werden muss, und biete tiefergehende Belege an, ohne den Prüfer danach suchen zu lassen.

Stelle zuerst die Folge der Aktion dar: «Privaten Release-Notiz-Entwurf im Projekt Amber erstellen» sagt mehr als Methode und Pfad. Zeige das Ziel daneben. Gib an, ob die Aktion Daten liest, ändert, löscht oder sendet. Bei SSH müssen Host und Befehl so angezeigt werden, dass Umleitungen, Dateischreibvorgänge und Berechtigungsänderungen offensichtlich sind.

Zeige außerdem den Berechtigungskontext. Ein Prüfer sollte wissen, ob die Anfrage von einem neuen Agentenprozess oder einem bereits genehmigten Lauf stammt und ob diese Aktion eine besondere Bestätigung erfordert. Die Prozessidentität ist wichtig, weil die Genehmigung eines Agentenprozesses nicht stillschweigend einen anderen Prozess freigeben darf, nur weil dieser dasselbe Protokoll verwendet.

Sallyport verwendet dafür eine feste Entscheidungskette: Ein gesperrter Tresor lehnt jede Aktion ab, ein neuer Agentenprozess erhält standardmäßig eine Sitzungsautorisierung und eine Berechtigung kann für jede Nutzung eine Genehmigung verlangen. Die erste Sitzungskarte stellt die Code-Signatur-Berechtigung des Prozesses an den Anfang. Das ist genau die richtige Information für eine Person, die entscheiden muss, ob dieser Lauf tatsächlich derjenige ist, den sie starten wollte.

Mach den Bildschirm nicht zu einem Editor für Regeln. Eine Person unter Zeitdruck sollte eine konkrete Anfrage genehmigen, ablehnen oder prüfen. Wenn ein Team wiederholt eine Ausnahme braucht, gestalte Aufgabenbereich oder Berechtigungsgrenze außerhalb der Unterbrechung neu. Eine kleine Regelsprache in den Genehmigungsablauf zu setzen bedeutet nur, dass müde Menschen unter Druck Sicherheitsentscheidungen programmieren sollen.

Eine Ablehnung muss verständlich sein. Gib eine Kategorie zurück, mit der der Agent arbeiten kann, etwa abgelaufen, falsches Ziel, engerer Umfang erforderlich oder menschliche Prüfung nötig. Teile private Kommentare des Prüfers standardmäßig nicht mit einem nicht vertrauenswürdigen Agenten. Der Agent braucht genug Information, um weitere Wiederholungen zu stoppen oder eine sichere alternative Aufgabe zu wählen, aber kein Protokoll der internen Überlegungen.

Zuständigkeit und Eskalation festlegen, bevor eine dringende Anfrage eintrifft

Ein Genehmigungsbudget ohne Zuständigkeit bleibt ein Wunsch. Für jede Aktionsklasse braucht es während ihres möglichen Ausführungszeitraums eine Person oder Rotation, die für die Entscheidung verantwortlich ist. Ein Team kann die Prüfung delegieren, aber nicht die Tatsache, dass jemand entscheiden muss.

Lege fest, was an jeder Budgetgrenze geschieht. Bei der Hälfte des Budgets kann das System die zuständige prüfende Person einmal benachrichtigen, wenn die Anfrage noch nicht gesehen wurde. Am Budgetlimit kann eine Aktion mit geringen Folgen ablaufen. Eine folgenschwere Anfrage sollte ablaufen und den Aufgabenverantwortlichen oder die Bereitschaftsrotation benachrichtigen, statt für immer ausstehend zu bleiben. Der genaue Zeitpunkt ist weniger wichtig als ein sichtbarer und begrenzter Zustand.

Sei bei Arbeitszeiten ehrlich. Wenn jemand nachts lokal einen Agenten ausführt und die Aktion die Genehmigung eines Teammitglieds braucht, muss die Aufgabe möglicherweise warten. Das ist akzeptabel. Der Fehler entsteht, wenn die Oberfläche sofortigen Fortschritt suggeriert und den Agenten anschließend an einer unbeaufsichtigten Warteschlange wiederholen lässt.

Eine Eskalation darf niemals Befugnisse erweitern. Eine eskalierte Anfrage geht an eine besser geeignete prüfende Person, nicht auf einen automatischen Genehmigungsweg. Das ist bei Vorfällen besonders wichtig, weil Dringlichkeit dazu verleitet, alle Kontrollen auf einmal zu umgehen. Vorab genehmigte Notfallverfahren sind möglich, sollten aber eine eng begrenzte Aktion, eine benannte Zuständigkeit und eine nachträgliche Prüfung festlegen. «Die Produktion ist kaputt» ist kein Genehmigungsumfang.

Betrachte auch die Kosten für Menschen und nicht nur die Verzögerung des Agenten. Erhält eine Person fast alle Aufforderungen, liegt ein Routingproblem vor, selbst wenn die mittlere Latenz gut aussieht. Sieht jeder Prüfer jede Anfrage, hat das Team einen gemeinsamen Posteingang mit Sicherheitslabels gebaut. Beide Muster führen zu Ermüdung und schwacher Verantwortlichkeit.

Die Warteschlange als Abfolge von Entscheidungen prüfen

Ein brauchbarer Audit-Trail ermöglicht die Rekonstruktion von mehr als der abschließenden Aktion. Er sollte den Agentenlauf, die dem Prüfer vorgelegte Anfrage, die Entscheidung, den tatsächlichen externen Aufruf und jede Stornierung oder Wiederholung zeigen. Ohne diese Abfolge kann ein Team nicht feststellen, ob eine verspätete Genehmigung eine veraltete Aktion ausgelöst hat oder ob der Agent seinen Plan nach einer Ablehnung geändert hat.

Verbinde Genehmigungs- und Aktionsbelege über IDs, aber verwechsle sie nicht. Die Genehmigung beantwortet, wer eine bestimmte Absicht autorisiert hat. Der Aktionsdatensatz beantwortet, was tatsächlich versucht wurde und was das Ziel zurückgegeben hat. Bei einem Agenten, dessen Anfrage halbwegs fehlschlägt, oder bei einem entfernten Dienst, der einen Payload unerwartet interpretiert, braucht eine Untersuchung beides.

Sallyport erstellt sowohl ein Sitzungsjournal als auch ein Aktivitätsjournal aus einem gemeinsamen verschlüsselten, hashverketteten Audit-Log. Der Befehl sp audit verify prüft die Kette offline über den Chiffretext, ohne den Tresorschlüssel zu benötigen. Das ist hilfreich, wenn jemand die Integrität des Logs testen muss, ohne Zugangsdaten für Agenten zu öffnen.

Verwende den Audit-Datensatz in einer wöchentlichen Prüfung von Ausnahmen, nicht als Datenspeicher, den niemand liest. Hole abgelaufene Anfragen, die langsamsten Beispiele mit p95, abgelehnte Aktionen und Aktionen heran, die nach langer Wartezeit ausgeführt wurden. Stelle zu jeder eine konkrete Frage: Entstand die Verzögerung durch Zuständigkeit, unklare Absicht, einen zu großen Umfang oder eine Aufgabe, die anders hätte geplant werden müssen?

Bewerte Menschen nicht nach ihrer Genehmigungsgeschwindigkeit. Bewerte den Ablauf danach, ob er vor Ablauf der Aufgabenfrist eine verständliche Entscheidung bei einer verantwortlichen Person platziert. Wenn wiederholte Prüfungen nur zu routinemäßigen Genehmigungen führen, entferne die Wiederholung. Braucht eine seltene Aktion sorgfältige Überlegung, gib ihr die dafür nötige Zeit, den Kontext und die Zuständigkeit.

Beginne damit, eine Woche lang Zeitstempel für den gesamten Lebenszyklus zu sammeln. Wähle die Aktionsklasse mit der schlechtesten p95-Wartezeit, untersuche zehn vollständige Anfrageabfolgen und ändere die Grenze, die die meisten doppelten Aufforderungen erzeugt hat. Diese Arbeit wird dir mehr sagen als ein weiteres Dashboard.