Introduction

Creating a policy is deliberately almost empty: New Policy asks for a Name (required) and a Description, and the person who creates it becomes its owner. The real work happens afterwards, in two places, and the create step is designed not to pretend otherwise.

Where to find it

AI Governance > Policies > New Policy.

The three steps, in the order the product enforces

Create the policy — Name and description; you become the owner. It is created enabled, and it governs nothing.
Add controls — On the Controls tab. Until it has controls it has nothing to check.
Point it at assets — On the Applies to tab. Until it covers assets it has nothing to check against.

Note: A policy that has completed only step one is live and inert. It shows Active, appears in every list, and does absolutely nothing. This is the most common misreading of the Policies screen — a healthy-looking list of policies with no controls and no assets behind them.

Naming, which matters more here than usual

The policy name is what appears on every incident the policy raises, in the queue where someone is triaging under time pressure. It is the fastest available context, so it should carry the scope, not just the topic.

Better	Weaker	Why
Confidential topics — customer-facing	Confidential topics	Says who it applies to, which is half the triage question
PII — outbound tool calls	Data protection	Names the surface, so an unexpected hit is obviously unexpected
Secrets in tool input — production agents	Security policy	Distinguishes it from three other policies that would also be called that

The description carries the rest: "What this policy enforces and why." The "why" is the part nobody writes and everybody later wants — specifically, which obligation or incident led to the policy existing.

The owner is who answers for it

A policy's owner is the person who decides when a control is too noisy to keep, when a flag should become a block, and when the policy has served its purpose. That is not the same person as the agent owner. Because the creator becomes the owner, create the policy from the account of the person who should answer for it.

Adding controls

The Controls tab lists the controls the policy enforces, with Add controls opening a searchable picker of enabled controls — "Pick controls to bind to this policy." — and a New control button. Controls are reusable objects: the same control can be bound to several policies, and it is the same control, not a copy.

That reuse cuts both ways, and it is worth being deliberate about:

Editing a shared control changes every policy that binds it. Tuning a threshold to quieten one noisy policy quietly retunes the others. (Its on/off switch is different: that is per policy.)
Removing a control from a policy does not delete it. It stays available, still bound wherever else it was bound.

Where a control needs different behaviour in two policies — flag here, block there — that is two controls, not one shared control you keep re-editing.

What you do not get to choose

Two properties are fixed by the fact that you are in AI Governance rather than chosen in the editor:

Property	Fixed to	Meaning
Scope	Global	The policy targets assets — agents and models — not individual users
Surface	Chat	It governs assistant conversations and tool use

The same policy object exists elsewhere in the platform with different values, which is why the editor has affordances that look absent here. In AI Governance those two answers are already made.

How many policies to have

The pull is toward one big policy holding every control, because it is less to manage. Resist it: a policy is the unit you enable, disable, assign an owner to and report on, so one policy means one owner, one on/off switch, and no way to say "we run PII checks on customer-facing agents only".

A workable shape is one policy per risk theme per audience — the granularity at which you would ever want to turn something off independently.

"Split policies where you would want to switch one off without switching off the other. Anywhere else, splitting is just more objects."

Before you consider it done

Test the controls first — Each control has a test tool. A policy is only as good as its controls, and testing after it is live means testing on production traffic. See Test a Control Before Enabling.
Start on flag — Watch what it catches for a period before turning anything to block. Almost every control is noisier on real traffic than in testing.
Check the Incidents tab a day later — The policy's own tab shows what it is catching. Nothing at all usually means it is pointed at nothing — check Applies to before concluding your agents are clean.

Create a Custom Policy