How does BeforeQuery enforce approvals and MFA?

Approvals are a first-class concept, not an afterthought.

Each playbook and each action carries an approval mode. Read-only actions default to autopilot. Writes default to require an approval. Destructive actions default to require a step-up MFA challenge on the reviewer.

Approval chains are configurable: one reviewer or many, sequential or parallel, with a deadline, a delegate list for when the primary reviewer is out, and an escalation policy for when the deadline lapses. All configuration lives in Approval Policies; you write it once and reference it from any playbook.

MFA is enforced at the reviewer, not the requester — the requester can be authenticated by their chat platform (Slack, Teams) but the reviewer must present a fresh factor when the policy demands it. The system supports WebAuthn passkeys, hardware keys, and TOTP.

Every approval decision — who reviewed, when, on what device — is written to the immutable audit log alongside the action itself. If the reviewer changes their mind before the action executes, the request can be revoked; if the action already ran, the audit trail shows both events with the intervening time.