Introduction

A policy bundles controls and applies them to assets. It is the only thing that connects a rule to an agent, which makes it the unit your governance programme is actually measured in.

Ask "is this agent governed" and the answer is a policy, or it is nothing.

Where to find it

AI Governance > Policies

Access to AI Governance is granted through platform roles. Ask your workspace administrator, or see Settings > Governance > Roles for how permissions are assigned.

What a policy does

1. Carries controls — One or more, added from its Controls tab. The same control can sit in many policies.

2. Covers assets — Agents and models, chosen by hand or matched by rule on its Applies to tab.

3. Produces incidents — Every control hit on a covered asset raises one, and the policy is named on it.

Policies do not detect anything themselves. They are the delivery mechanism.

System and custom policies

Policies has two tabs, System Policies and Custom Policies. The tab bar appears only for users with the STANDARD permission; other users see Custom Policies only.

Most programmes run both: a framework pack for the obligations you are audited against, and custom policies for the risks specific to what your agents do. See System Policies vs Custom Policies.

The Policies table

A policy is Active or Inactive; disabling stops its controls evaluating without unpicking its configuration. Each row also has Edit details and Delete.

"Read CONTROLS and APPLIES TO together. A zero in either column means the policy is decoration."

Inside a policy

Opening a policy gives you three tabs.

1. Controls — The controls this policy enforces. Each control row has an on/off switch for this policy, an incident count and a Remove action; clicking a row opens the control in a new tab. Add controls opens a searchable drawer of enabled controls — "pick controls to bind to this policy" — with a New control button.

2. Applies to — "Choose the agents and models this policy applies to", by hand-picking or by rule. See Apply a Policy to Assets.

3. Incidents — What this policy has raised. The fastest way to judge whether it is tuned.

Creating a policy

New Policy asks only for a name and a description; the creator becomes the owner. Controls and assets are added afterwards from their own tabs — the create step is deliberately light so you are not forced to decide everything at once.

A new policy starts enabled and covering nothing, which is the safe default: it cannot act until you point it at assets.

When two policies cover the same asset

Both apply. Each policy evaluates its own controls, and each can raise incidents.

Neither policy overrides the other. When actions differ, Block wins: if any control in any policy blocks, the request is blocked. The practical consequence is duplication: an asset covered by two policies that both check for the same thing — even with the same control — raises one incident per policy for one event. If your incident volume looks inflated, overlapping coverage is the first thing to check.

Best Practices

1. One policy, one intent — A policy named for an obligation or a risk is reviewable. A policy named "General" accumulates controls nobody can justify.

2. Report coverage, not policy count — "Nine policies" says nothing. "Every customer-facing agent is covered by at least one" is a programme status.

3. Watch for zeros — A policy with no controls or no assets is doing nothing, and it looks like it is.

4. Create each policy from its owner's account — The creator becomes the owner, and its incidents need somewhere to go.

5. Prefer rules for categories — Hand-picked coverage silently falls behind as new agents appear.

6. Review overlap before adding another policy — Two policies checking the same thing double the incidents without doubling the safety.