Approvals

Some rules don't allow or deny outright — they hold the request for a human. This is the require_approval verdict, and this page is how you operate the queue. For the guided walkthrough see Resolving approvals.

How a hold works

When a request matches a require_approval rule, the collector pauses it (up to 60 seconds) and surfaces it in the dashboard's Approvals queue. An operator resolves it:

• Allow → the request is released and forwarded to the provider.
• Deny → the request is stopped.
• No decision within 60s → it fails closed (denied) so a held request never hangs the calling app indefinitely.

Resolutions reach the collector on its next uplink cycle (~10s), comfortably inside the hold window.

Operating the queue

• The Approvals page lists everything currently waiting, with the agent, destination, rule, and args.
• Resolve with the buttons or keyboard (A allow, D deny, J/K to move).
• The queue only shows genuinely-pending items — once resolved or timed out, they leave.

Watch the backlog

A growing pending count means requests are being held and nobody's resolving them — which, for a require_approval rule, means those calls are timing out to deny every 60 seconds. If approvals pile up, either staff need to work the queue faster or the rule is too broad. The pending-approval count is on Fleet health (Monitoring).

When to use require_approval

Reserve it for genuinely high-stakes, low-volume events — a spend threshold crossed, a sensitive destination, a first-time provider. It's a human-in-the-loop control, not a bulk filter: if a rule holds hundreds of requests a day, it should probably be an allow (with logging) or a deny, not an approval.