Author your first policy

By default, Wicket allows every tool call that passes authentication. Policies let you restrict what tools agents can call — by service, tool name, time window, or specific repos and channels.

This tutorial creates a forbid policy that blocks GitHub destructive tools (file deletion and PR merges) while leaving read and write tools unrestricted.

Prerequisites

• A Wicket agent with GitHub connected — see the Quickstart if you need one

---

1. Open the Policies tab

   In the Wicket dashboard, open your agent and click Policies. Click New policy.

2. Name and configure the policy

   Fill in the form:

   Field	Value
   Name	Block GitHub destructive tools
   Service	GitHub
   Effect	Forbid
   Principal	All members

3. Select tools to restrict

   Under Tools, find and check the destructive tier:

   • delete_file
   • merge_pull_request
   • create_repository (optional — also block repo creation)

   Tip

   Tools are grouped by read / write / destructive tiers in the UI. Check the whole destructive tier to block all deletion operations at once.

4. Preview the Cedar policy

   Click Preview to see the raw Cedar policy Wicket will compile. It should look like:

   forbid (
     principal,
     action in [GitHubMCP::Action::"delete_file", GitHubMCP::Action::"merge_pull_request"],
     resource
   );

   This is informational — you don’t need to edit Cedar directly.

5. Save and enable

   Click Save. The policy is created in the enabled state. From this point, any call to delete_file or merge_pull_request returns a deny decision — no restart required.

6. Test the policy

   In Claude Desktop or Claude Code, ask:

   Delete the README file from one of my repositories.

   Wicket denies the request. Open the Audit tab to confirm — the row shows DENY and the matched policy name.

---

Add a time constraint (optional)

Policies can include time windows. The natural goal — “allow destructive tools only during business hours” — has to respect Cedar precedence: a matching forbid always wins over a matching permit. So you cannot get the effect by leaving the blanket forbid above in place and adding a windowed permit; the forbid would still match and the call would be denied.

Instead, put the time constraint on the forbid, so the block only applies outside business hours. Replace (or disable) the blanket forbid from the steps above with a forbid policy that carries the time window:

• Effect: Forbid
• Tools: destructive tier
• Time constraints: the hours you want to block (e.g. evenings/weekends)

Then add a broad permit for the same tools (or rely on a separate permit that already covers them). Now:

• Inside the allowed window → the forbid’s time condition doesn’t match, so a permit can take effect → ALLOW
• Outside the window → the forbid matches → DENY

Note

The key rule is plain Cedar: an unguarded forbid overrides every permit, and a call no permit covers is denied by default. To carve out a time window, scope the forbid with the time condition — don’t try to “out-permit” a blanket forbid. Wicket compiles your structured policy to the matching permit/forbid rules with when {} guards; it does not use Cedar unless clauses. To learn the language, see cedarpolicy.com.

---

Next steps

• Policy recipes — common patterns for GitHub, Slack, and Linear
• Structured policy schema — full field reference
• Move to production — harden policies before team rollout