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.

Where you do this: Cloud dashboard — kilasec.com/app/ → Approvals (the queue) and Settings → Notifications (alert channels). Requires the tenant_admin role. Configure at least one notification channel before you gate anything with require_approval — holds fail closed at 60 seconds.

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.

Getting notified

Because a hold fails closed at ~60 seconds, you can't rely on someone watching the dashboard. When a new approval arrives, Kilasec pushes it to the channel you set in Settings → Notifications — a Slack-compatible webhook and/or email — with the agent, destination, and rule, plus a link to resolve it. Configure at least one channel (and hit Send test) before you gate anything with require_approval. One notification fires per approval, not per sync, so you won't get repeats while it's pending.

This is why require_approval should stay rare and high-stakes (building an approval policy): a channel that buzzes for every routine call gets muted, and then a real one gets missed.

Operating the queue

Dashboard → Approvals.

• The list shows 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

Dashboard → Dashboard. The pending-approval count is on the top-level Dashboard tab (see Monitoring). 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 the queue needs working faster or the rule is too broad.

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.