Welche Agentenaktionen sperren Teams hinter menschliche Freigabe, und wie oft stoppt eine Sperre tatsächlich etwas?

Offene Frage

Die zitierte Spezifikation des Model Context Protocol besagt, dass stets eine Person im Loop sein sollte, die Tool-Aufrufe ablehnen kann, und dass Anwendungen Bestätigungsabfragen anzeigen sollten, und der zitierte OWASP-Eintrag zu Excessive Agency empfiehlt Human-in-the-Loop-Kontrolle für Aktionen mit hoher Tragweite. Beides ist Gestaltungsleitlinie; keines berichtet, wie sich Sperren im Betrieb verhalten. Genehmigungsmüdigkeit ist die üblicherweise genannte Fehlerart: Eine Person, die gebeten wird, jeden Aufruf zu bestätigen, hört auf, die Aufrufe zu lesen. Was fehlt, sind Betriebsdaten von Agenten im regulären Einsatz (Coding-Agenten, Support-Automatisierung, Datenpipelines, Browser-Agenten):

• Welche Tool-Aufrufe gesperrt werden: nach Tool-Name, nach Argumentmuster (ein Pfad ausserhalb des Workspace, ein Empfänger ausserhalb der Organisation), nach Betragsschwelle, oder durch eine Policy-Engine, die jeden Aufruf bewertet?
• Wie viele Freigaben eine Person pro Stunde oder pro Aufgabe bearbeitet und wie lange eine typische Freigabe dauert.
• Welcher Anteil der Anfragen abgelehnt wird und in wie vielen Fällen eine Ablehnung eine Aktion verhindert hat, die Schaden angerichtet hätte, im Gegensatz zu einer harmlosen Aktion, die der Agent danach umformuliert hat.
• Ob Teams, die Sperren von Tool-Namen auf Argumentmuster oder Schwellenwerte verlagert haben, weniger Abfragen ohne weniger erkannte Fälle sahen.
• Ob eine Freigabe als Zustimmung für den Rest einer Sitzung gewertet wird und was geschah, wenn dies der Fall war.

Ohne solche Zahlen ist jede Sperrpolicy eine Vermutung über den Zielkonflikt zwischen Durchsatz und dem einen Aufruf, der hätte gestoppt werden sollen.

Was eine nützliche Antwort enthält

Aufgabe und Toolset des Agenten; die Sperrregel genau wie konfiguriert, einschliesslich etwaiger Bedingungen auf Argumentebene; der Beobachtungszeitraum und die Anzahl der Läufe; Zahlen zu Abfragen, Freigaben und Ablehnungen; Beispiele dafür, was Ablehnungen erkannt haben und was durch eine Freigabe hindurchgerutscht ist; jedes Mass für den auf Freigaben verwendeten Zeitaufwand; sowie die danach vorgenommenen Änderungen an den Regeln, mit Begründung. Berichte eines einzelnen Teams sind nützlich, wenn sie dies angeben; Vorschläge ohne Betriebserfahrung sollten als solche gekennzeichnet werden.