Human Approval für KI-Agenten: Wie man write-Aktionen sicher kontrolliert

Idee in 30 Sekunden

Human approval ist ein Runtime-Gate für riskante write-Aktionen: vor der Ausführung erhält der Agent approval_required und wartet auf eine menschliche Bestätigung.

Wann das nötig ist: wenn ein Agent Daten ändern, Kundennachrichten senden oder irreversible Aktionen in Production ausführen kann.

Problem

Ohne Approval werden write-Aktionen sofort ausgeführt, wenn die Policy sie erlaubt. Im Demo ist das bequem. In Production wird ein einzelner Agentenfehler zu einem realen Incident.

Das Problem ist nicht nur ein "schlechtes" Modell. Auch ein gutes Modell liegt bei atypischen Anfragen manchmal falsch. Wenn zwischen Agent und write-Tool kein menschliches Gate steht, wird ein Fehler sofort zum Side Effect in realen Systemen.

Analogie: das ist wie eine Zahlung ohne 3D Secure. Solange alles gut läuft, gibt es keine Verzögerung. Wenn etwas schiefläuft, werden die Folgen in Sekunden teuer.

Lösung

Die Lösung ist, in der Policy-Layer einen separaten Approval-Flow für riskante write-Aktionen einzubauen. Die Policy liefert eine der Entscheidungen: allow, deny oder approval_required.

approval_required führt die Aktion nicht sofort aus: Runtime erstellt eine Approval-Request, wartet auf die Entscheidung eines Menschen und führt den Tool-Call erst nach approval_granted aus. Diese Entscheidung wird auf jedem Schritt getroffen, nicht nur am Ende des Runs.

Human Approval != Manual Mode

Das sind unterschiedliche Modelle:

• Manual mode: ein Mensch führt fast jede Aktion statt des Agenten aus.
• Human approval: der Agent arbeitet autonom, und ein Mensch bestätigt nur riskante write-Aktionen.

Eines ohne das andere reicht nicht:

• ohne Approval passieren riskante Aktionen ohne zusätzliche Kontrolle
• wenn man für alles Manual mode nutzt, verliert das System Geschwindigkeit und Skalierbarkeit

Beispiel:

• ohne Approval: ticket.close_bulk wird sofort ausgeführt
• mit Approval: Policy liefert approval_required, und die Aktion wartet auf Bestätigung

Metriken der Approval-Kontrolle

Diese Metriken und Signale arbeiten auf jedem Agenten-Schritt zusammen.

So sieht das in der Architektur aus

Die Policy-Layer (Tool-Gateway) steht zwischen Runtime und Tools und ist der zentrale Kontrollpunkt vor jedem Schritt. Jede Entscheidung (allow, deny, approval_required) wird im audit log protokolliert.

Jeder Agenten-Schritt läuft vor Ausführung durch diesen Flow: Runtime führt write-Aktionen nicht direkt aus — zuerst Policy-Check -> Approval-Gate -> Ausführung.

Kurz zum Flow:

• Runtime formt einen Tool-Call
• Policy-Layer prüft Risiko und kann approval_required zurückgeben
• bei approval_granted wird write ausgeführt
• bei approval_denied oder approval_timeout bekommt der Run einen stop reason
• jede Entscheidung wird ins audit log geschrieben

In Runtime wird deny ebenfalls in einen expliziten stop reason umgewandelt, sichtbar in Logs und Run-Response.

Eine Approval-Request enthält typischerweise:

• tool
• kurze preview der Aktion
• args hash
• reason / risk tier
• TTL

Beispiel

Ein Support-Agent möchte email.send für einen Kunden ausführen. Die Policy definiert, dass für dieses Tool eine menschliche Bestätigung nötig ist.

Ergebnis:

• ohne approval token wird write nicht ausgeführt
• nach approval_granted wird der Call freigegeben
• bei Timeout gibt der Agent stop("approval_timeout") zurück

Human approval stoppt die riskante Aktion vor dem Side Effect, nicht erst nach dem Incident.

Im Code sieht das so aus

Im vereinfachten Schema oben ist der zentrale control flow gezeigt. In der Praxis sollten Prüfung und Ausführung über ein einziges Policy/Tool-Gateway laufen.

Beispiel für Approval-Config:

approvals:
  required_for:
    - email.send
    - ticket.close_bulk
    - db.write
  ttl_seconds: 300
  fallback_when_not_approved: stop

decision = policy.evaluate(tool, user_context, mode="normal")

if decision.outcome == "approval_required":
    request = approvals.create_request(
        run_id=run_id,
        tool=tool,
        args_hash=hash_args(args),
        ttl_seconds=300,
    )
    audit.log(run_id, decision.outcome, reason="pending_human_review", tool=tool, pending_id=request.id)
    return stop("approval_required", pending_id=request.id)

elif decision.outcome == "deny":
    audit.log(run_id, decision.outcome, reason=decision.reason, tool=tool)
    return deny(decision.reason)

# later, in resume flow with pending_id
approval = approvals.get_decision(pending_id)
if approval.outcome != "approved":
    audit.log(run_id, "deny", reason=approval.outcome, tool=tool, pending_id=pending_id)
    return stop(approval.outcome)

audit.log(run_id, "approval_granted", reason="human_approved", tool=tool, approver=approval.approved_by)
result = tool.execute({**args, "approval_token": approval.token})
decision = Decision.allow(reason="policy_ok")
audit.log(run_id, decision.outcome, reason=decision.reason, tool=tool, result=result.status)
return result

In Production ist der Approval-Flow meist asynchron: Runtime erstellt eine Request, gibt einen pending/stop state ohne Blockierung des Workers zurück und setzt den Run nach der Entscheidung fort.

So sieht das während der Ausführung aus

Szenario 1: bestätigt (approval granted)

1. Runtime formt einen email.send-Call.
2. Policy gibt approval_required zurück.
3. Runtime erstellt Approval-Request und liefert pending/stop state zurück.
4. Ein Mensch bestätigt die Aktion innerhalb der TTL.
5. Runtime setzt den Run fort, führt den Tool-Call aus und schreibt `approval_granted -> allow`.

---

Szenario 2: Bestätigungs-Timeout

1. Runtime formt einen db.write-Call.
2. Policy gibt approval_required zurück.
3. Runtime erstellt Approval-Request und liefert pending/stop state zurück.
4. Bis zum Ablauf der TTL kommt keine Bestätigung.
5. Runtime gibt stop (approval_timeout) zurück, Aktion wird nicht ausgeführt.

---

Szenario 3: policy deny ohne approval

1. Runtime formt einen write-Call außerhalb des erlaubten scope.
2. Policy gibt sofort deny zurück.
3. Runtime gibt stop reason zurück.
4. Audit: decision=deny, reason=policy_denied.
5. Aktion wird nicht ausgeführt.

Typische Fehler

• Approval nur im UI, aber nicht im Policy/Tool-Gateway
• Approval ohne TTL und ohne Abbruch
• gleicher Ansatz für low-risk und high-risk write-Aktionen
• fehlender approval token bei der Tool-Ausführung
• approval_required und approval_granted nicht loggen
• alle Runs während Approval blockieren statt expliziten stop/pending state zurückzugeben

Im Ergebnis lässt das System entweder unsichere Aktionen durch oder hängt in Approval-Queues ohne transparenten Status.

Selbst-Check

Schneller Human-Approval-Check vor dem Production-Start:

FAQ

Q: Für welche Aktionen ist Approval zwingend?
A: Für irreversible oder kundensichtbare write-Aktionen: Datenänderungen, Bulk-Closes, Nachrichtenversand, Finanzoperationen.

Q: Wie verhindert man, dass das Team in approval-spam untergeht?
A: Teile write-Aktionen in risk tiers. High-risk -> Pflicht-Approval, low-risk -> eigene Policy mit tighter limits und Audit.

Q: Soll der Worker blockieren, solange wir auf Approval warten?
A: Besser nicht. Gib pending/stop state zurück und setze den Run nach der Entscheidung fort, um Queues und Deadlocks zu vermeiden.

Q: Kann Approval RBAC und Budgets ersetzen?
A: Nein. Approval ist ein zusätzlicher Gate für riskante Aktionen. RBAC, Limits und Budgets bleiben notwendig.

Q: Was sollte mindestens geloggt werden?
A: approval_required, approval_granted|approval_denied|approval_timeout, wer bestätigt hat, welches Tool, welcher reason und welches Ausführungsergebnis.

Wo Human Approval im Gesamtsystem liegt

Human approval ist eine der Ebenen von Agent Governance. Zusammen mit allowlist/RBAC, Budgets, Limits und audit bildet es ein einheitliches Ausführungskontrollsystem.

Verwandte Seiten

Weiter zum Thema:

• Agent Governance Überblick — Gesamtmodell zur Agent-Kontrolle in Production.
• Allowlist vs Blocklist — wie man default-deny Zugriff auf Tools aufbaut.
• Zugriffskontrolle (RBAC) — wie man Zugriff über Rollen und tenant scope begrenzt.
• Budgetkontrolle — wie man runaway-Kosten und Schleifen begrenzt.
• Audit Logs für Agenten — wie man Approval/Policy-Entscheidungen in Incidents erklärt.