Policy engine
Cloud & Enterprise · Enterprise plan
The policy engine decides whether a subject may perform an action on a resource. It
supports role-based (RBAC), attribute-based (ABAC), and relationship-based (ReBAC) rules,
and is consulted during the authorize decision flow. It ships in the
commercial edition (policy_engine).
Rule shape
A policy is an allow or deny rule with the following fields:
| Field | Purpose |
|---|---|
subject | Who the rule applies to: * (everyone), role:x, owner:x, or a specific agent id. |
resource | The resource the rule governs. |
action | The action being evaluated (e.g. payments.refund). |
effect | allow or deny. |
priority | Ordering weight among matching rules. |
conditions | Optional attribute/relationship conditions (JSONB) for ABAC/ReBAC matching. |
Deny wins
When multiple rules match a request, deny always wins: a single matching deny rule denies the action regardless of any matching allow rules. This makes the safe outcome the default and keeps allow rules from accidentally overriding an explicit prohibition.
Fail closed on load
If the policy set cannot be loaded — for example a storage error — the engine fails closed and denies rather than allowing traffic through an unknown policy state. Combined with deny-wins, this ensures a misconfiguration or fault never silently opens access.
Endpoints
| Method | Path | Purpose |
|---|---|---|
GET | /v1/policies | List the org's policies. |
POST | /v1/policies | Create a policy. |
DELETE | /v1/policies/{policyID} | Delete a policy. |
Next steps
- Governance overview — where policy evaluation sits in the authorize flow.
- Delegation & approvals — spend limits, permissions, and approvals.
- Compliance — policy dry-run: what the live policy set would decide.