Skip to content
Wicket

Why structured policies (not raw Cedar)

Wicket uses Cedar as its policy language under the hood, but the primary editing surface is a structured form — not a Cedar text editor. This page explains why, and when you’d want to reach for raw Cedar anyway. (Curious about the language itself? The Cedar site is the authoritative reference — you won’t need it for day-to-day Wicket use.)

The problem with raw Cedar for most users

Cedar is expressive and precise, but it requires understanding:

  • Entity type namespaces (GitHubMCP::Action::"search_repositories")
  • Principal/action/resource triple semantics
  • The difference between permit and forbid with and without unless clauses
  • Schema constraints from the Cedar schema file

For most operators — “I want to block destructive GitHub tools after 5pm” — this is unnecessary complexity. Getting a forbid clause wrong silently allows or blocks more than intended, with no feedback loop until an audit entry shows up.

What structured policies give you

The structured editor captures intent in human terms:

  • Effect: allow or block
  • Service: which connector
  • Tools: checked from a list, grouped by read/write/destructive tier
  • Principal scope: all members or specific members
  • Time constraints: days of week, hour range, date window
  • Repo/channel restrictions: GitHub repos or Slack channels by picker

Wicket compiles this to Cedar internally. You can preview the generated Cedar at any time — the Preview button on any policy shows the exact text that will be evaluated.

Guarantees the structured editor provides

  • No orphaned policies: tools are validated against the connector’s schema at save time
  • Predictable precedence: precedence is plain Cedar semantics — a matching forbid always overrides a matching permit, and a call no permit covers is denied by default. The compiler only emits permit/forbid rules with when {} guards; it never relies on unless clauses
  • Version history: every save creates a diff-tracked version you can roll back to
  • Simulate before enforce: test a policy against a hypothetical call without enabling it

When you’d want raw Cedar

The structured editor covers more than tools and time: resource conditions handle attribute rules like “only public repositories” or “not on protected branches”, and session conditions handle history-dependent rules. What it does not cover is the long tail of arbitrary Cedar — for example, cross-entity constraints like “only if the PR author is in this team”.

Raw Cedar editing is not currently in the product UI. If you have a rule the structured editor can’t express, contact support.