Unify Logo Footer.svg
AI Governance
Logo
Apply a Policy to Assets

Apply a Policy to Assets

Logo

5 mins READ

Introduction

A policy does nothing until it is pointed at something. Its Applies to tab is where you choose the agents and models it governs.

There are two ways to choose, and they behave differently as your estate changes. Picking the right one is the difference between a policy that keeps up and one you have to remember to update.

Where to find it

AI Governance > Policies > select a policy > Applies to

Applies to has two sub-tabs: Assets (n) for hand-picked assets and Rules (n) for rules.

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

Two ways to target assets

Specific assets

Rules

How you choose

Hand-pick from a list

Describe a condition

New matching assets

Not covered until you add them

Covered automatically

Membership is

Exactly what you picked

Whatever currently matches

Best for

A named, stable set

A category that keeps growing

They are not exclusive. A policy can hand-pick a handful of assets and also carry a rule, and an asset covered by either is governed.

Specific assets

"Hand-pick the assets this applies to. They stay covered until you remove them."

That second sentence is the whole behaviour. Membership is a list you control — nothing joins it on its own, and nothing drops out of it when an asset changes.

Step 1: Open the policy's Applies to tab

Step 2: Click Add assets

A drawer opens with a search box — "Search for agents or models" — and a Filter by asset type control with an All option, so you can narrow to agents or models before picking.

Step 3: Select the assets

Choose the assets. Changes save automatically — there is no separate Save step. Each row carries a Remove asset action. Only enabled assets are listed.

Use this when the set is genuinely a set: three named customer-facing agents, the two models handling regulated data. Its predictability is the point — an auditor can read the list and see exactly what is covered.

Rules

A rule describes the assets to cover rather than naming them, so anything matching is governed from the moment it matches.

What a rule is made of

Each rule targets an asset type — Agent or Model — plus conditions, which can be combined with AND / OR. The asset type narrows what the condition runs against, which is what stops a rule about model owners from also matching agents.

  1. Asset type — Agent or Model.

  2. Conditions — Each is a field on the asset record, an operator, and a value. The available fields come from the asset record itself, so what you can filter on reflects what your assets actually carry.

Step 1: Open Rules on the Applies to tab

Step 2: Add a rule

Pick the asset type, then build the condition.

Step 3: Let membership update

Changes save automatically. Membership is recalculated in the background, so new matches can take a moment to appear.

Refer: Rules match on fields your assets carry, so populating Owner, Workspace and Department at registration is what makes rule-based policy possible later. See Agent Record Reference.

An incomplete rule does not apply

A rule only takes effect once its condition is complete. A half-written rule is not saved as a partial match — it simply does not participate.

This is deliberate, and the reason is worth knowing: a rule that kept its asset type but lost its condition would read as "every model", and would silently apply the policy to your entire model registry. Rather than risk that, an incomplete rule is dropped whole.

"A rule with no condition is not a narrow rule. It is the widest possible one, which is why the product refuses to keep it."

Practical consequence: after editing rules, give membership a moment, then check the covered assets rather than assuming a saved rule is an active one.

Choosing between them

  1. Use Specific assets for a named set — Where the answer to "what does this cover" should be a list somebody signed off.

  2. Use Rules for a category — Where the answer should be "everything that is X", including things that do not exist yet. This is what stops governance drifting behind your estate.

  3. Use both where coverage must not depend on data quality — A rule catches the general case; hand-picking guarantees the assets that matter most are covered even if their fields are wrong.

Important considerations

  1. Coverage does not mean enforcement — A policy can cover an asset whose connection cannot execute its controls' actions. See Connection Type & Control Mode.

  2. Rule membership moves on its own — When an asset's fields change, or a new asset matches, it can leave one policy and join another. That is the feature, and it is also why rules deserve a review cadence.

  3. Hand-picked assets never leave — Even if the asset changes beyond recognition. Removing is a manual act.

  4. Policies apply to assets, agents and models alike — One policy can cover both. Asset type is a filter, not a boundary.

FAQs

What happens if an asset matches two policies?

Both apply. Their controls all evaluate, and each can raise incidents.

Does adding an asset to a policy govern its past traffic?

No. Controls evaluate traffic from the point coverage begins.

Why can I not filter on the field I want?

Rule fields come from the asset record. If the field is empty across your assets, filtering on it matches nothing useful — populate it first.

How do I see what a policy currently covers?

The Applies to tab lists it, and the APPLIES TO column in the policy list shows the count.