Human-in-the-loop-Agent-Design: Welche Schritte brauchen menschliche Freigabe?

Der Entwurf einer Feishu-Nachricht ist fertig: Titel, Text und Anhang-Link sind ausgefüllt. Es fehlt nur noch der Klick auf Senden. Genau davor stoppt der Agent bei send_message und wartet auf Ihre Bestätigung.

Eine E-Mail darf automatisch entstehen, aber vor dem Versand an Kunden müssen Empfänger, Betreff, Textzusammenfassung und Anhänge sichtbar sein. Ein CMS-Formular darf ausgefüllt werden, doch submit_form wird von einer Policy gestoppt und wartet auf owner approval. Das wirkt wie ein UI-Button, ist aber ein pausierter Run-Zustand. Der RunState des Agents wird gespeichert und erst nach der Entscheidung fortgesetzt. Wo der Run stoppt, wer freigeben darf und was bei Reject oder Timeout passiert, gehört zur Sicherheitsgrenze des Tool-Systems.

Dieser Leitfaden liefert eine Risikomatrix, eine Liste konkreter Approval-Punkte, ein Pause/Resume-Modell und ein Audit-Feldschema. So wird aus „noch ein Bestätigungsbutton“ ein serialisierbarer, fortsetzbarer und auditierbarer Zustand.

Risikomatrix: Entscheiden, welche Aktionen Approval brauchen

Nicht jede Aktion braucht Approval. Read-only-Aktionen dürfen automatisch laufen; Löschen und Zahlungen sollten stoppen. Fünf Dimensionen reichen als Startpunkt:

Dimension	Klassifizierungsregel	Beispielaktionen
Externe Wirkung	Berührt externe Systeme oder Nutzer	E-Mail senden, Formular absenden, externe API aufrufen, in Feishu/Slack schreiben
Reversibilität	Kann die Aktion zurückgenommen werden?	Record löschen (irreversibel), Draft speichern (reversibel), Zahlung (teilweise über Kompensation), Nachricht senden (irreversibel)
Datensensibilität	Sensibilitätsstufe der Daten	Öffentliche Daten abfragen, interne Records ändern, Nutzerdaten exportieren, Produktionskonfiguration lesen
Geld-/Rechte-Schwelle	Enthält Geld oder Rechteänderungen	Zahlung, Überweisung, Refund, Rechteänderung, Bulk-Operation, User-Daten löschen
Autonomiegrad	Erlaubtes Automationsniveau	Read-only Query (vollautomatisch), Draft schreiben (vollautomatisch), Outbound Message (Bestätigung), Delete/Payment (Approval)

Diese Matrix passt zu OWASP LLM06: excessive functionality, excessive permissions und excessive autonomy. Sie können sie direkt nutzen oder Schwellen an Ihr Geschäft anpassen.

Externe Wirkung: Alles, was andere Systeme oder Personen erreicht, braucht Aufmerksamkeit. Eine E-Mail lässt sich nicht zurückholen. Ein Formular kann eine Bestellung auslösen. Eine externe API kann Daten eines anderen Systems verändern.

Reversibilität: Ein gelöschter Record ist weg; ein Draft lässt sich ändern; eine Zahlung ist oft nur über Refund oder Kompensation rückgängig zu machen.

Datensensibilität: Öffentliche Daten können meist frei gelesen werden. Interne Daten brauchen Schreibkontrolle. Sensible Daten wie Privacy-Daten oder Produktionskonfiguration sollten Approval verlangen.

Geld-/Rechte-Schwelle: Alles mit Geld oder Berechtigungen sollte pausieren. Zahlungen, Transfers, Refunds, Rechteänderungen und Bulk-Operationen sind Hochrisikopunkte.

Autonomiegrad: Reads laufen automatisch. Drafts können ebenfalls automatisch entstehen. Outbound-Aktionen brauchen Confirmation; Delete und Payment brauchen Approval.

Die Matrix ist keine Einmal-Konfiguration. Interne Feishu-Benachrichtigungen können auf Confirmation gesenkt werden; echte Zahlungen bleiben bei Approval plus Zwei-Personen-Review.

Drei reale Szenarien zur Risikoklassifizierung

Fall 1: Feishu-Nachrichtenentwurf

Einen Feishu-Draft zu schreiben ist L0. Er liegt nur im Draft, ist nicht versendet, reversibel und hat keine externe Wirkung. Der Aufruf von send_message an Kunden ist dagegen L2. Die Nachricht ist irreversibel, erreicht externe Nutzer und kann sensible oder falsche Inhalte enthalten. Confirmation vor MCP tools/call ist genau dieses Muster.

Fall 2: E-Mail-Versand

E-Mail-Text generieren ist L0. Es ist nur Text. Der Versand über die Mail-API ist L2 und muss Empfänger, Betreff und Anhänge zeigen. Die Approval-UI darf nicht nur „Senden bestätigen“ sagen; sie muss Evidence und Zusammenfassung anzeigen.

Fall 3: CMS-Formular absenden

Formularfelder ausfüllen ist L0. Noch wurde nichts abgeschickt. Der CMS-API-Submit ist L2 und sollte per Policy auf owner approve warten. Das kann ein Guardrail sein, etwa „Betrag über Schwelle“, oder eine statische Policy: „Alle CMS-Submits brauchen Approval“.

Fall 4: Produktionsdatenbank löschen

Eine Produktionsdatenbank abzufragen ist L0. Es ist ein Read und verändert keine Daten. Ein Delete-API-Call auf Produktion ist L3: starke menschliche Freigabe plus Backup-Audit. Produktionslöschung ist irreversibel, sensibel und nutzerwirksam. Das gehört in Policy-Regeln, nicht nur in Guardrails.

Das Muster: In derselben Aufgabe haben einzelne Schritte unterschiedliche Risiken. Drafts dürfen automatisch sein, Versand braucht Approval, Produktionslöschung braucht Zwei-Personen-Review. Klassifizieren Sie konkrete Aktionen, nicht grobe Aufgaben.

Approval-Punkte definieren: Bis auf Aktionstypen herunterbrechen

Nach der Matrix definieren Sie Approval-Level:

L0 automatisch: Datenbankabfragen, Vektorsuche, Konfigurationslesen; Draft speichern oder Preview erzeugen. Keine externe Wirkung, reversibel, keine sensiblen Daten.

L1 Confirmation: ausgehende Nachrichten oder Daten wie E-Mail, Formular, externe API; Bulk-Reads wie Export oder Massenabfrage. Externe Wirkung, aber kontrollierbar.

L2 Approval: Löschen, Rechteänderungen, Bulk-Delete; Schreiben in Feishu, Slack oder CRM. Irreversibel oder mit hoher externer Wirkung.

L3 Strong Approval + Zwei-Personen-Review: Zahlungen, Refunds, sensible Datenexporte, Produktionskonfiguration ändern, Produktionsdatenbank löschen. Geld oder sensible Daten verlangen stärkere Kontrolle.

Diese Liste passt zu needs_approval im OpenAI Agents SDK und zu MCP Tool-Safety. MCP erwartet sichtbare, ablehnbare Tool Calls und Confirmation für sensible Operationen; das entspricht L2 und L3.

Passen Sie die Liste an:

Wenn eine Feishu-Nachricht nur interne Info ist, kann sie L1 sein.
Wenn ein Delete User-Daten betrifft, bleibt er L2.
Wenn Payment sehr riskant ist, wird es L3 mit Pflichtgrund und Zwei-Personen-Review.

Die Liste bleibt beweglich. Ändern sich Geschäftsregeln, kann „Nachricht senden“ auch aus der Approval-Liste verschwinden.

Approval-Flow als Zustandsmaschine: Pausieren, speichern, fortsetzen

Approval ist kein Pop-up, sondern ein pausierter Run. Wenn ein Tool Call Approval braucht, wird RunState gespeichert und nach der Entscheidung fortgesetzt.

Zustandsdiagramm

Der Flow sieht so aus:

request -> pending -> approved/rejected/timeout -> resume/abort/compensate

request: Der Tool Call erzeugt eine Approval-Anfrage. RunState enthält Tool-Name, Argumente und Kontext.
pending: Der Run wartet auf eine menschliche Entscheidung. Der Zustand liegt im Checkpoint und ist mit thread_id verknüpft.
approved: Die Freigabe kommt; der Run setzt am Checkpoint fort und ruft das Tool auf.
rejected: Die Freigabe wird verweigert; der Run geht auf abort oder convert to draft.
timeout: Approval läuft ab; der Run eskaliert oder auto-rejectet.
resume/abort/compensate: Fortsetzen, abbrechen oder kompensieren.

Resume-Modi

approve: Tool ausführen und danach weiterlaufen.
reject: Abbrechen oder in Draft umwandeln; Tool nicht aufrufen.
edit: Parameter ändern, etwa Empfänger oder Text, und erneut bestätigen lassen.

Checkpoint und thread state sind die technische Grundlage. Der veröffentlichte LangGraph-Artikel zu checkpoint/thread state erklärt, wie der Zustand gespeichert und an den Ausführungspunkt zurückgeführt wird.

OpenAI Agents SDK HITL Code Example

Das Beispiel zeigt den Approval-Flow im OpenAI Agents SDK. Prüfen Sie die offiziellen Docs vor Production-Code, weil sich APIs ändern können:

from agents import Agent, Runner, function_tool


@function_tool(needs_approval=True)
def send_email(to: str, subject: str, body: str) -> str:
    return send_email_handler(to=to, subject=subject, body=body)


agent = Agent(
    name="EmailAgent",
    tools=[send_email],
    instructions="E-Mail entwerfen und vor dem Versand auf Approval warten",
)

result = Runner.run_sync(agent, "Schreiben Sie eine Refund-Mitteilung für den Kunden")

if result.interruptions:
    state = result.to_state()

    for interruption in result.interruptions:
        print(f"Tool wartet auf Approval: {interruption.tool_name}")
        print(f"Argumente: {interruption.arguments}")

        decision = show_approval_ui(interruption)

        if decision == "approve":
            state.approve(interruption)
        elif decision == "reject":
            state.reject(interruption)

    result = Runner.run_sync(agent, state)

Kernpunkte:

needs_approval=True markiert das Tool als approval-pflichtig.
interruptions enthält die wartenden Tool Calls.
result.to_state() erzeugt einen serialisierbaren RunState.
state.approve() oder state.reject() speichert die Entscheidung.
Runner.run_sync(agent, state) setzt den Run fort.

Feldnamen können sich nach 2026-07 ändern; prüfen Sie die offiziellen Docs.

LangGraph interrupt/resume Code Example

Dieses Beispiel zeigt LangGraph interrupt und Command(resume=...):

from langgraph.graph import StateGraph, MessagesState
from langgraph.checkpoint.memory import MemorySaver
from langgraph.types import Command, interrupt


def send_email_node(state: MessagesState):
    approved = interrupt({
        "action": "send_email",
        "summary": state["email_summary"],
    })

    if approved != "approved":
        return {"messages": ["E-Mail-Versand wurde abgelehnt; die Nachricht wurde als Draft gespeichert"]}

    email_result = send_email(state["email_params"])
    return {"messages": [email_result]}


graph = StateGraph(MessagesState)
graph.add_node("send_email", send_email_node)
graph.add_edge("draft_email", "send_email")

checkpointer = MemorySaver()
app = graph.compile(checkpointer=checkpointer)

thread_id = "thread_123"
config = {"configurable": {"thread_id": thread_id}}

result = app.invoke(
    {"messages": ["Schreiben Sie eine Refund-Mitteilung für den Kunden"]},
    config=config,
)

# Nach der Pause gibt der Graph das interrupt payload an den Caller zurück.
# Zeigen Sie die Approval-UI und warten Sie auf die menschliche Entscheidung.
decision = show_approval_ui(result["__interrupt__"])

if decision == "approve":
    app.invoke(Command(resume="approved"), config=config)
elif decision == "reject":
    app.invoke(Command(resume="rejected"), config=config)
elif decision == "edit":
    app.update_state(config, {"email_params": {"to": "[email protected]"}})
    app.invoke(Command(resume="approved"), config=config)

Kernpunkte:

interrupt() pausiert den Graph.
Command(resume=...) setzt die Ausführung fort.
checkpoint + thread_id halten den Zustand konsistent.
approve/reject/edit sind unterstützte Resume-Pfade.

Auch hier gilt: API in den LangGraph-Docs prüfen.

Approval-Evidence-Felder: Was speichern, wie nachverfolgen?

Approval ist nicht nur Entscheidung, sondern auch Aufzeichnung. Das minimale Audit-Log enthält:

Feld	Beschreibung	Beispiel
tool_name	Tool-Name plus Operationstyp	send_email / delete_record
tool_arguments	Vollständiges Argument-JSON	{“to”: “[email protected]”, “subject”: “Refund notice”}
invoker_id	Identität des Aufrufers	[email protected] / agent_run_abc123
request_time	Zeitpunkt der Approval-Anfrage	2026-06-23T09:26:10Z
approver_id	Identität des Approvers	[email protected]
decision_time	Entscheidungszeit	2026-06-23T09:35:12Z
decision	Ergebnis	approved / rejected / timeout_auto_reject
evidence	Evidence, Screenshot oder Zusammenfassung	„Empfänger korrekt, keine sensiblen Daten im Inhalt“
audit_trail_id	Verweis auf Run-Logs	run_abc123_step_5_tool_3

Die Felder stammen aus MCP Tool-Audit-Empfehlungen und OpenAI API Items wie mcp_approval_request. Approval-Logs sind Observability; der veröffentlichte Monitoring/Recovery-Artikel behandelt das breitere Logging.

Wie serialisiert man RunState? Im OpenAI Agents SDK lässt sich ein pausiertes Ergebnis mit result.to_state() in RunState umwandeln. LangGraph nutzt checkpoint + thread_id. Speichern Sie den Zustand in Datenbank oder Logs und verknüpfen Sie ihn mit audit_trail_id.

Audit-Logs haben drei Aufgaben:

Incident-Tracing: Bei Datenleck prüfen Sie, wer wann welche Operation freigegeben hat.
Compliance-Nachweis: Unternehmen müssen zeigen können, dass Hochrisikoaktionen menschliche Freigabe hatten.
Policy-Verbesserung: Häufig freigegebene, abgelehnte oder abgelaufene Aktionen zeigen, wo Regeln angepasst werden müssen.

Sie können Felder ergänzen: Approval-Dauer, Kanal wie E-Mail/Slack/Feishu oder Zwei-Personen-Review. Der minimale Satz sollte aber bleiben.

Reject und Timeout: Was passiert, wenn Approval scheitert?

Approval wird nicht immer erteilt. Reject und Timeout brauchen klare Pfade, sonst bleibt der Task hängen.

Drei Pfade nach Reject

Pfad 1: continue with fallback. Nutzen Sie eine risikoärmere Aktion. Wird E-Mail-Versand abgelehnt, speichern Sie als Draft und fahren fort.

Pfad 2: convert to draft. Wandeln Sie die Aktion in einen Draft um. Wird CMS-Submit abgelehnt, bleibt ein Draft zur manuellen Bearbeitung.

Pfad 3: abort task. Stoppen Sie die Aufgabe. Wird Produktionsdatenbank-Löschung abgelehnt, darf der Task nicht weiterlaufen.

Auswahl nach Aktion:

Reversibel: fallback oder convert to draft.
Irreversibel und hochriskant: abort task.
Menschliche Klärung nötig: escalate.

Zwei Pfade nach Timeout

Pfad 1: escalate to backup approver. Reagiert der Haupt-Approver nach 30 Minuten nicht, geht die Anfrage an den on-call engineer.

Pfad 2: auto-reject. Nach einer Stunde wird automatisch abgelehnt und der Task gestoppt. Das passt zu niedrigerem Risiko, aber zeitkritischen Abläufen.

Auswahl nach Kontext:

Hochrisikoaktion: eskalieren, nicht automatisch ausführen.
Zeitkritisch: auto-reject, damit der Task nicht endlos hängt.
Normalfall: eskalieren und mehr Zeit geben.

Bereits ausgeführte Schritte zurückrollen

Nach einem Reject kann bereits Arbeit passiert sein. Wenn der Agent vor der Payment-Freigabe eine Bestellung angelegt hat, muss sie storniert werden.

Rollback-Strategien:

Checkpoint rollback: Zum Zustand vor Approval zurückkehren und spätere Schritte verwerfen.
Kompensierende Transaktion: Eine Kompensations-API aufrufen, etwa Bestellung stornieren.
Manueller Eingriff: Menschen informieren, wenn automatische Kompensation nicht möglich ist.

Rollback klappt nicht immer. Eine gesendete E-Mail lässt sich nicht ungeschehen machen. Dann bleiben Audit-Log und Incident-Nachbearbeitung.

Vier Sicherheitsgrenzen: Policy, Guardrail, Approval, Audit kombinieren

Approval ist kein isolierter Schutz. Policy, Guardrail, Approval und Audit arbeiten zusammen und ersetzen einander nicht.

Verantwortlichkeiten der vier Schichten

Schicht	Aufgabe	Beispiel
Policy	Statische Regeln begrenzen Tool-Scope	„Produktionsdatenbank nie löschen“, „Payment-Tool nur gegen Sandbox“
Guardrail	Automatische Prüfung blockiert auffällige Eingaben/Ausgaben	Input-Validierung, Output-Sanitizing, Filter für sensible Daten, Betragsgrenzen
Approval	Menschliche Entscheidung für Hochrisikoaktionen	Empfänger/Inhalt vor E-Mail zeigen, vor Record-Delete bestätigen, Payment freigeben
Audit	Nachträgliche Nachvollziehbarkeit	Approval-Logs, Tool-Call-Logs, Zustandsänderungen

Policy ersetzt Guardrails nicht: Statische Regeln prüfen keine dynamischen Inputs.
Guardrails ersetzen Approval nicht: Automatische Checks treffen keine Geschäftsentscheidung.
Approval ersetzt Audit nicht: Entscheidung und Nachvollziehbarkeit sind getrennt.
Audit ersetzt die ersten drei nicht: Es dokumentiert nachträglich und verhindert nichts.

Kombinationen:

Payment: Policy setzt Maximalbetrag, Guardrail validiert Argumente, Approval verlangt Zwei-Personen-Review, Audit speichert die Entscheidung.
E-Mail: Policy begrenzt Empfänger, Guardrail prüft sensible Inhalte, Approval zeigt Zusammenfassung, Audit speichert den Versand.

MCP-Tool-Sicherheitsgrenze

MCP (Model Context Protocol) hat eigene Tool-Grenzen. Für die Spec 2025-06-18 sollten Sie die Version vor Veröffentlichung erneut prüfen:

tools/list zeigt verfügbare Tools und macht Risiken sichtbar.
tools/call vor sensiblen Operationen entspricht Approval.
inputSchema-Validierung entspricht Guardrail.
timeout verhindert hängende Tool Calls.
audit logging entspricht Audit.

Wichtig: MCP approval ersetzt weder OAuth Scope noch server-side authorization. MCP approval bestätigt einen Tool Call; OAuth Scope ist API-Zugriff; server-side authorization prüft Geschäftsrechte. Alle drei sind nötig.

Ein Feishu MCP Server kann OAuth bestanden haben und send_message im Scope tragen. Das heißt nicht, dass jede Nachricht sicher ist. MCP approval prüft vor dem Versand den Inhalt, server-side authorization den erlaubten Empfänger.

Outbound Messages, Writes in Collaboration-Systeme und Bulk-Table-Änderungen behandelt der geplante Feishu-MCP-Artikel.

Approval-UI-Design

Die Approval-UI ist mehr als Approve/Reject. Sie muss genug Informationen für eine Entscheidung zeigen.

Designprinzipien:

Tool-Name und Argumente anzeigen, damit Approver wissen, was der Agent aufrufen will.
Erwartete Wirkung anzeigen, etwa „E-Mail an [email protected] mit Betreff Refund notice senden“.
Reversibilität anzeigen: „nach Versand nicht rückgängig“ oder „nach Löschung wiederherstellbar“.
Datensensibilität anzeigen: „enthält Nutzerdaten“ oder „öffentliche Daten“.
Cancel und Reject trennen. Cancel bricht diese UI-Interaktion ab; Reject verweigert den Tool Call und schreibt Audit.

Kernelemente:

Tool-Name + Operationstyp
Vollständige Argumente, bei Bedarf einklappbar
Zusammenfassung der erwarteten Wirkung
Reversibilitätswarnung
Datensensibilitätslabel
Feld für Approval-Grund
Approve / Reject / Cancel Buttons

Wichtig: UI ersetzt server-side authorization nicht. Selbst nach einem Klick auf Confirm muss das Backend prüfen, ob Aufrufer, Zielobjekt und Berechtigung passen.

Wenn die UI „Record ID=123 löschen“ zeigt, muss das Backend trotzdem prüfen, ob der Record dem Nutzer gehört und gelöscht werden darf.

HITL ist kein isoliertes Pop-up. Es gehört in Tool-Gateway, Logging und Berechtigungssystem. Der geplante MCP-Produktionsarchitektur-Artikel vertieft das.

OWASP LLM01/LLM06 Risiko-Mapping

OWASP LLM Top 10 beschreibt Risiken für LLM- und Agent-Systeme. Nummern und Versionen können sich ändern; prüfen Sie sie vor Veröffentlichung. Zwei Risiken sind für Approval zentral:

Risiko-ID	Beschreibung	Approval-Gegenmaßnahme
LLM01 Prompt Injection	Externe Eingaben induzieren unautorisierte Funktionsaufrufe, Datenlecks oder externe Kommandos	Hochrisikoaktionen brauchen menschliche Freigabe; nicht nur Prompt-Regeln; UI zeigt Argumente und Wirkung
LLM06 Excessive Agency	Zu viel Funktionalität, Berechtigung und Autonomie erzeugen Tool-System-Risiken	Tool-Scope per Policy begrenzen, Automationsniveau per Approval begrenzen, „immer erlauben“ eng scopen

LLM01 zeigt, dass Prompt Injection ein Modell zu nicht autorisierten Tool Calls bringen kann. Approval stoppt vor Hochrisikoaktionen und zeigt Argumente plus Wirkung.

LLM06 zeigt, dass zu viel Autonomie riskant ist. Approval ist kein Allheilmittel; es braucht Policy für Tool-Scope und Approval-Regeln für Automationsgrad. „Für diese Session immer erlauben“ muss eng begrenzt sein.

NIST AI RMF Core Mapping

NIST AI RMF Core ordnet AI-Risikomanagement in vier Phasen. Kleine Teams können eine leichte Variante nutzen, ohne Enterprise-Compliance aufzubauen:

Phase	Approval-Aufgabe	Beispiel
Govern	Rollen und Risikoregeln definieren	Approver-Rollen wie owner/on-call engineer, L0-L3-Level, Reject- und Timeout-Strategien
Map	Hochrisikoszenarien erkennen	Delete, Payment, Rechteänderung und Prompt-Injection-Pfade mit der Matrix identifizieren
Measure	Coverage und Reject-Rate messen	Approval-Coverage, Reject-Rate und Timeout-Rate tracken und Policy verbessern
Manage	Incident Response und Recovery	Approval-Logs für Tracing nutzen, Schritte zurückrollen, Kompensation ausführen

Govern definiert Regeln. Map erkennt Risiken. Measure prüft, ob die Kontrolle greift. Manage behandelt Vorfälle und Wiederherstellung.

Für Einzelpersonen oder kleine Teams reicht die leichte Version: Approval-Level definieren, Hochrisikoaktionen finden, Reject-Rate messen und Audit-Logs speichern.

Fazit

Risikoklassifizierung ist der erste Schritt. Nicht alles braucht Approval: Reads und Drafts dürfen automatisch laufen; Deletes und Payments müssen stoppen. Entscheiden Sie nach externer Wirkung, Reversibilität, Datensensibilität, Geld-/Rechte-Schwelle und Autonomiegrad.

Approval ist kein Pop-up. Es ist serialisierbarer, fortsetzbarer und auditierbarer Systemzustand. RunState liegt im Checkpoint, der Run setzt am Pausenpunkt fort, und das Audit-Log speichert Entscheidung und Ausführungskette.

Die vier Sicherheitsgrenzen haben unterschiedliche Rollen. Policy begrenzt Tool-Scope, Guardrail prüft automatisch, Approval gibt Menschen die Entscheidung, Audit macht nachverfolgbar. Nur die Kombination deckt das Risiko.

OWASP LLM01 und LLM06 zeigen Prompt Injection und excessive agency als Kernrisiken für Agent-Tool-Systeme. Approval muss mit Policy und Guardrails arbeiten, nicht allein.

NIST AI RMF Core liefert den Rahmen. Für kleine Teams genügt: Approval-Level definieren, Hochrisikoaktionen identifizieren, Reject-Rate messen und Audit-Logs speichern.

Nächste Lektüre:

LangGraph checkpoint/thread state, bereits veröffentlicht: technische Grundlage für gespeicherten Approval-Zustand.
Agent monitoring/recovery, bereits veröffentlicht: Approval-Logs als Teil der Observability.
MCP-Produktionsarchitektur, geplant: HITL gehört in Tool-Gateway und Berechtigungssystem.
Feishu MCP Research, geplant: Approval-Szenarien für ausgehende Nachrichten und Writes in Collaboration-Systeme.