Control CoreDocs

Quick Start: Testing Controls

Get started with the Control Impact Simulator (CIS) in 5 minutes.

Scope note: The Control Impact Simulator evaluates one control against one input payload per run. It uses the same OPA engine the Bouncer uses at runtime. It is not a blast-radius, traffic-replay, or fleet-impact tool.

What You'll Learn

  • How to select a control for testing
  • How to run your first simulation
  • How to interpret results
  • How to save test scenarios

Prerequisites

  • Access to Control Core PAP
  • At least one control created in Sandbox environment
  • Basic understanding of your control's purpose

Step 1: Open the Control Impact Simulator (30 seconds)

  1. Log into Control Core PAP.
  2. Click Control Simulator in the Operations section (left sidebar).
  3. You'll see a three-panel interface: control selection (left), input builder (center), results and history (right).

Step 2: Select a Control (1 minute)

In the left panel:

  1. Check your current environment badge (Sandbox recommended for first test)
  2. Open the Select Control to Test dropdown
    • For 10+ controls, a search box appears automatically
    • Search by control name, status, or resource name
  3. Choose any control from the list
  4. Notice the automatic display of:
    • Resource being protected
    • Bouncer enforcing the control
    • Target actions (HTTP methods)

What just happened:

Control Core automatically linked your control to its enforcement context. You didn't need to look up configuration—it's all there.

Step 3: Configure Test Inputs (2 minutes)

In the center panel:

The form you see is automatically generated from your control's logic.

How it works:

  • Control Core parsed your Rego code
  • Found all input.* references
  • Created a form field for each one
  • Guessed the data type and added a default value

What you do:

  1. Fill in the form fields with test values

    • For strings: Type text (e.g., "admin")
    • For numbers: Enter numbers (e.g., 100)
    • For booleans: Toggle the switch
    • For arrays: Enter comma-separated values

  2. Example input:

    • User Role: admin
    • Resource Type: api
    • Action: read

Pro tip:

  • Click the JSON View tab to see and edit the structured input data directly
  • For large policy lists (10+ controls), the dropdown automatically becomes searchable
  • You can edit JSON directly and changes will sync back to the form fields

Step 4: Run Your First Test (30 seconds)

  1. Leave Test Type as Decision (faster)
  2. Click the big button: Run Controls Impact Test
  3. Wait 1-2 seconds for results

Step 5: Understand the Results (1 minute)

In the right panel, you'll see:

Result Card

A large, color-coded badge showing:

  • ALLOW (green) = Access granted
  • DENY (red) = Access denied
  • MASK (blue) = Granted with masking
  • NO_MATCH (gray) = No control matched

Plus a human-readable explanation.

Control Trace Timeline

Click Policy Trace tab to see:

  • Step 1: Control matched
  • Step 2-N: Each condition evaluated with pass/fail
  • Final Step: How the decision was made

Example:

Step 1: Control Matched ✓
Step 2: user.role == "admin" → TRUE ✓
Step 3: action == "read" → TRUE ✓
Step 4: Final Decision → ALLOW ✓

Step 6: Save Your Test (30 seconds - Optional)

To reuse this test later:

  1. Click Save as Scenario in the center panel
  2. Enter a name: "Admin Read Access Test"
  3. Click Save Scenario

Next time:

  1. Select the same control
  2. Choose your scenario from Load Saved Scenario
  3. All inputs auto-fill—just click Run!

Common Testing Patterns

Test a "Should Allow" Case

Goal: Verify control grants access when it should

  • Input: Provide values that meet all conditions
  • Expected: ALLOW (green)
  • If DENY: Check which condition failed in the trace

Test a "Should Deny" Case

Goal: Verify control blocks access when it should

  • Input: Provide values that violate a condition
  • Expected: DENY (red)
  • If ALLOW: Review control logic—it may be too permissive

Test an Edge Case

Goal: Verify boundary conditions

Examples:

  • Time exactly at business hours boundary
  • User with minimum required permissions
  • Resource at classification threshold

Tips for Effective Testing

1. Start Simple

Test the happy path first:

  • All conditions should pass
  • Result should be ALLOW
  • Trace should show all green checkmarks

2. Test One Condition at a Time

Change one input value to violate one condition:

  • See which condition fails
  • Verify the control responds correctly
  • Builds confidence in control logic

3. Use the Trace

The trace is your debugging tool:

  • Shows exactly which condition failed
  • No guesswork about control behavior
  • Faster than reading Rego code

4. Save Important Tests

Create scenarios for:

  • Happy path (should allow)
  • Sad path (should deny)
  • Edge cases
  • Regression tests after changes

5. Test in Sandbox First

Always test in Sandbox before Production:

  • Safe to experiment
  • Can modify control and retest
  • No impact on real users

Next Steps

Now that you've run your first test:

  • Test more controls: Build confidence across all controls
  • Create scenarios: Build your regression test library
  • Review history: See all past tests at the bottom of the page
  • Export results: Include in change requests for documentation

Getting Help

Stuck? Check these resources:

Common issues:

  • No attributes shown: Control may not have input references
  • Simulation failed: Check error message and simplify inputs
  • Unexpected result: Review trace to see which condition caused it

You're Ready!

You now know how to:

  • Select and test a control
  • Configure inputs with the auto-generated form
  • Interpret results and trace
  • Save scenarios for reuse

The Control Impact Simulator is your most important tool for building confidence in your controls. Use it before every promotion from sandbox to production.