The signed policy bundle
The signed, cached, offline-safe manifest a sensor checks in for roughly every four hours — what it actually carries and enforces today, and what it carries but does not yet enforce.
The policy bundle is what a host actually receives once host groups, policy objects, indicators and rules have all been resolved into one document for that specific sensor. It is signed, it is cached to disk on the endpoint, and it keeps working when the machine is offline. This article explains what it is in plain terms, precisely what it does and does not enforce today, and why there is a Preview effective policy button in the console instead of a re-sync button.
What it is, in plain terms
Every sensor checks in for a fresh bundle on the same cadence it already uses to check for a sensor update — roughly every four hours. The request carries an ETag for the bundle the sensor already has; if nothing has changed, the server answers 304 Not Modified and nothing is re-sent. If the effective policy for that host has changed since the last check-in, the server signs a new bundle and returns it.
The bundle's content hash is computed only over its policy content — never over its version number or the time it was generated — which is what makes an unchanged policy hash identically regardless of how many times it has been rebuilt. That is also why a repeated check-in with no real change never burns a new version number: nothing new is signed or stored unless the policy content actually differs.
What it carries
| Section | What it is |
|---|---|
| Collection | Which telemetry channels the sensor should report, and sampling. |
| Prevention | Whether prevention is enabled, ML sensitivity, and the on-write action. |
| Indicators | Every active indicator of compromise scoped to this host — file hashes, domains, IPs, URLs and the rest — with its action and severity. |
| IOA rules | Every custom indicator-of-attack rule scoped to this host, with its conditions and action. |
| Exclusions | Paths and scopes excluded from prevention and scanning. |
| Containment | The allowlist a containment or RTR ticket may consult. |
| FIM | The watch-path list — recursive, realtime, who-data, hash algorithm, ignore patterns, diff cap — the FIM collector applies. |
| SCA | A narrow, injection-safe list of fact-collection targets for security configuration assessment: file existence/regex, a registry value, a running process, or a fixed command reference by ID. |
| Response scripts | The names of response scripts this host's group is allowed to run, delivered so the sensor's allowlist check does not depend on a separate call. |
| Update ring | Which sensor-update ring this host is in. |
Every one of those sections is covered by the same signature and the same content hash — there is no separate versioning per section. Adding a new field to what the bundle carries (the SCA section, for instance, and the response-script allowlist) did not require a new delivery mechanism, only a new field on the same signed document.
What is actually enforced on the endpoint today, and what is not
| Bundle section | Enforced locally by the sensor today? |
|---|---|
| FIM watch paths | Yes. The sensor's FIM collector watches exactly what the current bundle names, nothing more. |
| SCA fact-collection targets | Yes. The sensor collects exactly the facts the current bundle's SCA section names. |
| Response-script allowlist | Yes, as a second, independent check: a sensor refuses to run a script named in a ticket that is not also present in its own last-received bundle. |
| Indicators of compromise (action: detect/block/quarantine) | No. The action field rides in the bundle for a future local-enforcement release. Today, matching and alerting happen server-side, on ingest — see Indicators of compromise. |
| Custom IOA rules (action: detect/kill/block) | No. Same as above — matching and alerting happen server-side, on ingest, not locally. See Custom IOA rules. |
| Prevention (enabled, ML sensitivity, on-write action) | No. The settings are carried and resolved correctly; there is no on-sensor classifier or kill path yet to act on them. |
| Exclusions | No, for the same reason — there is nothing on the sensor yet that a prevention exclusion would need to exempt. |
Verification and offline behaviour
The bundle is signed with Ed25519 under a signing key dedicated to policy bundles — a different key from the one that signs sensor-update manifests, held separately for the same reason those two trust chains are kept apart everywhere else in the product. A sensor verifies the signature and also checks that the bundle actually names its own organisation and sensor ID, which catches a validly-signed bundle meant for a different sensor, something a signature check alone would not catch.
A verified bundle is written to disk and re-verified on load, so a tampered cache file is exactly as inert as a tampered bundle received over the wire. On a cold start or while the network is unreachable, the sensor applies the last-known-good bundle from disk before it ever makes a network attempt — this is what makes the channel genuinely offline-safe: a laptop cut off from the network keeps enforcing whatever it last verified (FIM watch paths, SCA targets, the response-script allowlist) rather than reverting to nothing or to factory defaults. A verification failure never applies the new bundle; the sensor keeps running under the last one it trusted.
There is no staleness or expiry on a cached bundle in the current schema — a host that stays offline for a long time keeps enforcing an old bundle indefinitely rather than failing safe to a tighter default after some number of hours. That is a known, deliberate omission rather than an oversight, and worth knowing if you are thinking through what happens to a host group whose policy needs to change urgently while some of its hosts are offline.
"Preview effective policy", and why there is no re-sync button
A sensor always pulls its bundle on its own poll cycle — there is no server route to push a bundle to a host on demand, and the console does not pretend otherwise. What genuinely exists, from the endpoint's View details modal (see The endpoint list and endpoint health), is Preview effective policy: it resolves and signs the current effective policy for that host without persisting a new bundle version, which is exactly what the host would receive on its next check-in. That is the honest substitute for a re-sync action, and it is labelled as a preview rather than as anything that reaches the sensor.
The same modal shows what the sensor last confirmed it applied — a content hash, not a bare version number, because an unchanged bundle hashes identically regardless of version — next to the content hash of the latest bundle the server has built for it. A mismatch badge compares the two: matched, mismatched, or unknown when either side has never been observed (a sensor that has never reported applying a bundle, or a tenant with no bundle history at all, has not disagreed with anything, so it is shown as unknown rather than as a false mismatch).
What to read next
- Policy objects and host groups — how the content of the bundle is decided before it is ever built.
- Indicators of compromise and Custom IOA rules — the detection content the bundle carries but does not yet enforce locally.
- File integrity monitoring — the section of the bundle a sensor genuinely does act on.
- The endpoint list and endpoint health — where the applied-vs-latest mismatch badge and Preview effective policy actually live.