Control CoreDocs

Visual Builder — Wizard Guide

Audience: Control authors, compliance officers Time: ~10 min to build your first control with the Wizard

The Visual Builder (also called the Lego Builder or Wizard) lets you compose controls using a drag-and-configure interface. It generates Rego automatically. You can preview the generated Rego at any time and switch to the code editor if you need finer control.

Build flow overview

1. Select resource + bouncer
2. Add conditions (principal / resource / action / context)
3. Group conditions with AND / OR logic
4. Choose effect (allow / deny / mask)
5. Configure context enrichment and post-decision actions
6. Preview Rego → Save → Deploy to Sandbox

Step 1 — Select resource and bouncer

On the first page of the Wizard, select:

  • Resource — the protected asset this control applies to
  • Bouncer — which enforcement instance(s) will receive this control

This binding is important: the Policy Bridge syncs this control only to the linked Bouncer(s). A control not linked to a Bouncer will not enforce.

Step 2 — Add conditions

Click Add Condition to add an attribute check. Each condition specifies:

FieldExample
Attributeuser.department, action, resource.data_classification
Operatorequals, in, contains, starts_with, greater_than, regex
Value"Finance", ["read","export"], "CONFIDENTIAL"

Full operator reference: equals · not_equals · contains · in · not_in · starts_with · ends_with · greater_than · less_than · regex

Step 3 — Group conditions with AND / OR

Conditions can be grouped into logical blocks:

Group 1 (AND — all must be true):
  user.department  equals  "Finance"
  user.authenticated  equals  true

Group 2 (AND):
  action  in  ["read", "export"]
  resource.data_classification  equals  "CONFIDENTIAL"

Groups combined: AND (both groups must match)

Use OR between groups to express "match any of these scenarios":

Group 1 (user is Finance manager)  OR  Group 2 (user is auditor)

Troubleshooting: An attribute is not in the dropdown? The attribute comes from a connected PIP data source. Go to Settings → Data Sources, confirm the connection is active, and check the last sync timestamp.

Step 4 — Choose the effect

  • Allow — permit the request when all conditions match
  • Deny — block the request when conditions match
  • Mask — allow but redact or transform sensitive fields in the response

Step 5 — Configure context enrichment and post-decision actions

Context enrichment

Context enrichment pulls additional attributes into the decision at runtime from a connected PIP:

  1. Click Add Context Source
  2. Choose the Source type (PIP data source)
  3. Select the Connection (the specific configured data source)
  4. Map Attribute/Endpoint to a Target Path that your conditions can reference

Post-decision actions

Actions fire after the allow/deny decision. They don't change the outcome — they add operational side-effects:

Action typeUse case
audit_logAppend a structured decision record to Control Core audit trail
notificationAlert via Slack, Teams, PagerDuty, email
webhookPOST to an external endpoint (SIEM, ticketing, workflow)
siem_logWrite a structured event to Splunk, QRadar, or any SIEM
approval_gatePause request and require human approval. Configure approver role, TTL, escalation, and quorum.
break_glass_notifyNotify on emergency override access

Configure each action:

  1. Choose Action type
  2. Choose Trigger: on_allow · on_deny · on_mask · on_error · always
  3. Select Destination (a configured integration) via destination_ref
  4. Select Credential reference via credential_ref

Best practice: Always add an audit_log action on every control. Start with audit_log + notification before enabling approval_gate to validate routing before hard-blocking requests.

Troubleshooting: Action did not fire?

  • Confirm BOUNCER_ENABLE_POST_DECISION_ACTIONS is not false in Bouncer config
  • Check trigger matches the decision outcome
  • docker compose logs bouncer | grep POST_DECISION_ACTION Full reference: Actions Reference

Rollout guidance for approval gates and break-glass

approval_gate and break_glass_notify can intentionally pause request flow. Do not enable hard gating before validating:

  1. Start with audit_log + notification to confirm routing is correct
  2. Test approval flows end-to-end in sandbox: submit a request → confirm approver receives notification → approve → confirm request proceeds
  3. Enable approval_gate in a narrow scope (one endpoint, one user group) before expanding
  4. Pending approvals surface in Controls → Approval Inbox and Settings → Approval Gates

For full approval gate configuration options (escalation, multi-approver quorum, TTL presets), see Approval Gates Admin Guide. For the JSON field reference, see Actions Reference — approval_gate.

Step 6 — Preview Rego and deploy

  1. Click Preview Rego at any time to see the generated Rego policy code
  2. If you need to tweak the logic, switch to Code Editor — the editor opens with the wizard-generated Rego pre-loaded
  3. Click Save
  4. Click Deploy to Sandbox → confirm the control status shows Active

Compliance starter packs

The Scenario Starter Catalog (in Controls → Templates) includes pre-configured packs for:

  • AI Security and Governance
  • Data Governance and Privacy
  • API Security and Partner Access
  • Financial and Payments Risk Controls
  • Healthcare and Clinical Access Controls
  • Identity, Workforce, and Zero Trust
  • DevSecOps, SDLC, and Release Governance
  • Third-Party and Vendor Access Governance
  • Insider Risk and SOC Automation

Each pack pre-fills conditions and action triggers for the scenario. Customise before deploying.

See the full list: Control Scenarios.

Next steps