Policy objects and host groups
How host groups and the five policy kinds work, how precedence is resolved when more than one assignment matches a host, and why they all live on one console page today.
A policy object is a named, reusable configuration — a prevention posture, an update ring, a set of exclusions — that you assign to a group of hosts rather than to one machine at a time. A host group decides which machines a policy applies to. Together they are what turns a single organisation-wide setting into something you can vary by department, by platform, or by how sensitive a machine is. This article covers both objects: what a host group is, the five policy kinds, and — the part that actually matters when two assignments disagree — how precedence is resolved.
Host groups: static or dynamic
A host group is either static or dynamic, chosen when you create it, in the Host groups panel.
- Static
- An explicit list of member hosts. You add and remove machines one at a time, in the group's Members list. Nothing evaluates on its own — membership is exactly what you put there.
- Dynamic
- A rule expression that a host either matches or does not. The rule is a predicate over
context.hostname,context.platform,context.architectureandcontext.domain— a machine belongs to the group for as long as it matches, with no membership list to maintain by hand.
The rule language is the same CEL-based expression engine IAM's dynamic group rules use, applied here to a different set of variables. If you have already written a group membership rule for users, the syntax and operators will be familiar; see Groups and automatic membership for the language itself rather than re-learning it here. A host-group rule only ever sees the four context.* fields above — it cannot reference a user or an app, because those variables are simply never supplied to it on this path.
The five policy kinds
| Kind | Console label | Covers |
|---|---|---|
prevention | Prevention | Whether prevention is enabled, ML sensitivity, and the on-write action. Collection settings — which channels a sensor reports, sampling — also ride inside this kind's settings rather than having a kind of their own; that is a deliberate scope decision, not an oversight. |
sensor_update | Sensor update | Which update ring a host's bundle carries (see Sensor rollout rings). |
response | Response | The response-script allowlist a host group's sensors are permitted to run — see Response scripts and run-script tickets. |
exclusions | Exclusions | Paths and scopes carried in the bundle as exclusions from prevention/scanning. |
fim | File integrity monitoring | The watch-path list a sensor's FIM collector applies — see File integrity monitoring. |
A policy is a row with a kind, a settings document and an enabled flag. At most one policy per kind per organisation can be marked as that kind's tenant default — the fallback used when nothing more specific matches a host, described below.
How precedence is resolved
A host can be a member of more than one host group, and more than one of those groups can have a policy of the same kind assigned. When that happens, exactly one rule decides which policy the host actually receives, applied in this order:
- A host-group-scoped assignment always outranks the tenant-wide fallback, regardless of the fallback's own precedence number. Being assigned to any matching group beats not being scoped to a group at all.
- Among assignments from groups the host actually belongs to, the lowest precedence number wins. The console's own hint states this plainly: lower number wins.
- If nothing matches at all — no group assignment, no tenant-wide assignment — the kind's tenant default policy applies, if one is marked as default. If there is no default either, the host has no effective policy of that kind.
| Assignment | Scope | Precedence | Wins? |
|---|---|---|---|
| Finance prevention policy | Host group "Finance workstations" | 10 | Yes — lowest precedence among matching group assignments |
| Default prevention policy | Tenant-wide fallback (no host group) | 0 | No — a group assignment always beats the fallback, whatever its own number says |
| Contractor prevention policy | Host group "Contractors" (host is not a member) | 5 | No — the host does not belong to this group, so this assignment never applies to it |
This is why the tenant-wide fallback assignment (host_group_id IS NULL) is a distinct concept from a policy's is_default flag: a tenant can assign a non-default policy tenant-wide without renaming which policy is the default, and the two only converge when nobody has bothered to override the fallback. The resolution itself is a pure function over the assignments you can see in the console — nothing about it depends on which sensor asked, only on which host groups that sensor's endpoint belongs to.
Everything here lives on one console page
Creating, editing and assigning a policy uses a generic Settings JSON box for every kind except FIM, which has a structured editor (watch paths, recursive, realtime, who-data, ignore patterns, diff cap). Every write — creating or editing a host group, a policy, or an assignment — is recorded in an append-only audit trail, so a policy change is always attributable to who made it and when.
Who can manage this
Reading host groups, policies and assignments needs xdr:policy.read; creating, editing, assigning and deleting them needs xdr:policy.write. Both are ordinary member-grade permissions in the default role set — unlike custom IOA rule authoring, which is admin-only (see Custom IOA rules).
What to read next
- The signed policy bundle — what a host actually receives once these objects are resolved, and what it does and does not enforce today.
- Indicators of compromise and Custom IOA rules — the two kinds of detection content the bundle also carries.
- File integrity monitoring — the one kind with its own structured editor.