Introduction

Two questions get bundled together and should not be. Scoping is which assets a policy covers, and the product answers it precisely. Precedence is what happens when two policies cover the same asset — and the answer there is simpler than most people expect: everything applies, and when actions differ, Block wins.

Where to find it

Open a policy > the Applies to tab — "Choose the agents and models this policy applies to."

Two ways to cover an asset

They sit side by side and behave quite differently. The product states the difference in one sentence each, and those sentences are the whole decision:

	Specific assets	Based on rule
The product says	"Hand-pick the assets this applies to. They stay covered until you remove them."	"Cover everything with these attributes. Anything added later that matches is covered automatically."
Membership	Frozen at the moment you pick	Recomputed from attributes
A new agent that fits	Not covered	Covered, without anyone acting
Fails by	Silently missing new assets	Silently catching more than intended
Right for	A named, deliberate, stable set	A category you want covered by definition

Note: This is the most consequential choice on the page, and the failure is silent either way. Hand-picked coverage decays — every agent registered after you picked is outside the policy, and nothing tells you. Rule-based coverage grows — and an agent someone registers next month is governed by a policy they have never heard of, which is usually what you wanted and occasionally a surprise.

Choosing between them

The question that decides it: if a new agent appeared tomorrow matching this description, should it be covered without anyone thinking about it?

Yes — use a rule. "Every customer-facing agent runs PII checks" is a standing commitment, and hand-picking turns it into a recurring chore you will eventually miss.
No — hand-pick. A pilot, a remediation, or anything scoped to named systems should not silently acquire members.

The two combine. A common and sensible shape is a rule for the baseline plus a handful of hand-picked additions for the exceptions the attributes cannot express.

How rules behave

A rule is an asset kind (Agent or Model) plus conditions, which can be combined with AND / OR — the kind narrows the query first, so a condition written for models cannot accidentally match agents.

Three behaviours worth knowing:

An incomplete rule does not apply at all — A rule needs an asset kind and a complete condition. An asset kind on its own would match every model there is, so the product declines to apply it rather than doing something drastic.
Membership is recalculated in the background — Rule changes save automatically, and new matches can take a moment to appear. You do not wait for a sweep.
The available attributes come from the asset record — Which is the practical argument for the ownership and department fields being filled in — unpopulated attributes cannot be the basis of a rule. See Ownership, Workspace & Department.

Precedence: policies add, they do not compete

The natural expectation from firewall rules or IAM is that overlapping policies resolve — one wins, or an explicit deny beats an allow. That model does not apply here, because governance policies are not permissions.

An asset covered by three policies is evaluated by all the controls in all three. Each control that breaches raises its own incident, naming its own control and its own policy. Nothing is suppressed because another policy also covers the asset.

What people expect	What happens
The stricter policy wins	Both run
A more specific policy overrides a broader one	Both run
One policy can exempt an asset from another	It cannot. Exemption is removing the asset from that policy's coverage
Overlap causes duplicate incidents	Yes. Each policy evaluates its own controls, so a control in two policies runs twice and raises one incident per policy

"Policies do not override each other. Controls accumulate — and when their actions differ, Block wins."

When actions differ

Additivity is clear for detection, and the action is settled too: if any control in any policy blocks, the request is blocked — Block wins over Flag. Masks from different controls are applied on top of each other.

Each matching control still raises its own incident, so the record is complete either way. A narrow blocking control alongside a broad flagging one over the same surface behaves as you would hope: the block takes effect, and both are recorded.

How to exempt an asset

There is no exemption mechanism, and that is a design choice rather than a gap: an exemption you can grant inside a policy is an exemption nobody reviews. The ways to stop a policy applying to one asset are all explicit:

Remove it from Specific assets — Direct, and visible on the tab.
Change the attribute the rule matches on — If the rule covers a department and the agent should not be in it, the record is what is wrong.
Split the policy — When one group genuinely needs different treatment, that is two policies with two owners — which is also the honest representation of the situation.

Verifying coverage

Coverage is checkable from both ends, and checking from both is worth the minute it costs:

From the policy — the Applies to tab lists what it covers.
From the asset — the agent's or model's Policies tab lists what covers it.

The second is the one that catches real gaps, because it starts from the thing you care about rather than from the thing you configured. An agent whose Policies tab is empty is ungoverned, no matter how many policies exist.

Scoping & Precedence