Approval Gates — Administration Guide

Audience: Platform administrators, compliance officers Time: ~8 min

Approval gates add a human-in-the-loop step to policy enforcement. When a control includes an approval_gate post-decision action, the request is held until an authorised approver reviews and approves it. This guide covers configuration, queue management, escalation workflows, and Rego integration.

Overview

An approval gate is a post-decision action attached to a control. After the Bouncer evaluates a request and the control decides "allow", the approval_gate action pauses execution and creates an approval request. The request only proceeds once an approver with the configured role approves it.

Key architectural point: the allow/deny decision stays in Rego (SCCA Principle 2). The gate is implemented as a post-decision action dispatched by the Control Plane — no decision logic lives in the Bouncer binary.

When to use approval gates

• Sensitive operations requiring manager sign-off (large transactions, data exports, production deploys)
• Regulatory workflows where dual-control or four-eyes review is mandated
• AI agent actions that require human verification before execution
• Break-glass escalation paths combined with audit logging

Accessing Approval Gates

Approval gates are accessible from three locations:

Configuring Default Gate Settings

Navigate to Settings → Approval Gates → Gate Configuration to set tenant-wide defaults. Per-control overrides in the Policy Builder take precedence over these defaults.

Default approver role

Select the role required to approve requests when not specified per-control:

• policy_manager — default; anyone with the Policy Manager role
• compliance_officer — for regulated workflows
• admin — highest privilege
• security_manager — for security-sensitive operations

Default TTL (time-to-live)

How long a pending request remains valid before auto-expiring. Preset options:

Reason required

When enabled, approvers must provide decision notes when approving or denying. Recommended for audit-sensitive environments.

Auto-escalation

When enabled, pending requests that exceed the escalation timeout are automatically escalated to a secondary approver role. Configure:

• Escalation role — the fallback approver role (e.g. admin when the primary is policy_manager)
• Escalate after — minutes before escalation triggers (minimum 5 minutes)

Multi-approver quorum

Require multiple distinct approvals before a request proceeds:

• Single approver (1) — one approval is sufficient
• Quorum of 2 — two distinct approvers must approve
• Quorum of 3 — three distinct approvers must approve

Managing the Approval Queue

Navigate to Settings → Approval Gates → Approval Queue.

Filtering

Use the status filter to view:

• Pending — requests awaiting approval (default view)
• Approved — completed approvals
• Denied — rejected requests
• Expired — requests that exceeded their TTL
• All — unfiltered view

Reviewing request details

Click any request row to expand its details:

• Approver role and requested by fields
• Created and expires timestamps
• Decision audit trail (who decided, when, and their notes)
• Request context (the full JSON context from the policy evaluation)
• View Originating Control link to the policy that triggered the gate

Approving and denying

• Click Approve or Deny on individual requests
• For bulk operations: check multiple pending requests, then use Bulk Approve or Bulk Deny

Bulk actions require admin or compliance_officer role.

Linking Approval Gates to Controls

Via the Visual Builder (Policy Wizard)

1. Open a control in the Visual Builder
2. Navigate to Step 5 — Context & Actions
3. Click Add Action and select Require Human Approval
4. Configure:
   • Approver role — who can approve
   • Notification destination — where approver alerts are sent
   • TTL — use preset buttons (15m, 30m, 1h, 4h, 24h)
   • Quorum — number of required approvals
   • Reason required — toggle on/off
   • Auto-escalation — enable with escalation role and timeout

Via JSON (Code Editor)

{
  "type": "approval_gate",
  "trigger": "on_allow",
  "enabled": true,
  "config": {
    "destination_ref": "approval_queue",
    "approver_role": "security_manager",
    "ttl_minutes": 30,
    "reason_required": true,
    "notify_destination_ref": "slack_security_channel",
    "quorum": 2,
    "escalation_enabled": true,
    "escalation_role": "admin",
    "escalation_after_minutes": 60
  }
}

Full field reference

Escalation Workflows

Escalation ensures that pending approvals are not silently ignored when primary approvers are unavailable.

How escalation works

1. An approval_gate action creates a pending approval request
2. A timer starts based on escalation_after_minutes
3. If the request is still pending when the timer fires, the escalation role is notified
4. Both the primary and escalation roles can now approve the request

Configuration priority

1. Per-control config (in the action's config block) — highest priority
2. Gate defaults (Settings → Approval Gates → Gate Configuration) — fallback
3. Built-in defaults — escalation disabled, 60 minute timeout

Notification routing

Escalated requests trigger a separate notification to the escalation role. Ensure the notify_destination_ref channel is configured and active in Settings → Action Destinations.

Rego Integration

The approval gate workflow is backed by a Rego template at controlcore.policy.templates.approval_gate.

Input context values

The Bouncer populates input.context.approval_status via Control Bridge–synced policy data:

Template rules

package controlcore.policy.templates.approval_gate

allow if { input.context.approval_status == "approved" }

gate_decision := "allow" if { approval_gate_passed }
gate_decision := "hold"  if { approval_gate_pending }
gate_decision := "deny"  if { approval_gate_denied }
gate_decision := "deny"  if { approval_gate_expired }

escalation_required if {
    approval_gate_pending
    time.now_ns() > (input.context.gate_created_at_ns + input.context.escalation_after_ns)
}

Composing with other conditions

Combine the approval gate with business conditions:

allow if {
    input.action == "transfer_funds"
    input.resource.amount > 10000
    input.context.approval_status == "approved"
}

Rollout Checklist

Start with audit_log + notification before enabling the gate. This validates routing without blocking requests.

Troubleshooting

Full troubleshooting reference: Troubleshooting Controls

Related

• Actions & Post-Decision Flows — full action type reference
• Visual Builder (Wizard) — step-by-step control authoring
• SCCA — AI-Assisted Authoring — AI-powered control generation
• Rego Guidelines — Rego best practices