Policy Sets

Group Rego policies into sets scoped to your organization, projects, or individual workspaces.

What Is a Policy Set?

A policy set is a named collection of Rego policies with a shared enforcement mode and scope.

Scope Hierarchy

Policy sets can be scoped to three levels:

Scope	Applies To	Creation Requirement
Org (global)	All workspaces in the org	Org `owner` or `admin` role
Project	Workspaces within a project	`write` access at project scope
Workspace	Single workspace	`write` access at workspace scope

Only one scope level should be set. If workspace_id is provided, project_id must match the workspace’s parent project.

Creating a Policy Set

POST /policy-sets
{
  "name": "production-safety",
  "description": "Policies for production workspaces",
  "enforcement": "mandatory",
  "profile": "terraform",
  "project_id": "proj-uuid"
}

Field	Type	Required	Default	Description
`name`	string	Yes	—	Must be unique within scope
`description`	string	No	—	Human-readable description
`enforcement`	string	No	`mandatory`	`mandatory` or `advisory`
`source_type`	string	No	`db`	`db` (policies stored in DB) or `git` (policies from Git)
`profile`	string	No	`terraform`	`terraform`, `kubernetes`, `security`, or `custom`
`project_id`	UUID	No	—	Project scope
`workspace_id`	UUID	No	—	Workspace scope
`git_path`	string	No	—	Used when `source_type` is `git`

Adding Policies

POST /policy-sets/{id}/policies
{
  "name": "no-destroy-prod",
  "description": "Prevent destroying production databases",
  "rego_source": "package forgecroft.policy\n\ndeny[msg] { ... }"
}

The Rego source is validated by compiling it and running against a stub input. It must:

Contain package forgecroft.policy
Have at least one of deny or require_approval rules
deny must return an array of strings
require_approval must return an array of objects

Updating a Policy Set

PATCH /policy-sets/{id}
{
  "enforcement": "advisory",
  "enabled": false
}

Mutable fields: enforcement, enabled, description, profile. At least one field must be provided.

Deleting a Policy Set

DELETE /policy-sets/{id}

Requires admin access at the set’s scope (stricter than write). Global sets require org owner/admin.

Effective Role

When listing or getting policy sets, the response includes effective_role based on your access:

admin — you can delete the set
write — you can modify policies within the set
read — you can view the set and its policies

Git-Sourced Policy Sets

Set source_type: "git" and provide git_path to load policies from a Git repository instead of storing them in the database. This is useful for:

Version-controlling your policies alongside your infrastructure code
Reviewing policy changes through PRs
Sharing policies across organizations

Listing Policy Results for a Run

GET /runs/{runId}/policy-results

Returns all policy evaluation results for a specific run, including which policies passed or failed and their violations.

POST /policy-sets — Create a policy set
GET /policy-sets — List policy sets
GET /policy-sets/{id} — Get a single policy set
PATCH /policy-sets/{id} — Update a policy set
DELETE /policy-sets/{id} — Delete a policy set
GET /policy-sets/{id}/policies — List policies in a set
POST /policy-sets/{id}/policies — Add a policy
GET /runs/{runId}/policy-results — List policy results for a run