Preview and simulate before enforcing

A policy that’s wrong in either direction hurts: too strict and your agents stall mid-task, too loose and the restriction you wanted isn’t there. Wicket gives you two checks before a policy takes effect.

Preview: see the compiled policy

In the policy builder, click Preview at any time. Wicket compiles your draft and shows the generated Cedar policy text — the exact rule that will be evaluated. You don’t need to read Cedar fluently; the preview is there to confirm the scope matches your intent (right tools, right principal, right conditions).

Simulate: replay real traffic against the draft

Simulation answers the question that matters: “if this policy had been active, which of my recent calls would have changed decision?”

1. Open Simulate

   In the policy builder (new policy or editing an existing one), click Simulate.

2. Read the before/after counts

   Wicket replays your agent’s audit traffic from a fixed 24-hour lookback against the draft and reports:

   • Before — how many of those calls were allowed / denied as they actually happened
   • After — how many would be allowed / denied with your draft active
   • Changed — the number of calls whose decision flips
   • Unmatched — calls skipped because they lack the Cedar fields needed to replay (e.g. older audit rows, or rows with no caller IP when the policy uses network conditions)

   Each replayed row also carries a baselineDecision — the decision from the other enabled policies alone, with the draft excluded — so you can separate the draft’s effect from what was already in place.

3. Inspect the flipped rows

   The result table lists each replayed call with its tool, member, resource, timestamp, current decision, and draft decision — changed rows are highlighted. This is where misconfigurations show up: a forbid that would block your CI agent’s create_pull_request, or a permit that fails to cover a tool you expected.

4. Adjust and re-run

   Edit the draft and simulate again until the changed set is exactly what you intend.

5. Save and enable

   Save the policy. New policies are created enabled; existing ones keep their toggle state. From the moment a policy is enabled, every matching call is enforced — no restart, no propagation delay.

Tip

For high-stakes forbids, pair simulation with a rollout habit: enable during a quiet period, then watch the Audit tab filtered to result=DENY and your policy’s name for the first hour. Rolling back is one click on the policy’s toggle.

When simulation can’t help

Simulation replays past traffic. It can’t predict calls your agents haven’t made yet — a brand-new tool, a new member, a resource that didn’t exist last week. For those, lean on:

• Resource conditions that express intent (“only public repos”) rather than enumerating resources
• The default-deny backstop: a call no permit policy covers is denied

Related

• Author your first policy
• Policy recipes
• Work with audit logs