π οΈ Troubleshooting Controls
Audience: Control authors, DevOps, security engineers Related: Troubleshooting Overview Β· Admin Troubleshooting
π Actions
Action did not fire
- Confirm
BOUNCER_ENABLE_POST_DECISION_ACTIONSis notfalsein Bouncer config - Verify the action trigger matches the expected decision outcome (
on_allow,on_deny,on_mask,on_error,always) - Check Bouncer logs:
docker compose logs bouncer | grep POST_DECISION_ACTION - Confirm
config.destination_refandconfig.credential_refin the action point to valid, active integrations in Settings β Integrations
π PIP attributes
Missing PIP attributes in Visual Builder
- Confirm the data source connection is Active in Settings β Data Sources
- Verify the attribute mapping uses the correct
target_attributeanddata_type - Check the last sync timestamp β click Sync Now to force a refresh
- In the Wizard Context Enrichment panel: select the PIP Connection first, then map Attribute/Endpoint to Target Path (the connection must be selected first for attributes to appear)
Attribute resolves to undefined at runtime
- Confirm the target attribute name in the mapping exactly matches what the control references (e.g.
user.department, notuser.dept) - Check
runtime_tierβ ifsnapshot, confirm the latest sync populated the value - For
decision_timetier: confirm the data source is reachable from the Bouncer at runtime
π Semantic Explorer
No columns appear in Semantic Explorer
- Click Refresh Auto-Tags for the selected data source
- Confirm the connection test succeeds and schema discovery returns tables/columns
- Verify provider credentials have metadata-read permissions (read-only is preferred)
- If using manual overrides: ensure table/column names exactly match the discovered schema
Auto-tags look incorrect
- Use manual override in Semantic Explorer (click a tag β Override β Save)
- Add a short override reason for audit traceability
- Re-run a simulation with a generated test case to confirm the control evaluates correctly after the override
π Simulator
"Generate Test Case" button is greyed out or fails
- Confirm the control has at least one valid condition with an input attribute (e.g.
input.subject.department) - Confirm at least one data source has synced successfully
- Browser network panel: check
POST /v1/pis/policies/{id}/generate-test-casefor the error response
Denial replay is empty
- Confirm audit logs include
DENYorFAILUREoutcomes in the selected environment - Verify the selected environment matches the Bouncer's
ENVIRONMENTsetting - Send a few test requests through the Bouncer in sandbox, then retry
- Use Manual Payload Mode if no denial records are available yet
Denial explanation not shown
- Explanations are generated only for
DENYoutcomes - Confirm trace data is present in the simulation result panel
- Browser network panel: check
POST /v1/pis/policies/{id}/explain-denialreturns HTTP 200
Decision evaluates to undefined or No Match
- The control has no matching condition for the provided input β treated as implicit deny
- Add a
print()statement in the Rego editor to trace evaluation paths - Verify attribute paths match exactly:
input.subject.department, notinput.user.department - Open Semantic Explorer to confirm field names from the data source
π Control promotion
Promote button is disabled
- Confirm the License Server connection is active: Settings β General β Telemetry β Test Connection
- Confirm the subscription tier is active: Settings β General β Subscription
- See License Management
Control promotes but does not enforce in production
- Confirm the Production Bouncer is linked to this control (Settings β PEPs β Bouncer status)
- Verify the Policy Bridge sync completed: the Bouncer should show an updated sync timestamp
- Confirm traffic is going through the Bouncer (port 8080), not directly to the resource
- Check
docker compose logs bouncer | grep -i "policy_sync"for sync errors
Production metadata mismatch after promotion
Controls that rely on PIP attributes can fail in production if the production data source returns different field names or values than sandbox.
- Use SCCA: "Compare sandbox vs production metadata values and list parity gaps"
- Confirm
region,risk_level,kyc_status, and other enum attributes return identical values across environments - Fix mismatches in Settings β Data Sources β Mappings before retrying promotion
π Approval gates and break-glass
Requests blocked after enabling approval gate
- Check Controls β Approval Inbox for pending approvals
- Confirm
approver_roleis a valid role and approvers can access the Approval Inbox - Verify notification routing:
notify_destination_refmust point to a configured destination so approvers are alerted
Break-glass path still fails
- Verify
break_glass_notifydestination references exist and are Active in Settings β Integrations - Confirm reason and TTL requirements are aligned with your runbook
- Pair break-glass with
audit_logonon_denyto capture decision evidence for each emergency request - If rollout is new: temporarily use alert-only actions (
audit_log+notification) before enabling hard enforcement
π SCCA
SCCA guidance seems too generic
- Provide resource and control context in your prompt: "For the control
finance-read-accesson resourceData API, add a conditionβ¦" - Ask for explicit wizard tab actions: "In the Conditions tab, add a condition for user.department equals Finance"
- If SCCA does not see your PIP attributes: confirm the data source has synced recently