Approvals & human review

Many sensitive operations do not deserve a flat deny. A support agent's bulk export is sometimes exactly what the customer asked for, and sometimes an exfiltration path. Approval required is the engine's outcome for that middle ground: the call pauses before execution, a human decides, and the action resumes or blocks.

This is an intentional control point, not a model failure. A borderline request escalates to a deliberate, recorded decision; a silent block would only teach the operator to route around the control.

Approval requests are delivered over the channels you configure, Slack, Microsoft Teams, or email, alongside the dashboard queue. The approver acts where they already work; nobody has to keep another console open.

The wait is bounded, so an agent never hangs indefinitely on a human. What happens when nobody answers is itself a policy outcome, defined by you in advance.

A useful approval needs the decision context, and the request carries it: who is acting, on whose behalf, doing what, against which resource, and which rule paused the call.

The approver is deciding one concrete action in the shape it will execute. That is a different job from reviewing a transcript after the fact, which is why the pause lands before dispatch, while the action can still be stopped.

Each grant or rejection is recorded into the same signed decision chain as every permit and deny, cryptographically tied to the execution event it governed. A skeptical reviewer can verify that record independently, without taking the operator's dashboard at its word.

Regulators are beginning to ask about this layer directly. The EU AI Act's Article 14 requires effective human oversight of high-risk AI systems.