Human-in-the-Loop Approvals (Stop Writes) + Code

Interaktiver Ablauf

Szenario:

Schritt 1/3: Execution

Action is proposed as structured data (tool + args).

Problem (aus der Praxis)

Du willst Writes. Dein Agent will Writes. Deine Kunden wollen, dass Writes stimmen.

In Demos klingt das easy: „der Agent kann doch einfach das Ticket schließen“. In Prod ist „einfach“ genau die Stelle, an der du später erklärst, warum 200 Dinge kaputt sind.

Approvals sind kein Feature für PMs. Approvals sind ein Safety Valve für Systeme, deren Entscheider probabilistisch ist.

Warum das in Production bricht

1) „Write tool“ ist keine einzelne Kategorie

Writes sind nicht gleich Writes:

reversible vs irreversible
low impact vs high impact
idempotent vs „oops, duplicate“

Wenn du alles gleich behandelst, machst du entweder:

zu viele approvals (UX stirbt)
oder zu wenige approvals (Prod stirbt)

2) Ohne Approval Path wirst du aus Versehen voll-autonom

Wenn ein Write Tool in der Allowlist ist und nichts stoppt es, dann wird es genutzt. Nicht „vielleicht“. Sondern sobald es für den Agent „der kürzeste Pfad“ ist.

3) Approval ohne Context ist nutzlos

„Approve this tool call?“ reicht nicht. Du brauchst evidence:

proposed action
tool args (oder diff)
warum der Agent glaubt, dass es richtig ist
risk score / policy reason

Implementierungsbeispiel (echter Code)

Ein Minimal-Approval-Gate:

Write Tools triggern einen Approval Request
Approval wird mit einem token/key signiert
Tool Gateway führt nur aus, wenn Approval existiert

PythonJS

PYTHON

from dataclasses import dataclass
from typing import Any


WRITE_TOOLS = {"ticket.close", "db.write", "email.send"}


@dataclass(frozen=True)
class Approval:
  approval_id: str
  approved: bool
  approved_by: str


class ApprovalRequired(RuntimeError):
  pass


def requires_approval(tool: str) -> bool:
  return tool in WRITE_TOOLS


def tool_gateway_call(tool: str, args: dict[str, Any], *, approval: Approval | None) -> Any:
  if requires_approval(tool):
      if not approval or not approval.approved:
          raise ApprovalRequired(f"approval_required:{tool}")
  return call_tool(tool, args)  # (pseudo)

JAVASCRIPT

const WRITE_TOOLS = new Set(["ticket.close", "db.write", "email.send"]);

export class ApprovalRequired extends Error {}

export function requiresApproval(tool) {
return WRITE_TOOLS.has(tool);
}

export function toolGatewayCall(tool, args, { approval } = {}) {
if (requiresApproval(tool)) {
  if (!approval || approval.approved !== true) throw new ApprovalRequired("approval_required:" + tool);
}
return callTool(tool, args); // (pseudo)
}

Echter Incident (mit Zahlen)

Wir hatten einen Agenten, der Support Tickets „aufräumen“ sollte. Ein Prompt Change hat „cleanup“ als „close“ interpretiert.

Impact:

63 Tickets geschlossen, die offen bleiben sollten
2 Engineer-Stunden zum Reopen + Entschuldigen
wir haben den Agenten für eine Woche read-only gemacht, bis wir’s wieder vertrauen konnten

Fix:

approvals für high-impact writes
UI zeigt diff/evidence (nicht nur „approve?“)
idempotency keys, damit Approvals nicht doppelt ausführen

Abwägungen

Approvals kosten Zeit. Das ist der Preis für Safety.
Zu viele Approvals killen Conversion/UX. Du brauchst Risk-Tiers.
Approval Systeme brauchen Audit Logs, sonst hast du keinen Beweis im Incident.

Wann du es NICHT nutzen solltest

Für read-only Tools brauchst du keine Approvals.
Für low-risk, fully reversible Writes kann ein Auto-Approve unter tight budgets okay sein.
Wenn du keine Menschen hast, die Approvals wirklich reviewen: dann ist es kein Approval, es ist Theater.

Checkliste (Copy/Paste)

[ ] Write Tools identifizieren (capability-based)
[ ] Approval required für irreversible/high-impact actions
[ ] Evidence im Approval UI (args diff, why, provenance)
[ ] Enforced im Tool Gateway (nicht nur im Frontend)
[ ] Idempotency keys pro approved action
[ ] Audit logs (who approved what)

Sicheres Default-Config-Snippet (JSON/YAML)

YAML

approvals:
  required_for:
    - "db.write"
    - "email.send"
    - "ticket.close"
  evidence:
    include_args: true
    include_diff: true
  enforce_in: "tool_gateway"

FAQ (3–5)

Von Patterns genutzt

Erforderliche Governance

Wann brauche ich Approvals wirklich?

Wenn die Action teuer/irreversibel ist oder Kunden-Daten verändert. Default: writes brauchen Approval.

Wie verhindere ich Approval-Spam?

Risk-Tiers + only escalate high-risk. Und halte write tools klein (keine generischen RPCs).

Kann ich Approvals automatisieren?

Teilweise: auto-approve low-risk unter tight budgets. Aber logge es als ‘auto-approved’.

Wo enforce ich Approvals?

Im Tool Gateway. Wenn es nur im UI ist, wird’s umgangen.

Q: Wann brauche ich Approvals wirklich?
A: Wenn die Action teuer/irreversibel ist oder Kunden-Daten verändert. Default: writes brauchen Approval.

Q: Wie verhindere ich Approval-Spam?
A: Risk-Tiers + only escalate high-risk. Und halte write tools klein (keine generischen RPCs).

Q: Kann ich Approvals automatisieren?
A: Teilweise: auto-approve low-risk unter tight budgets. Aber logge es als „auto-approved“.

Q: Wo enforce ich Approvals?
A: Im Tool Gateway. Wenn es nur im UI ist, wird’s umgangen.