🏗️ Actions & Post-Decision Flows

Audience: Control authors, security engineers, compliance officers Time: ~10 min

Post-decision actions run after a control evaluates a request. They do not change the allow/deny outcome — they add operational side-effects: notifications, approvals, audit events, and integrations.

🔧 Action types reference

📞 Supported triggers

📌 Canonical action shape (JSON)

{
  "type": "<action_type>",
  "trigger": "<trigger>",
  "enabled": true,
  "config": {
    "destination_ref": "<configured-destination-id>",
    "credential_ref": "<credential-reference>"
  }
}

Actions use references to destinations and credentials configured in Settings → Integrations — raw credentials are never stored inside a control.

📌 Examples

audit_log — always write a decision record

{
  "type": "audit_log",
  "trigger": "always",
  "enabled": true,
  "config": {
    "destination_ref": "control_core_audit",
    "level": "info",
    "message": "Decision for {{subject.id}} on {{resource.name}}: {{decision}}"
  }
}

Best practice: Add an audit_log action to every control. It provides decision traceability without affecting request flow.

siem_log — forward denials to Splunk or QRadar

{
  "type": "siem_log",
  "trigger": "on_deny",
  "enabled": true,
  "config": {
    "destination_ref": "splunk_hec",
    "credential_ref": "siem_prod_token",
    "severity": "high",
    "event_type": "control_decision"
  }
}

Recommended fields to include in SIEM events:

• Trigger and decision outcome
• Control name and version
• Resource path and method
• Environment and Bouncer ID

webhook — call an external API

{
  "type": "webhook",
  "trigger": "on_deny",
  "enabled": true,
  "config": {
    "url": "https://hooks.example.com/control-event",
    "method": "POST"
  }
}

Webhook dispatch is asynchronous with a bounded request timeout. Use always only for low-cost telemetry endpoints to avoid adding latency.

notification — alert via Slack or Teams

{
  "type": "notification",
  "trigger": "on_deny",
  "enabled": true,
  "config": {
    "destination_ref": "slack_security_channel",
    "message": "Access denied: {{subject.id}} attempted {{action}} on {{resource.name}}"
  }
}

Best practices:

• Use on_deny for actionable security alerts
• Prefer role/group recipients over individual-only routing
• Use always sparingly to avoid alert fatigue

Supported channels: in-app, Slack, Teams, PagerDuty, email.

approval_gate — pause and require human approval

{
  "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"
  }
}

approval_gate pauses request execution. The request only proceeds after an approver with the configured role approves it via the Controls → Approval Inbox.

Rollout guidance (to avoid breaking flows):

1. First deploy with audit_log + notification only — verify approver receives the notification
2. Test the full approval loop in sandbox: request → notification → approve → confirm request proceeds
3. Enable approval_gate only after routing is validated
4. Start with narrow scope (one endpoint or user group) before expanding

Troubleshooting: Requests blocked after adding approval gate?

• Check pending approvals in Controls → Approval Inbox and Settings → Approval Gates
• Confirm approver_role matches an existing role in your platform
• Verify notify_destination_ref is configured so approvers are notified

break_glass_notify — emergency override path

{
  "type": "break_glass_notify",
  "trigger": "on_deny",
  "enabled": true,
  "config": {
    "destination_ref": "break_glass_bridge",
    "notify_channels": "email,siem",
    "require_reason": true,
    "ttl_minutes": 15
  }
}

Pair break_glass_notify with audit_log on on_deny so every emergency access attempt produces a decision record for audit.

Troubleshooting: Break-glass path still fails after notification?

• Verify destination_ref and notify_channels destination refs exist and are active in Settings → Integrations
• Confirm TTL and reason requirements are documented in your runbook and communicated to users who need emergency access Full reference: Troubleshooting Controls

📌 Safe staged rollout pattern

For high-impact controls (approval gates, break-glass, hard denies on critical paths):

Stage 1: audit_log (always) + notification (on_deny)   → Confirm routing
Stage 2: Enable approval_gate in sandbox, narrow scope  → Validate loop
Stage 3: Promote to production in narrow scope          → Monitor audit logs
Stage 4: Expand scope                                    → Confirm no disruption

📌 Configuring destinations and credentials

All destinations and credentials are configured in Settings → Integrations, not inside individual controls. This allows:

• Multiple controls to share the same destination
• Credential rotation without editing individual controls
• Centralised audit of outbound integration activity

🛠️ Troubleshooting

Full: Troubleshooting Controls