Human-in-the-Loop

Sicherheitsziel

Human-in-the-Loop (HITL), also menschliche Freigabe, stellt vor ausgewählte folgenreiche oder mehrdeutige Agentenaktionen eine informierte menschliche Entscheidung, bevor sie wirksam werden. Die Kontrolle beantwortet drei Fragen, die keiner anderen Kontrolle auf dieser Website gehören: wann eine menschliche Entscheidung erforderlich ist, welche Belege die prüfende Person sehen muss, um gut zu entscheiden, und wie diese Entscheidung an genau die Operation gebunden wird, die ausgeführt wird.

HITL ist ein zusätzliches Gate für ausgewählte Aktionen, nicht das Basis-Berechtigungsmodell. Die deterministische Agentenautorisierung bleibt maßgeblich dafür, ob eine konkrete Aktion überhaupt ausgeführt werden darf, Least Privilege begrenzt, wie viel Befugnis existiert, und die Informationsflusskontrolle entscheidet, ob Daten von einer Quelle zu einer Senke fließen dürfen. Menschliche Freigabe setzt auf diese Kontrollen auf und ersetzt keine davon.

Zuständigkeitsgrenzen

Wenn HITL die erste Stelle ist, an der eine gewöhnliche unautorisierte Aktion auffällt, fehlt die Autorisierung. Jede Freigabeanfrage sollte bereits eine Anfrage sein, die die deterministische Policy für sich genommen erlauben würde und die HITL wegen ihres Risikos zusätzlich einer Beurteilung unterzieht.

Bedrohungsmodell

Die adressierten Bedrohungen sind jene, auf die alle Agenten-Angriffsartikel dieser Website hinauslaufen: Ein Agent, beeinflusst über indirekte Inhalte oder Tool-Ausgaben, schlägt eine Aktion vor, die innerhalb seiner Befugnis liegt, aber für die Aufgabe falsch ist. Eine zweite Klasse von Bedrohungen zielt auf den Freigabeschritt selbst.

Vertrauensmodell

Maßgebliche Metadaten und variable Inhalte bleiben während der gesamten Prüfung getrennt. Die Entscheidung der prüfenden Person ist ein authentifiziertes Systemereignis. Der Vorschlag, auf den sie sich bezieht, bleibt variabler Inhalt.

Ein authentifizierter initiierender Nutzer macht seinen Aufgabeninhalt nicht zu Systeminhalt. Plan, Vorschlag und Begründung des Modells sind variabel. Identität, Policy-Entscheidung, Risikostufe und Provenienzlabels stammen aus maßgeblichen Quellen. Die menschliche Entscheidung wird als authentifiziertes Ereignis erfasst, doch die Freigabe eines Nachrichtentexts, eines Diffs oder einer Zusammenfassung stuft diese Nutzdaten nicht als vertrauenswürdig ein. Die Ausführung bleibt hinter deterministischer Durchsetzung.

Freigabe ist keine Autorisierung

Die Autorisierung läuft vor der Freigabeanfrage und nach der Freigabe erneut, zum Ausführungszeitpunkt. Lehnt die Policy ab, wird die Aktion nicht ausgeführt, egal wer freigegeben hat. Freigabe kann ein Ergebnis also einengen, aber nie erweitern.

Freigabe ist keine Fähigkeit

Ein Klick auf Freigeben darf kein Credential erzeugen, keinen Scope hinzufügen und kein Tool freischalten, das der Agent unter Least Privilege nicht bereits hatte. Braucht eine Aktion Befugnisse, die dem Agenten fehlen, ist das eine Bereitstellungsfrage mit eigener Prüfung, die kein Freigabedialog löst. Die Ausführung nutzt dieselbe begrenzte Identität und dieselben Zugangsdaten wie ohne Freigabe.

Wer entscheidet, dass Freigabe nötig ist

Das Modell darf nicht entscheiden, ob eine Aktion eine Freigabe braucht. Ein Modell, das sagen kann "geringes Risiko, keine Prüfung nötig", gibt einer eingeschleusten Anweisung dieselbe Macht. Die Pflicht wird durch deterministische Policy außerhalb des Modells bestimmt, aus aufgelöster Aktion, Parametern, Principal, Datenklassifizierung und relevantem Zustand.

Kriterien für Risikostufen

Es gibt keine universelle Liste freigabepflichtiger Aktionen. Jedes Deployment definiert eigene Stufen. Häufig höher eingestufte Kategorien sind etwa die folgenden, ausdrücklich nur als Beispiele:

Die Sicherheitshinweise des Microsoft Agent Framework empfehlen, als Herstellerhinweis, ebenfalls eine Freigabe für risikoreiche Tools und nennen Nebenwirkungen und Datensensibilität als Kriterien. Stufen sollten sich nach Folgen und Umkehrbarkeit richten, nicht allein nach dem Tool-Namen.

Exact-Action-Bindung

Eine Freigabe hat nur Bedeutung, wenn sie für die vollständig aufgelöste Operation gilt. Die Absicht "Bericht senden" freizugeben, gibt keinen bestimmten Empfänger, Anhang und Text frei.

Wie die Bindung dargestellt wird, variiert: ein kanonischer Aktions-Digest, ein serverseitig gehaltener Aktionsdatensatz oder ein versioniertes Anfrageobjekt sind möglich. Entscheidend ist die Eigenschaft, nicht der Mechanismus: Der Ausführende muss prüfen können, dass das Ausgeführte dem Freigegebenen entspricht.

Wesentliche Änderung, TOCTOU und erneute Freigabe

Zwischen Freigabe und Ausführung kann sich die Lage ändern. Ein späterer Planungsschritt kann einen Parameter umschreiben, ein Empfänger-Alias anders auflösen, eine Datei ersetzt werden oder ein Saldo sinken. Das ist ein Time-of-Check-to-Time-of-Use-Problem (TOCTOU). Jede wesentliche Änderung vor der Ausführung macht die Freigabe ungültig und erfordert eine erneute Bewertung durch die Policy und, falls weiterhin nötig, eine neue menschliche Entscheidung.

Was wesentlich ist, legt die Policy fest, nicht das Modell. Ein sinnvoller Standard: Jede Änderung an einem gebundenen Feld ist wesentlich, ebenso jede Änderung an einem Zustand, von dem die Entscheidung abhing.

Informierter Prüfkontext

Prüfende sind nur so gut wie die Belege vor ihnen. Die Prüfoberfläche sollte klar getrennte Gruppen zeigen.

Auch das vom initiierenden Principal formulierte Aufgabenziel sollte sichtbar sein, damit Prüfende Auftrag und Vorschlag vergleichen können.

Vorschau und Diff

Wo sinnvoll, sollte die Wirkung gezeigt werden statt einer Beschreibung: die genaue Nachricht mit Empfängern, ein feldgenauer Diff eines Datensatzes, die Dateien, die eine Löschung entfernt. Eine Vorschau muss aus der gebundenen Aktion selbst erzeugt werden, nicht aus einer vom Modell verfassten Zusammenfassung. Kann eine Vorschau die Wirkung nicht getreu abbilden, etwa bei großen Batch-Operationen, sollte das offen gesagt und stattdessen Umfangszahlen und Stichproben gezeigt werden.

Identität, Berechtigung und Funktionstrennung der Prüfenden

Freigaben sollten von einer authentifizierten Person kommen, deren Berechtigung für die Risikoklasse per Policy bestimmt wird. Für manche Klassen, etwa Finanztransfers oder Berechtigungsvergaben, ist Funktionstrennung angemessen: Der initiierende Principal sollte nicht die einzige freigebende Instanz der eigenen folgenreichen Aktion sein. Delegierte Freigabebefugnis sollte explizit, begrenzt und dokumentiert sein, nicht aus Jobtitel oder Chatkontext abgeleitet.

Entscheidungsoptionen jenseits von Freigabe und Ablehnung

Freigabeermüdung, Durchwinken und Bündelung

Ein Freigabeschritt, der bei allem auslöst, gewöhnt Menschen ans Durchklicken. Ermüdung ist ein Designergebnis, kein Versagen der Nutzer. Das Prüfvolumen sollte dem Risiko entsprechen, Freigaben für Aktionen, die deterministische Kontrollen bereits sicher abdecken, sollten entfallen, und unzusammenhängende folgenreiche Aktionen sollten nicht in einer Entscheidung gebündelt werden. Ist Bündelung unvermeidbar, sollte auch eine Sammelfreigabe an eine aufgezählte, feste Menge von Aktionen gebunden sein.

Täuschende Prüfoberflächen

Gegenmaßnahmen sind strukturell: Systemfelder aus maßgeblichen Daten an festen Positionen darstellen, variable Inhalte sichtbar trennen, Freigabeanfragen über einen authentifizierten Kanal zustellen und das Modell nie die Bedienelemente steuern lassen.

Mehrstufige und Multi-Agent-Workflows

Die Freigabe von Aktion A gibt B oder C nicht frei. Die Freigabe einer Delegation von Agent A an Agent B gibt nicht frei, dass B weiter an C delegiert. Jede wesentlich eigenständige Aktion oder Übergabe wird separat gegen die Policy geprüft, und jede von der Risikostufe erfasste bekommt ein eigenes Gate. Die Artikel zu Multi-Agent und KI-Agenten zeigen, warum Ketten Einfluss verstärken; HITL darf nicht der Schritt werden, der eine Kette in ein pauschales Ja zusammenfasst.

Wiederholungen, Schleifen und Lebensdauer von Freigaben

Konzeptionell sollte eine Freigabe einmalig nutzbar, an eine Aufgabe gebunden und kurzlebig sein. Ein Wiederholungsversuch nach einem Fehler, ein Schleifendurchlauf oder ein fortgesetzter Workflow darf eine frühere Freigabe nicht stillschweigend wiederverwenden. Ob das über Einmal-Kennungen, Ablaufzeiten oder serverseitigen Zustand durchgesetzt wird, ist eine Implementierungsentscheidung; die Anforderung ist, dass der Ausführende eine frische von einer veralteten Freigabe unterscheiden kann.

Zeitüberschreitung und ausbleibende Antwort

Bei folgenreichen Aktionen bedeutet keine Antwort nein. Eine Anfrage, die abläuft, abgebrochen wird oder nicht zugestellt werden kann, sollte die Aktion unausgeführt und die Aufgabe in einem klaren Zustand lassen, nie standardmäßig zur Ausführung durchfallen.

Abbruch und Widerruf vor der Ausführung

Auch eine freigegebene Aktion muss gegebenenfalls gestoppt werden. Prüfende, Betreiber oder automatisierte Signale sollten eine ausstehende freigegebene Aktion vor ihrer Ausführung abbrechen können, etwa wenn neues Risiko entdeckt wird oder sich relevanter Zustand ändert. Ein Abbruch sollte wie jede andere Entscheidung protokolliert werden.

Break-Glass und Vermeidung eines Engpasses

Notfallpfade gibt es, und sie sollten separat gesteuert sein: eigene Berechtigung, enger Umfang, Zeitlimits und vollständiges Audit. Sie sind kein Weg, eine Policy-Ablehnung über den normalen Freigabefluss zu umgehen. Zugleich sollte HITL kein universeller Engpass werden. Braucht alles eine Freigabe, verkommt die Kontrolle zum Ritual. Zuerst in Autorisierung, Least Privilege und Informationsfluss investieren, damit weniger Aktionen überhaupt einen Menschen brauchen.

Menschliche Prüfung ist fehlbar

Menschen übersehen Details, vertrauen flüssigen Erklärungen und geben unter Zeitdruck frei. Deshalb bleiben deterministische Kontrollen vor und nach der menschlichen Entscheidung maßgeblich. HITL ergänzt Urteilsvermögen, wo eine Policy Kontext nicht ausdrücken kann; es macht das System nicht allein sicher.

Audit-Nachvollziehbarkeit

Durchgespieltes synthetisches Szenario

Alle Daten sind synthetisch. Ein Support-Operations-Agent bearbeitet ein Ticket, dessen angehängter Text eine eingeschleuste Anweisung enthält. Er schlägt vor, einen Kundendatenexport an eine externe Adresse zu mailen. Die deterministische Autorisierung erlaubt den Aktionstyp Mail senden für diesen Principal grundsätzlich, doch die Policy stuft einen externen Versand mit personenbezogenem Anhang als freigabepflichtig ein.

Benigner Fall: Ein Agent schlägt eine Erstattung von synthetischen 40 Einheiten auf das verifizierte ursprüngliche Zahlungsmittel einer verifizierten Bestellung vor. Die Policy erlaubt das oberhalb eines Schwellenwerts nur mit Freigabe. Die prüfende Person gibt die gebundene Aktion frei. Vor der Ausführung bestätigt der Ausführende, dass Bestellstatus und Betrag unverändert sind und die Autorisierung weiterhin zustimmt, und führt dann mit den normalen begrenzten Zugangsdaten des Agenten aus.

Tests und Metriken

Jede Eigenschaft wird einzeln gemessen, mit explizitem Nenner und ohne zusammengesetzten Score.

Zum Üben dieser Eigenschaften in kontrollierter Umgebung ist das Lab Menschliche Freigabe eine deterministische Simulation zu Exact-Action-Bindung, Nachweisen für Prüfende, veralteten Freigaben nach wesentlichen Änderungen, vom Modell verfassten Freigabebehauptungen und fester Batch-Prüfung.

Umsetzungs-Checkliste

Standards und Quellen

Zur Quellennutzung: Das NIST AI RMF wird für den Governance-Grundsatz zitiert, dass Rollen und Prozesse menschlicher Aufsicht definiert und dokumentiert sind; es definiert keine spezifische HITL-Kontrolle, und keine wird unterstellt. OWASP-Einträge sind Risiko-Frameworks, keine HITL-Standards. Die Microsoft-Seiten sind Herstellerleitlinien: Die Agent-Framework-Sicherheitsseite empfiehlt Freigaben für risikoreiche Tools, und MCSB v2 AI-5 empfiehlt menschliche Prüfung und Freigabe für kritische Aktionen; produktspezifische Mechanismen werden hier nicht verallgemeinert.

Häufige Fragen