Policies

▱

Policy Packs

Route: /policy-packs Who: Platform engineers and admins
(platform_engineer and above)

A policy pack is a versioned bundle of policies with a status (for example draft vs published) and assignments.

What you can do:

Create a pack, name it, set category and version label.
Add installed policies to the pack.
Assign the pack to a scope (organization, project, environment — see labels in the UI).
Publish, archive, or restore a pack.
View dashboard KPIs: pack count, assignment count, policy coverage.

Use packs when several teams should share the same baseline (for example “AWS security baseline” or “Kubernetes hardening”) instead of assigning dozens of policies one by one.

Catalog bundles (SOC 2, CIS, PCI, HIPAA, Zero Trust, AI Governance, and others) can be installed from the Policy Library and then grouped or assigned as packs.

▣

Policy Library

Route: /policies Who: OWNER and ADMIN

The library is the full policy catalog and the org’s installed policies.

Typical tabs / panels:

↗

OverviewKPIs, quick actions, connectors to scans and packs

⊞

CatalogBrowse 200+ built-in policies by cloud, Kubernetes, IaC, identity, FinOps, AI, and more

◇

BundlesInstall an entire baseline (CIS, SOC 2, PCI DSS, HIPAA, Kubernetes hardening, …)

▤

My policiesInstalled/custom policies: versions, assignments, tests, publish

▶

EvaluateRun a policy against a chosen target (stack/path) without waiting for a deploy

◷

HistoryPast evaluations

◎

Catalog domains (built-in)

AWS, Azure, GCP, Kubernetes, IaC, CI/CD, AI, identity, networking, FinOps, operations, containers.

⚙

Engines

Policies can be expressed for engines such as OPA/Rego, Kyverno, CEL, Gatekeeper, Checkov, Trivy, and Axio-native rules. You pick an engine when creating a custom policy; catalog entries already have an engine.

♢

What you can do with a single policy

Install from catalog (creates an org copy you can assign).
Assign to a scope so evaluations actually run.
Test with saved test cases; publish a new version.
Set enforcement (for example enforcing vs advisory) so the deploy gate knows whether to block.

Installing a catalog policy does nothing until it is assigned (directly or via a pack).

Evaluation vs live scan vs gate

Mechanism	When it runs	Result
Evaluate in Policy Library	On demand from the UI	Pass/fail for that target
Live scan	On connected Git repos (if enabled)	Findings + violations
Policy gate	PLAN / APPLY	Block, warn, or ignore per gate mode

ⓘ

All three use the same policy definitions. The gate is the only one that can stop a deployment.

✎

Custom policies

Admins can create a policy with name, engine, category, severity, and rule body (subject to canCreatePolicy in the UI).

Prefer catalog policies for common CIS/cloud controls; use custom policies for org-specific rules.

Keep versions: publish rather than silently editing production assignments.

♧

Role presets (policy vs approval)

Apply governance role presets from the API (POST /organizations/:orgId/roles/governance-presets) or as documented in enterprise governance.

Preset	Manage policies	Approve exceptions
Compliance Officer	No	Yes
DevSecOps Engineer	Yes	No
Developer	No	No

This is how you implement separation of duties without giving everyone ADMIN.

Policies: library, packs, and evaluation