Policies: library, packs, and evaluation

Policies define what Axio checks in IaC, Kubernetes, cloud resources, identity, CI/CD, and related domains. Policy Library is where you discover, install, and evaluate policies. Policy Packs group installed policies into versioned baselines you assign in one step.

◎

Access requirements

Surface Route Typical permission
Policy Library /policies governance:read, policy:manage, or compliance:manage
Policy Packs /policy-packs policy:manage

Installing catalog bundles and creating packs from official admin bundles may additionally require an organization administrator. Members with policy:manage can create and edit their own packs and assign published packs within their scope.

▱

Policy Packs

Open Security & Governance → Policy Packs. A policy pack is a versioned bundle of installed policies with a lifecycle status: draft, published, or archived.

What you can do

  • Create a pack — name, description, category, version label, and selected policies.
  • Edit, clone, publish (with version bump), archive, restore to draft, or delete (when unassigned).
  • Assign a published pack to a scope; archived packs cannot be assigned.
  • View dashboard KPIs: total packs, published, draft, archived (admin), assigned (admin), policies in packs.
  • Search and filter the pack list; KPI cards filter or sort the table below.

Assignment scopes (labels shown in the UI):

  • Organization
  • Project
  • Workspace
  • Environment
  • Stack

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.

From Policy Library Bundles, you can install a compliance baseline and optionally Create pack from that bundle to turn it into an assignable policy pack.

ⓘ

Non-admins can edit packs they created. Organization and administrator packs are use-only — assign them in your scope, or clone to make your own. Org-wide catalog install and assignment may require an administrator.

▣

Policy Library

Open Security & Governance → Policy Library. The library is the full built-in catalog plus your organization’s installed policies.

Tabs

↗
OverviewKPIs, category breakdown, recommendations, and navigation into other tabs
⊞
CatalogBrowse built-in policies by cloud, domain, severity, or framework; install individually or in bulk
◇
BundlesInstall compliance baselines (CIS, SOC 2, PCI DSS, HIPAA, Zero Trust, AI Governance, cloud baselines, …)
▤
InstalledOrg policies: enable/disable, view detail, assign, test, publish versions, create custom policies
▶
EvaluateRun enabled policies against sample demo data or live Git repos, stacks, and workspaces
◷
HistoryPast evaluation runs with pass/fail and violation detail

Quick actions and connectors

  • Quick actions: Browse catalog, Install bundle, Installed policies, Run evaluation (requires at least one enabled policy).
  • Related: Governance dashboard, Policy packs, Security insights (IaC scans), Compliance.
◎

Catalog domains (built-in)

AWS, Azure, GCP, Oracle Cloud, DigitalOcean, Kubernetes, IaC & Templates (Terraform, OpenTofu, Helm, CloudFormation, Pulumi), CI/CD & GitOps, AI Governance, Identity, Networking, Operations, Containers, FinOps.

Catalog size is loaded live from the API (hundreds of built-in policies). Use Overview and Catalog facets to browse by platform, severity, and subcategory.

⚙

Engines

Policy as code — write rules in the engine’s native format:

OPA, Rego, Kyverno, CEL, Gatekeeper, Cloud Custodian, Conftest, Sentinel.

Scanning engine profiles — classify controls and map to external tooling (Checkov, Trivy, Kubescape, Falco):

Policy Evaluate uses built-in attribute checks for these profiles; run the external scanner in CI/CD or Security Insights and map findings to the policy.

Built-in — Axio-native attribute checks evaluated inside the platform without an external engine.

You pick an engine when creating a custom policy; catalog entries already declare their engine.

♢

What you can do with a single policy

  • Install from catalog or bundle (creates an org copy).
  • Enable on the Installed tab — disabled policies are not evaluated.
  • Assign to organization, project, stack, workspace, repository, or environment scope.
  • Test with saved test cases; publish a new version with change summary.
  • Set enforcement: Enforcing, Advisory, or Disabled — the deploy gate respects enforcing policies when gate mode is Enforce.
  • Create custom policies from templates or scratch (requires valid name, engine, and rule body or parameters).

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

Evaluation vs live scan vs gate

Mechanism When it runs Result
Evaluate (Policy Library) On demand — sample demo resources or live Git repo / stack / workspace Pass/fail per policy; saved to History
Live scan (Security Insights) On connected Git repos when enabled, or manual Scan now IaC findings and policy violations
Policy gate (Governance settings) PLAN / APPLY Enforce blocks; Advisory records only; Fail-open blocks on enforcing violations but allows deploy on evaluation errors
ⓘ

All three use the same policy definitions. The gate is the only mechanism that can stop a deployment. Fix IaC, re-scan or re-evaluate, then retry the deployment.

How it works (Policy Library)

  1. Browse & install — pick policies from Catalog or install a baseline Bundle.
  2. Enable for your org — toggle policies on under Installed; assign via policy packs or direct assignment.
  3. Evaluate workloads — run enabled policies against sample or live targets.
  4. Track violations — review History, then remediate on My findings or the Governance dashboard.
✎

Custom policies

Users with policy:manage can create a policy with name, engine, category, severity, enforcement, rule body (or parameters for built-in/scanner engines), and optional templates.

Prefer catalog policies for common CIS and cloud controls; use custom policies for org-specific rules. Keep versions — publish rather than silently editing production assignments.

♧

Role presets (policy vs approval)

Enterprise governance role presets implement separation of duties.

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

Policy exception approval requires governance:approve, not policy:manage. Org Admin/Owner retains full access to both policy management and exception approval.

Permissions summary

Permission Typical access
policy:read View policies, catalog, and evaluation results.
policy:manage Install, create, enable, assign, evaluate, and manage policy packs.
governance:manage Org-wide governance settings including policy gate mode and live-scan defaults.
governance:approve Approve policy exceptions (Compliance Officer preset).