Governance Policies

A policy is a named group of controls that represents a single compliance requirement—for example, your internal AI standard or an external framework like the EU AI Act or NIST AI RMF. A policy is met when every control above Low importance passes.

How policies work

• A policy contains one or more controls.
• Each project belongs to at most one policy. A single policy can govern many projects.
• Every project assigned to a policy is assessed against all of that policy's controls, plus all controls inherited from its base policy.
• The policy is met for a project when every control above Low importance resolves to PASS. A Low-importance control can resolve to FAIL, ERROR, or NO_DATA without causing the policy to fail.

Create a policy

1. Navigate to your organization's Governance page.
2. Click New Policy.
3. Enter a Name and an optional Description.
4. Add the controls this policy should enforce.
5. Save the policy.

Assign projects

A policy has no effect until projects are assigned to it. From the policy, assign the projects it should govern. Each assigned project is then continuously assessed against the policy's controls.

To move a project to a different policy, simply reassign it—a project always belongs to exactly one policy or none.

Base policies

A policy can extend a base policy and inherit its controls. This lets you define shared requirements once in an org-wide baseline, then apply them to many team or application policies.

:::info There is no separate button to create a "base policy". A policy automatically becomes a base policy when another policy extends it. :::

To extend a base policy:

1. Open or create the policy that should inherit the shared controls.
2. Click Extend base policy near the page heading.
3. Select the policy to use as the base.
4. Click Save.

The selected policy receives a Base policy badge after it is extended.

• Inheritance is live. Adding or removing a control on the base immediately changes the effective control set of every policy extending it; each extender's projects pick up the change at their next assessment.
• Inheritance is strictly additive. An extending policy always carries every inherited control (shown as via ‹base policy› in the app) plus its own. It can't opt out of an inherited control.
• Hierarchies are two levels. Policies that already extend another policy can't be selected as bases. A base policy can't extend another policy.
• A base is an ordinary policy. It can still have its own projects assigned directly, and its page reports on those projects only.
• Deleting a policy that others extend is blocked until the extending policies are removed or deleted with it.

Through the public API, a policy's controls field lists every control that applies to its projects, inherited ones included, and a read-only isBasePolicy flag tells you whether other policies extend it.

Custom Agent Skills

Governance policies can also define the governance Custom Agent Skill for coding agents. Define the skill once on the policy, and every project assigned to that policy receives the same skills/governance/SKILL.md content from the project-scoped /skills.git endpoint.

Use this to give Claude Code, Codex, Cursor, and other coding agents the same policy-specific instructions your teams are expected to follow. See Standardize Onboarding with Custom Agent Skills for the end-to-end setup.

When assessments run

A project's controls are assessed against its policy:

Each assessment produces a historical record, so you can track how a project's compliance posture changes over time.

Next steps

• Gate Deployments in CI/CD — block non-compliant deployments using a policy
• Controls — configure the requirements inside your policy
• Custom Agent Skills guide — distribute policy-specific governance instructions to coding agents
• Introduction to AI Governance — learn how policies, controls, and gating fit together

Last updated on August 12, 2026