Define human-approval-gate standard for irreversible actions, incl. chained/multi-agent flows

[MrCarrera]

Description

Define where and how a mandatory human-in-the-loop checkpoint must sit before an agent — or any agent within a multi-agent chain — executes an irreversible or high-consequence action.

Source

Krav 4 "Godkjenningspunkt før handlinger med vesentlig konsekvens" and Krav 12 "Godkjenningspunkter i kjeder": a checkpoint at the system's entry point is not sufficient — it must sit immediately before the consequential action, regardless of which agent in the chain performs it.

Business Goal

This is the control that keeps a human accountable for irreversible outcomes. Without it, Class 3 agents and multi-agent systems can act autonomously in ways nobody explicitly approved.

Acceptance Criteria

• A documented pattern for placing approval checkpoints exists, covering both single-agent and orchestrator/sub-agent architectures.
• Guidance requires checkpoint placement to be justified per-action in a system's documentation, not assumed from a single entry-point check.
• The pattern is referenced from the classification scheme: Class 3 requires at least one such checkpoint.

Dependencies

Depends on the classification-scheme issue in this epic. Coordinates with the mandate-delegation-limits issue for multi-agent systems.

[babyblueviper1]

Real, relevant experience from a production system with exactly this requirement (a pre-action verdict layer that has to be independently, third-party verifiable, not just internal-only) — the entry-point-vs-per-action distinction you're drawing is the right one, and the harder failure mode for chained/multi-agent systems is a subtler version of it: a checkpoint can be satisfied by an action and then a different action executes (approval granted for one proposed operation, something else runs in its place — whether by bug, drift, or a compromised intermediate agent in the chain).

The mitigation that's worked for us: the checkpoint's approval isn't a boolean per-agent flag, it's a verdict cryptographically bound to a canonical hash of the specific proposed action (parameters, target, effect — not "agent X may proceed"). Execution then only honors an approval if the hash of what's actually about to run matches the hash the approval was issued against. This generalizes cleanly across your single-agent vs orchestrator/sub-agent case: each sub-agent's consequential action gets its own hash-bound checkpoint, regardless of position in the chain, and a chain can't "launder" one approved action into a different executed one.

One question for the pattern doc, since it seems like the crux for the multi-agent case specifically: does the acceptance criteria plan to require that binding explicitly (approval tied to a recomputable hash of the exact action, checked again at execution time), or is checkpoint placement the only thing being specified, leaving the binding mechanism to each team's implementation?